WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 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)

15829.001.diff (5.7 KB) - added by duck_ 5 years ago.
15829.002.default-on-both.diff (7.1 KB) - added by duck_ 5 years ago.
15829.002.default-on-ms.diff (7.2 KB) - added by duck_ 5 years ago.
15829.diff (7.2 KB) - added by ryan 5 years ago.
Updated pref names

Download all attachments as: .zip

Change History (31)

comment:1 @ryan5 years ago

Defaults for multisite are on front and back.

comment:2 @PeteMall5 years ago

is_multisite()

show on front, admin

else

show on front, hide admin

comment:3 @ocean905 years ago

Why we need an option if we have a filter?

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

comment:4 @nacin5 years ago

  • Owner set to duck_
  • Status changed from new to assigned

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

comment:5 @alex-ye5 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...

Last edited 5 years ago by alex-ye (previous) (diff)

@duck_5 years ago

comment:6 follow-up: @duck_5 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.

comment:7 in reply to: ↑ 6 @duck_5 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

comment:8 @duck_5 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.

comment:9 @ryan5 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.

@ryan5 years ago

Updated pref names

comment:10 @nacin5 years ago

  • Keywords i18n-change added

comment:11 @ryan5 years ago

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

comment:12 @nacin5 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.

comment:13 @nacin5 years ago

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

comment:14 @nacin5 years ago

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

comment:15 @nacin5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:16 @demetris5 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.

comment:17 @nacin5 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

comment:18 @jane5 years ago

[] Display when viewing site
[] Display in dashboard

comment:19 @jane5 years ago

Show Admin Bar [] when viewing site

[] in dashboard

comment:20 @nacin5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:21 @demetris5 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.

comment:22 @jane5 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.

comment:23 @demetris5 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?

comment:24 @nacin5 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.

comment:25 follow-up: @demetris5 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.

comment:26 in reply to: ↑ 25 @PeteMall5 years ago

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.

comment:27 @ryan5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.