#13516 closed feature request (duplicate)
Hide JS-only widgets on dashboard is no JS
Reported by: | jane | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0 |
Component: | Administration | Keywords: | |
Focuses: | Cc: |
Description
We hide screen options and help; we should also hide these widgets instead of displaying by default with the 'you need JS' message. Affected modules: QuickPress, Incoming Links, Plugins, WordPress Development Blog, Other WordPress News.
We should display an additional module for no-JS people that lets them know that their WordPress install would be even more awesome with JavaScript, and list out some of the features they would gain access to with JS enabled.
Change History (11)
#2
@
14 years ago
I agree, I could have worded that better. The current setup, if you don't have JS, displays all the dashboard modules with a note in each of those non-js modules that is not helpful. It just says This widget requires JavaScript. There's no alternate way to get those features, and since no-js means no screen options, they have no way to hide those modules and are faced with the negative messaging 5 times on every dashboard load. I would rather they be hidden so that no-js users aren't continually seeing that downer of a message.
Having a module for no-js people that just lists out what they can't get (but in more positive terms) would be helpful because people looking at things like WordPress for Dummies, screenshots in the codex, or video tutorials may think there is something wrong with their WordPress b/c things are missing. Yes, people with screenreaders know how this goes and dont need the reminder, but regular users who have js disabled by employers, etc generally don't. I spent 45 minutes at WordCamp Ireland helping a woman who was utterly confounded by widgets b/c directions she found online didn't work, and when I looked, she just didn't have js enabled on her work laptop, which she didn't even understand as a concept though she was an intelligent woman. I've also seen someone say WP doesn't work on their phone, and their assumption was that the code was just error-prone, not that the phone didn't support javascript.
I think messaging about the differences between the js/no-js distinctions would help more people than it might annoy.
#3
@
14 years ago
OK, I agree with your points.
Ideally the failure procedure would go something like this:
- Partial JS failure falls back on non-js functionality and mostly works.
- A feature with core functionality absent has a message indicating that it won't work.
- Those with no JS whatsoever get the general reminder that things could be better.
#5
@
14 years ago
- Keywords 3.2-early added
- Milestone changed from 3.1 to Future Release
Punting due to entering beta. Marking 3.2-early.
#7
@
13 years ago
Are we still adding this in 3.2? It seems the argument by @filosofo affects other pages in the admin too so the right thing for here would be to extend the JS that replaces the body class no-js
-> js
. Then we can continue using the existing hide-if-no-js
and hide-if-js
CSS classes to control what is shown on the screen.
I'm thinking the "reduced functionality" warning can be a standard (yellow) message at the top of the screen mentioning the disabled widgets.
Let's not think of JS use in too binary of terms, as in just JS vs. non-JS.
The common problem is clients with limited JavaScript. Take for example many of the browsers on phones. There's a wide range of JS support, some with enough support not to see the noscript tags but not enough to do anything WP admin uses it for.
That's why the JS needs to be progressive enhancement: adding features on top of functionality that still mostly works when the JS fails. It's not helpful to remind a JS-limited phone browser (the only one available for that phone), a screenreader (necessary for the blind), or a text-only browser (being used over a low-bandwidth connection) how awesome better JS support in general would be.
Those users are already aware at least that they're missing out, even if they don't know the technical reasons why. Best to let JS-failure fall back to non-JS functionality; if not possible, at least let them know specifically what won't be working.