Admin Bar on/off preferences

[jane]

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.

[ryan]

Defaults for multisite are on front and back.

[PeteMall]

is_multisite()

show on front, admin

else

show on front, hide admin

[ocean90]

Why we need an option if we have a filter?

The current behavior, see PeteMall's comment, should be good enough.

[nacin]

We're doing an option for users. Rare situation.

[alex-ye]

In my opnion a option is better than filter _{, we can add option in the user controll page ....}

[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.

[duck_]

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

[duck_]

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.

[ryan]

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.

[ryan]

Updated pref names

[ryan]

(In [17032]) Admin bar visibility prefs. Props duck_. see #15829

[nacin]

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.

[nacin]

(In [17054]) Simplify this string. props jane, see #15346, see #15829.

[nacin]

(In [17055]) String changes to admin bar preferences. props jane, see #15829.

[demetris]

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.

[nacin]

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

[jane]

[] Display when viewing site
[] Display in dashboard

[jane]

Show Admin Bar [] when viewing site

[] in dashboard

[nacin]

(In [17095]) Final string tweaks to admin bar preferences. props jane, fixes #15829.

[demetris]

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.

[jane]

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.

[demetris]

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?

[nacin]

Your attitude should join the UI team in that regard.

Closing as fixed. You've demonstrated that there is nothing worth discussing here.

[demetris]

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.

[PeteMall]

It is too late in the 3.1 cycle to be making string changes. We are already concentrating on regressions and blockers. I appreciate you effort and I hope you show the same entusiasm early in the 3.2 dev cycle and overhaul all settings screens.

[ryan]

Per wordpress-dev IRC discussion, resolving this as fixed with the points made here noted for 3.2.