Opened 14 years ago
Closed 14 years ago
#15829 closed task (blessed) (fixed)
Admin Bar on/off preferences
Reported by: | jane | Owned by: | duck_ |
---|---|---|---|
Milestone: | 3.1 | Priority: | normal |
Severity: | normal | Version: | 3.1 |
Component: | Administration | Keywords: | ux-feedback i18n-change |
Focuses: | Cc: |
Description
Per IRC discussions and original agreements about how feature would work, we still need to put in preferences for having the admin bar on/off for live site and admin.
Defaults: off in admin, on in live site
Preference as personal option a la Visual editor and color scheme in Profile.
Attachments (4)
Change History (31)
#3
@
14 years ago
Why we need an option if we have a filter?
The current behavior, see PeteMall's comment, should be good enough.
#4
@
14 years ago
- Owner set to duck_
- Status changed from new to assigned
We're doing an option for users. Rare situation.
#5
@
14 years ago
In my opinion a option is better than filter , we can add option in the user controll page and this allow every admin user to chose if he want the admin bar or not or in another way why not we add a botton in the admin bar to hide or show the bar...
#6
follow-up:
↓ 7
@
14 years ago
15829.001.diff
attached. Works around the problem of existing users and the default settings by changing the option strings as required... however this does make it quite messy, so another solution (if there someone can think of one) is probably preferable. Another note is the user of non-short-circuiting |
to avoid undefined notice, probably want to either change this to calling each filter again or assign the filter results before the first conditional for clarity.
#7
in reply to:
↑ 6
@
14 years ago
Replying to duck_:
15829.001.diff
attached. Works around the problem of existing users and the default settings by changing the option strings as required... however this does make it quite messy, so another solution (if there someone can think of one) is probably preferable. Another note is the user of non-short-circuiting|
to avoid undefined notice, probably want to either change this to calling each filter again or assign the filter results before the first conditional for clarity.
Just noticed that I think the code in wp-admin/includes/user.php can be cut down a bit since wp_update_user will perform a merge with old data, so only need to set $user->admin_bar_pref_* when apply_filters('show_admin_bar_pref_front', true) == true
#8
@
14 years ago
- Keywords has-patch needs-testing added; admin bar options removed
Re-rolled patches after IRC discussion. No option UI display filter. Ran with 'true'/'false' still to be consistently lame with other usermeta and empty('0') == true (see wp_insert_user).
15829.002.default-on-both.diff
: admin defaults to on in both admin and front for both multisite and single.
15829.002.default-on-ms.diff
: sticks with defaults mentioned at top of ticket.
Moved show_admin_bar to admin-bar.php per ryan.
#9
@
14 years ago
15829.002.default-on-ms.diff looks good. We're sticking with the defaults per the top of the ticket.
As discussed in IRC, let's change the preference names to show_admin_bar_front and show_admin_bar_admin. Now that we aren't inverting the meaning of the prefs depending on context, we can use a less generic name.
#12
@
14 years ago
- Keywords ux-feedback added; has-patch needs-testing removed
Going over this now. Looks good. What's left?
I believe Jane wanted possibly different strings?
One option is "Display the admin bar on the [ X ] admin dashboard and [ X ] website", reducing redundancy and moving it to two checkboxes in the same line.
#16
@
14 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Currently the preferences are like this:
Admin Bar [ ] Display the admin bar when viewing your site [ ] Display the admin bar when accessing the dashboard
The first pref says “your site”, but it’s not always YOUR site, and you don’t necessarily have ONLY ONE site.
The second pref talks too much. It only needs to say: Display the admin bar on the dashboard
I think we should take it from the start again and aim at something like:
Admin Bar [ ] Display the admin bar on the front end [ ] Display the admin bar on the dashboard
I am tempted to say that “front end” may be prohibitively technical, but I don’t know what else to use. We don’t have a standard term for the part of a WordPress setup that is not dashboard — which is a general problem in our terminology.
Then again, some technical terminology is unavoidable, and we already use lots of terms that would seem pretty weird in everyday speech.
#17
@
14 years ago
Conversation between Jane and I on skype:
Andrew Nacin: Let me know what else you wanted here: http://core.trac.wordpress.org/ticket/15829#comment:12 Andrew Nacin: I knew you didn't like frontend/backend Jane Wells: generic bloggers don't use those terms Jane Wells: devs do Andrew Nacin: I agree Jane Wells: i don't like admin dashboard Jane Wells: i said just dashboard Andrew Nacin: Ok, typo then. Jane Wells: it's what matt calls it Andrew Nacin: This is what's included in the Help text when you're on the Dashboard, fyi: "The Admin Bar at the top, new in 3.1, provides quick access to common tasks when you are in the front end of your site." Jane Wells: s/front end/public-facing portion Jane Wells: s/in/viewing Andrew Nacin: I was going to say "public-facing" but then it's unclear that it's only when you're logged in. Andrew Nacin: "when you are viewing the public-facing portion of your site", yes? Andrew Nacin: s/unclear/could be more clear/ Jane Wells: s/in the public-facing portion/viewing your Andrew Nacin: "when you are viewing your site" Jane Wells: yeah Jane Wells: simpler Andrew Nacin: agreed Jane Wells: accessing your dashboard v viewing your site Andrew Nacin: two checkboxes, one line? Jane Wells: two lines, that's how all settings and prefs are done Andrew Nacin: ok. I think the comments page has some interesting one-line things Jane Wells: that one is super messed up Andrew Nacin: okay Andrew Nacin: "[ X ] Display the admin bar when viewing the dashboard" Andrew Nacin: "[ X ] Display the admin bar when viewing your site" Jane Wells: i would use accessing or working in for the dashabord one, to drive home fact that it's the active area, as opposed to passive viewing on site Andrew Nacin: "[ X ] Display the admin bar when viewing your site" Andrew Nacin: "[ X ] Display the admin bar when accessing the dashboard" Andrew Nacin: using? Jane Wells: good as is Andrew Nacin: ok. Andrew Nacin: should it be Admin Bar? Jane Wells: nah Andrew Nacin: agreed
#21
@
14 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Now we have inconsistency in the UI AND deterioration in the message.
We start with this:
Visual Editor [ ] Disable the visual editor when writing Admin Color Scheme ( ) Blue ( ) Gray Keyboard Shortcuts [ ] Enable keyboard shortcuts for [...]
... and then:
Show Admin Bar [ ] when viewing site [ ] in dashboard
The deterioration is that we have sentences whose parts live in different columns and are separated by checkboxes.
#22
@
14 years ago
There is inconsistency all across the settings UI, which we know about. The admin bar is more consistent with the Reading Settings. Yes, it's dumb. All settings are getting UI overhaul in 3.2.
#23
@
14 years ago
You know what needs an overhaul? The UI team.
How much time do we need to spend to get two decent sentences in, in a manner that is consistent at least with the adjacent UI elements in that particular screen?
#24
@
14 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Your attitude should join the UI team in that regard.
Closing as fixed. You've demonstrated that there is nothing worth discussing here.
#25
follow-up:
↓ 26
@
14 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Please, Andrew, spare me the admonitions.
My attitude is that I see an issue and that I take the time to come here to explain what it is, demonstrating in detail, and to suggest improvements.
If Jane, the head of the UI team, cannot offer a satisfactory solution to this very simple problem, and then comments “there is inconsistency all across the settings UI”—how on earth is this an excuse for leaving the prefs as they are currently?—, then I think we have a more serious problem.
I do not have unlimited resources, no contributor has unlimited resources, and when contributing proves to be too much of a struggle, as it is sometimes, then, simply, people do not contribute.
Defaults for multisite are on front and back.