[wp-trac] [WordPress Trac] #32678: Audit toolbar links and content
WordPress Trac
noreply at wordpress.org
Mon Jun 29 20:11:51 UTC 2015
#32678: Audit toolbar links and content
-----------------------------------------------+------------------
Reporter: helen | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 4.3
Component: Toolbar | Version:
Severity: normal | Resolution:
Keywords: has-patch make-flow needs-testing | Focuses: ui
-----------------------------------------------+------------------
Comment (by ryan):
Talking through this out loud while looking at single site on a phone...
Customize is the impetus for this rework. Let's talk about it. I want
Customize available from the admin, not just the front-end. Currently, you
must go through Appearance in the admin menu to get at it. On the front
end, Customize is available from the toolbar via Dashboard > Customize
(which I use every time I customize). I don't like Customize in the
Appearance submenus because I have to dig to get at it and because its an
outlier among the other Appearance menus. So, if we remove it, where does
it go? The proposal here is to put it top level in the toolbar. I'm not
completely sold on that; I'm still waffling. After heavy use during setup,
Customize use trickles off. Most of the time it will be clutter in what
should be a tight bar. I think I prefer it in the Dashboard toolbar menu
as it is now. But then we have Customize and Appearance in the same
toolbar menu. Further, the Home icon in the admin toolbar doesn't have a
menu so we can't put Customize in there to accommodate admin views. A
strike against the Home, Dashboard pairing that I like so much. But, with
the W menu on phones toggling the admin menu, the new design can't
accommodate Customize anywhere but on the top-level either. The W menu
*must* always be the same and match the admin menus for the new design to
work. Customize would have to be top-level in the admin menus for either
the existing bar or i9b to work without Customize top-level in the
toolbar. All new things must be added to top-level? Either top-level admin
menu or top-level toolbar?
Walking that path warms me to replacing Home, Dash with a persistent menu,
although having the top-level of the admin menu follow me around does not
appeal to me at first blush. I've gotten used to working around its
baggage. :-) On the up side, a persistent slice of the top level admin
menu will offer a way to traverse into top-level admin menus without
having to experience the tap-burning submenus. @folletto noted that above,
and I appreciate this benefit. The Dashboard menu could be changed to save
submenu tapburns, however. See some submenus-on-touch talk here:
https://make.wordpress.org/flow/2015/06/13/site-switching-on-the-make-
network-iphone-6/ and item #4 here:
https://make.wordpress.org/flow/2015/06/13/the-top-5-impediments-to-flow-
on-touch-devices/
> This idea solves both the initial issue (no more discussion on which
items to include and which not, that gets incredibly simplified) and also
creates a long-lost consistency between front-end and back-end. Plus
solves all your flow concerns above.
That resonates. Any change we do, Customize or something else, is going to
force these discussions until we make an accommodation in the direction of
a persistent top-level. But this also resonates.
https://make.wordpress.org/flow/2015/06/29/toolbar-survey-iphone-6/#jp-
carousel-2431
I love the way that works and looks. It is lovely to me and would be great
if the Dashboard menu was fixed. But, it unravels under certain desires.
Okay, I think I've talked myself into letting go. I'll keep testing. We
still need vizrecs.
Aside: Landing #29906 would make exercising both the old and new bars so
much nicer.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/32678#comment:61>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list