Opened 9 years ago
Last modified 5 years ago
#32678 assigned enhancement
Audit toolbar links and content
Reported by: | helen | Owned by: | helen |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Toolbar | Keywords: | has-patch make-flow needs-testing has-screenshots needs-refresh |
Focuses: | ui | Cc: |
Description
We've done some tweaks here and there in the toolbar, such as changing where links go or adding/removing some, but I don't think we've really taken a wider view of its general contents since 3.2 in #17705. Right now, some links take you into the customizer context without warning (as do a couple in the admin menu), which is quite jarring. We need context for each link to be clearer, and a good hard look at how the toolbar actually gets used and if it's really working to help get users to where they need to go more quickly.
At the very least, for 4.3, we need to resolve the issue of mixing customizer links in with dashboard links.
Attachments (28)
Change History (193)
This ticket was mentioned in Slack in #design by celloexpressions. View the logs.
9 years ago
@
9 years ago
Replace "appearance" with "admin" menu in admin bar, add top-level Customize link for admin and front-end.
#5
follow-up:
↓ 6
@
9 years ago
- Keywords has-patch added
32678.diff is a first-pass that attempts to cover the bare minimum here so that we can get something into 4.3 safely. The "admin" menu in the toolbar is intentionally built-out manually, so that plugins would be required to opt-in to having their links here by adding them via the admin bar API (and makes it a lot easier since there's not much of an API for the admin menu). Comments and Tools are excluded intentionally because comments have a top-level link in the admin bar and we've been thinking about removing tools at least as a top-level admin menu item for a while anyway. But if we added icons we'd probably want parity with the admin.
It's easier to not have the icons for the admin menu items here (since they're submenus), but we could add those if we really want them. I also really like the idea of merging the WordPress icon in with the site title and killing the dashboard icon, but not sure if we're willing to lose that "About" menu in the process.
@melchoyce is working on an icon for Customize - the current one is a placeholder but we may end up with something similar to it. Also need to think about the exact placement of the Customize link - it should be before edit since edit isn't always there, but we may want to put it before add new so that we don't split new from edit.
#6
in reply to:
↑ 5
@
9 years ago
Replying to celloexpressions:
but we may want to put it before add new so that we don't split new from edit.
Maybe even before "Updates" right after the "admin" (Site name, whatever it's called) menu?
#7
@
9 years ago
so that plugins would be required to opt-in to having their links here by adding them via the admin bar API (and makes it a lot easier since there's not much of an API for the admin menu).
I'd personally suggest to keep (if possible, of course, maybe even post 4.3) the back-end and front-end navigations identical. This not just for a slight ease of use for developers, but more importantly to give stability of the navigation for users that don't have to "read" two different menus and understand a difference between front-end and back-end menu.
This might seem minor, but will give a lot of stability and ease of use to WordPress. It's just the same menu. Couldn't be simpler than that. :)
Which also means that the visual treatment should be the same, icons included — as the mockup (which I get, could also be done in a future release to keep this doable for 4.3).
I also really like the idea of merging the WordPress icon in with the site title and killing the dashboard icon, but not sure if we're willing to lose that "About" menu in the process.
This is a good question. My advice would be:
- Let's assess the links in there. Where do they go to?
- Maybe we can add them at the bottom of the menu for now, until we make sure we remove them OR we just keep the icon separate until we do the assessment (1).
#8
@
9 years ago
Quick assessment on the current (W) menu:
- Icon →
/wp-admin/about.php
. - About WordPress →
/wp-admin/about.php
. This page doesn't seem linked anywhere else. - WordPress.org →
wordpress.org
. Linked from the footer of every wp-admin page. - Documentation →
codex.wordpress.org
. Deep-Linked from the "Help" tab present on every wp-admin page. - Support Forums →
wordpress.org/support
. Linked from the "Help" tab present on every wp-admin page. - Feedback →
wordpress.org/support/forum/requests-and-feedback
.
This means that the only missing pages are:
- "About", which could be easily and appropriately linked on the version text of every wp-admin page (i.e. "Version 4.2.2").
- "Feedback", which could be added to the footer too, or the Help tab, or else.
#9
@
9 years ago
I did another iteration (i6) with the feedback above. Moved customizer link (with placeholder icon), aligned the look of the menu to be exactly identical to wp-admin at both desktop and mobile and matched the icons on mobile to be properly sized (might be just me on this last one, however).
I've also introduced an idea on how to leverage the current notifications that happen as counter bubbles in the sidebar and surface them in a single dot in the admin bar, thus achieving a win-win: we leverage the already existing navigation bubbles and we simplify the admin bar too. This again might be a more long-term view, so we can keep it for later.
#10
@
9 years ago
Visual surveys of the production toolbar.
https://make.wordpress.org/flow/2014/07/07/the-guises-of-bar-nexus-5-4-0-alpha-20140706/
https://make.wordpress.org/flow/2014/06/20/the-guises-of-bar-macnchrome-single-site/
https://make.wordpress.org/flow/2014/06/18/the-guises-of-bar-ipad-air-single-site/
#12
@
9 years ago
For my use, the most important flows are create, edit, customize, and front-to-back linkage.
My favorite incarnation of the production toolbar is on phones, as seen here: https://make.wordpress.org/flow/2014/07/07/the-guises-of-bar-nexus-5-4-0-alpha-20140706/
The straightforward front to back linkage with paired home and dashboard icons, the edit icon that is contextually aware of posts, pages, CPTs, and taxonomy, and the creation icon seen in those Nexus 5 shots are pretty nice.
I don't use the comments icon nearly so much. I'm more interested in likes than comments. Commenting happens on social sites via Publicize. Collapsing them into one thing sounds good to me. Long ago (during the 2.7 design) we wanted to have a notifications/stream page that brought everything together. That never happened.
We also show an Updates icon when there are core, theme, or plugin updates, except on phones. How would we handle that in the new design?
There's a site switcher key icon on multisite installs, as seen here: https://make.wordpress.org/flow/2015/06/13/site-switching-on-the-make-network-iphone-6/
There's also a view post/page icon when editing a post or page in wp-admin. This seems a good candidate for removal to make room for other things.
The current W menu (with about, documentation, etc.) is a waste of important space. I'm glad production omits it from the toolbar on phones. Putting a unified menus there seems more useful.
In Unified Concept i6, how do I get from wp-admin to the frontend? On desktop I'm assuming I tap the blog title. That won't be available on touch devices. A View Site item at the top?
One of the things I miss the most in the production toolbar is access to Posts. Concept i6 is a big help there.
i6 has Customize, Edit, and New up top. That satisfies 3 out of my 4 favorite flows. That leaves my question about front to back linkage with view site.
@
9 years ago
Desktop toolbar showing updates (core, themes, plugins). Links to the Grand Unified Updater (GUU), /wp-admin/update-core.php
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
9 years ago
#14
@
9 years ago
I like the third through sixth icons proposed above, with the 3rd being my favorite because it's more abstract, fitting the word Customize well, while the others definitely imply "site builder" or "layout modifier", which is too specific and not something they can necessarily do.
#15
@
9 years ago
Played around with the patch some more, and here's where I got:
- Removed the W/About menu. Added a link to about.php under dashboard in the admin menu as an alternative placement for now. I think we're probably fine without that feedback link; looking at some of the posts there I don't think it's a productive means for evaluating community feedback, although it would be great to have a better system in place in the future.
- Merged the W icon into the site title/admin menu, in place of the dashboard icon.
- Added comments and tools to the "admin" menu, for parity with what core has here.
- Removed the top-level comments link, related: #27831.
- Removed the Headers and Backgrounds Customizer deep-links from the admin menu under Appearance, so that the only admin menu link going to the Customizer is "Customize" (these were temporary/transitional anyway).
- Added notification counts for plugins and comments in the "admin" submenu. Note that updates is a submenu of dashboard in the admin, and I think a lot of users rely on the update count in the admin bar so I think we should keep that as its own item there.
- Added a small notification bubble to the W icon when there are pending comments or plugin updates, per @folletto's i6 design.
- Moved Customize next to the site title menu.
I believe the only remaining thing needed to get to a full implementation of the i6 design above is bringing in the admin menu icons and the admin menu styling for the admin submenu in the admin bar.
#16
follow-up:
↓ 32
@
9 years ago
First answering a bit...
We also show an Updates icon when there are core, theme, or plugin updates, except on phones. How would we handle that in the new design?
I'd use the same notification dot on the W icon. Or we can add another "action" button, if we feel that's not enough, but I feel that the notification dot should work. We could also use different colors from the Design Handbook: maybe blue for comments and orange for updates.
Customize icon ideas in content
I'd avoid the last one because it's often used for "plugins". If possible I'd like also something less abstract, but I would be ok with either. I'd like @melchoice's feedback here. :)
—
Added new iteration (i7) building on the points above, specifically:
- create + edit + customize + front-to-back flow
- handle multi site
A couple of notes on i7:
- Going back to front-end: I feel we could have some kind of "separate" badge to do that, but let's try with something simple first: what if the W logo / title just goes back to the site? Too hidden? Any perspective or data here?
- "My Sites" is going to be a bigger issue, but I don't want to tackle that now because seems a bigger issue, so I've suggested an approach that will allow to keep the existing structure without more rework, just switching the places.
- "My Sites" however should have a more descriptive icon. Even just adding a circle that makes it identical to the W logo makes it way better, but I feel that some work should be done there too inside that circle.
Also: amazing work there @celloexpressions! :)
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
9 years ago
#18
@
9 years ago
The issue with general updates is that there's nowhere to display the update count or a link to updates in the "admin" menu that comes down there, so you wouldn't have any clear path to addressing the notification. I think that's probably fine as its separate icon for now.
Other note - currently (in the patch) the "home" icon is used in place of the W icon in the admin context, which I think makes sense because that links to the front page of the site instead of the dashboard. But, we do lose that branding there, so not sure whether that's worth it.
#19
@
9 years ago
The issue with general updates is that there's nowhere to display the update count or a link to updates in the "admin" menu that comes down there, so you wouldn't have any clear path to addressing the notification. I think that's probably fine as its separate icon for now.
I'm ok with a separate icon for now, however given core updates come inside the "Updates" menu inside "Dashboard", and dashboard has the update message at the top once opened — we should just show a badge there and put the dot on the W icon as for comments. This would also scale better on mobile.
But yes: we can keep the icon for now and iterate in a later patch.
Other note - currently (in the patch) the "home" icon is used in place of the W icon in the admin context, which I think makes sense because that links to the front page of the site instead of the dashboard. But, we do lose that branding there, so not sure whether that's worth it.
The W icon should always stay there. Not just for branding, but also for context. With this point you also made me noticed that I overlooked a piece in the previous i7, which was the opening of the menu from the admin side on mobile. So I reworked a bit the design, and followed your idea of using the house icon ("Home" action). If we put it immediately to the right of the site name it would work well. :)
So, uploaded i8 design above. ;)
#20
follow-up:
↓ 25
@
9 years ago
Regarding my screenshot, why have appearance and customize? they’re basically the same thing.
We could use the brush we have for customize and take it out of the left menu. It's really weird that the site name item toggles icons between the gauge and the house. I never got used to that behavior, and it's hard to explain. They should be separate actions.
#21
follow-up:
↓ 22
@
9 years ago
Isn't this basically just moving "appearance" out of the sidebar into the top bar? Customize has all the stuff you get in appearance, minus themes. Maybe themes could be in the customizer, or its own top level menu item.
#22
in reply to:
↑ 21
@
9 years ago
Replying to EmpireOfLight:
Isn't this basically just moving "appearance" out of the sidebar into the top bar? Customize has all the stuff you get in appearance, minus themes. Maybe themes could be in the customizer, or its own top level menu item.
Some of those links are still standalone admin screens that are not going anywhere. This ticket is rooted in the problem we have of some links going to the customizer context without warning and that those links should be differentiated from ones that go to an admin context, especially when they have the same label (menus admin screen vs. menus in the customizer).
#23
@
9 years ago
This ticket and associated patch is streamlining the navigation across back-end and front-end. I think that Ryan did an excellent summary above (comment 12). It's not just about moving that link. :)
The discussion of dropping Appearance and keeping just Customizer is entirely different (and as far as I know got a sensible pushback recently), so let's avoid that in this ticket. As Helen said we're polishing flow, avoiding that a menu opens entirely different destinations from a single list. Which led us to a cleaner navigation overall, so this so far feels a big win, also thanks to the swift patching by Cello. :)
I think the direction is good right now... but I'd like a check on the icon lol :D
#24
@
9 years ago
Some history, as I remember it. The updates icon was added at top level because we wanted update notifications to be right there at the top of every logged in page load. When that update icon shows, I know I have updates to install. Getting sites updated is important to the health of the web. Update flow deserves some weight when balancing the bar. I also like a toolbar that appreciates brevity; losing a top level is appealing.
#25
in reply to:
↑ 20
@
9 years ago
Replying to EmpireOfLight:
Regarding my screenshot, why have appearance and customize? they’re basically the same thing.
We could use the brush we have for customize and take it out of the left menu. It's really weird that the site name item toggles icons between the gauge and the house. I never got used to that behavior, and it's hard to explain. They should be separate actions.
I'm glad you brought this up, because it's worth starting to think more seriously about potential longer terms plans as we make admin bar tweaks for 4.3.
With menus, all "Appearance" functionality is in the Customizer (note that Themes were added in 4.2) with the exception of theme-install and the theme editor. I'm planning on tackling both of those in 4.4. At that point, all of the appearance functionality will be in two places. Most likely, as things continue evolving, usage trends progress and development focus shifts, it will make sense to remove the currnet appearance section from the admin in the future. That doesn't necessarily mean that all of that functionality would only exist in the Customizer, for example maybe a menus UI is added to pages/list tables somewhere or something, but we would at least hide the current admin pages for users that can access the Customizer. I anticipate that we'll reach this point in the next year or two, but it's obviously hard to say at this point, and people definitely have opinions about these types of changes, even when proposing that we commit to at least partially doing them a year from now.
At the same time, the scope for the Customizer is definitely not limited to "Appearance" and really, its full power is realized when themes and plugins use it more broadly. We currently define the Customizer as "A framework for live-previewing any change to WordPress." Since it could contain anything, we need an appropriately abstract icon. I"m definitely liking the one that I mentioned before and @folletto used in his latest designs.
The current approach that this ticket takes addresses the short-term problems while also setting us up for several future improvements. The Customizer gets the visibility it deserves and becomes more conceptually separated from "Appearance", the admin becomes significantly more accessible from the front-end, the often-unhelpful dashboard is de-emphasized, etc. We also have the ability to easily upgrade the Customize link to do a much faster/shinier loading of the Customizer in the future without moving it. Notably, the add-content and edit-content links remain separated from the admin menu (and we skip submenus there for simplicity), setting us up to be able to point them to a front-end-contextual content-creating/editing experience if we build that in the future, without moving links around. This minor rearrangement should be able to last several years without things moving around much if at all, even as further adjustments are made to the features they point to.
@folletto could you add designs for the admin with the home concept and also showing the admin menu, on desktop and mobile? I'm thinking that perhaps we should remove the "hamburger" icon and use the W to toggle the admin menu on mobile in the admin, for consistency with the front-end.
#26
@
9 years ago
@folletto could you add designs for the admin with the home concept and also showing the admin menu, on desktop and mobile? I'm thinking that perhaps we should remove the "hamburger" icon and use the W to toggle the admin menu on mobile in the admin, for consistency with the front-end.
Heya! They are already in iteration 8. See the right side and bottom alternatives? :)
I can use a different visualization if that's not clear, let me know. :)
@
9 years ago
another icon idea...makes visual reference to the design of the customizer, which may or may not be a good thing
#28
follow-up:
↓ 29
@
9 years ago
another icon idea...makes visual reference to the design of the customizer, which may or may not be a good thing
I like this idea. Also because it doesn't just recall the customizer, but there's also "one item different from the others" like the previous concept, which makes this icon meaningful even if you don't get the resemblance at a first sight. :)
#29
in reply to:
↑ 28
@
9 years ago
Replying to folletto:
another icon idea...makes visual reference to the design of the customizer, which may or may not be a good thing
I like this idea. Also because it doesn't just recall the customizer, but there's also "one item different from the others" like the previous concept, which makes this icon meaningful even if you don't get the resemblance at a first sight. :)
I also think I like this concept best, though it might be too literal, especially if the customizer UI changes in the future. My second vote would be for the smaller brush.
Outside of just this, I like the box grid/layout icon (number 5 in @empireoflight's mockups) and think we should include it in Dashicons as an all-purpose "layout" icon plugin authors can use.
This ticket was mentioned in Slack in #design-dashicons by melchoyce. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
9 years ago
#32
in reply to:
↑ 16
;
follow-up:
↓ 33
@
9 years ago
- Going back to front-end: I feel we could have some kind of "separate" badge to do that, but let's try with something simple first: what if the W logo / title just goes back to the site? Too hidden? Any perspective or data here?
Before the toolbar, the blog title was in an h1 and provided linkage to the front end. Many couldn't find that front end linkage, so we added a "<- Visit Site" link next to it. When the toolbar came, we moved to a home icon with Visit Site in the submenu. The W logo handling visit site may be too hidden (or maybe this is a natural progression), and it wouldn't accommodate touch devices which do not follow links in the toolbar icons (once #29906 is fixed). Seems like Visit Site would need to be at the top of the W menu on wp-admin screens in order for W to accommodate front end linkage. I'm a fan of the home and dashboard icon pairing we have now. My biggest complaint with the pairing is that on touch devices the Visit Site submenu should go away so that going home is one tap.
- "My Sites" is going to be a bigger issue, but I don't want to tackle that now because seems a bigger issue, so I've suggested an approach that will allow to keep the existing structure without more rework, just switching the places.
Cool. The current order came from following a WordPress > Network > Site hierarchy, but I've never really liked that order in practice. The multisite switcher shouldn't jump in front of the new W.
- "My Sites" however should have a more descriptive icon. Even just adding a circle that makes it identical to the W logo makes it way better, but I feel that some work should be done there too inside that circle.
Agreed. I've never liked this icon for a site switcher.
#33
in reply to:
↑ 32
;
follow-up:
↓ 35
@
9 years ago
Replying to ryan:
Many couldn't find that front end linkage, so we added a "<- Visit Site" link next to it.
I'd like to know more about this. Does anyone know where that feedback came from (support team, forums, somewhere else)?
I'm wondering if it was a transition issue that the explicit "Visit Site" link alleviated in the past but now it would be reasonable to remove so that the home icon works the same way as the comment did and the customize icon will (tapping those opens the feature directly instead of triggering a dropdown menu).
#34
@
9 years ago
I love the customizer icon with a nod to the layout but I think the brush is a more natural extension from the larger Appearance brush and also simpler which is more inline with the "+" and the pencil. I like both!
@EmpireOfLight, the first few My Sites options you posted seem like they are complex and have a lot going on compared to the other icons. What about a simple gear icon (too settings-y?) or something similar to this one (which I saw on Google Apps) but with rectangles instead of squares?
#35
in reply to:
↑ 33
@
9 years ago
Replying to designsimply:
Replying to ryan:
Many couldn't find that front end linkage, so we added a "<- Visit Site" link next to it.
I'd like to know more about this. Does anyone know where that feedback came from (support team, forums, somewhere else)?
I'm wondering if it was a transition issue that the explicit "Visit Site" link alleviated in the past but now it would be reasonable to remove so that the home icon works the same way as the comment did and the customize icon will (tapping those opens the feature directly instead of triggering a dropdown menu).
[10168] is the only reference to the re-introduction of Visit Site I've come up with so far.
"Visit Site" in a submenu has never been considered in mobile context. Flying out a menu when hovering over the home icon is an easy hinting trick on desktops that doesn't have a click cost. That flyout becomes an extra tap on mobile. Lingering desktop bias.
This ticket was mentioned in Slack in #design by celloexpressions. View the logs.
9 years ago
#37
@
9 years ago
- Keywords needs-testing added
32678.3.diff is a full build-out of the i8 concept (see those screenshots):
- Add admin menu icons to the toolbar's admin sub-menu
- Align toolbar "admin" menu spacing/fonts with that of the admin menu
- Add a visit site link with the home icon in the admin
- Add an icon to the "View Post" links (this was the only thing in the admin bar without an icon), so that they can be displayed on mobile, giving admin/backend parity for viewing/editing content on mobile as we have on desktop
- Move "My Sites" after the site title
- Use the WordPress logo for the menu toggle in the admin on mobile, to match the front-end behavior
This could use testing but is probably ready for a first-pass commit. Only thing that's missing are the new icons and potential tweaks (for example, background color of the front-end admin sub-menu). Also a bit awkward that we now have two links to the front page in the admin, especially since we don't really have room for them and it's getting a bit cluttered. I'm not planning on iterating on the patch further, so feel free to adjust it further.
This would be a great thing to test and gather feedback about at the WCEU contributor day tomorrow for those that'll be there.
#38
@
9 years ago
Woah @celloexpressions! Amazing! :D
—
Also, about the icons, after reading the feedback above, my personal vote would go for:
- The houses design by @EmpireOfLight for "My Sites" — It conveys the meaning of multitude well.
- The brush as suggested by @designsimply — I like that being in the same context but different from the brush used in Appearance. That argument won me. ;)
- And I'd +1 @melchoyce's idea of adding to the set the box grid/layout icon as an all-purpose layout one.
#39
@
9 years ago
When testing this, think of the toolbar as a flowbar. The toolbar is about enabling the most important flows. My most important flows through the toolbar are:
- Creating posts.
- Editing existing posts.
- Customizing my site.
- Getting from the back-end to the front-end and vice-versa. Front-to-back-to-front flow is important to the create, edit, and customize flows.
Other important flows to test are updating core, plugins, and themes, and logging out.
Any toolbar change is a big deal. This is lots of toolbar change. We need before and after visual records on make/flow across the usual array of screen sizes (desktop, tablet, phablet, phone). Taking screenshots as we develop and posting visual records to make/flow should become reflex.
#40
@
9 years ago
A good start to visually recording this change would be fresh visual surveys of the toolbar.
https://make.wordpress.org/flow/tag/toolbar+visual-survey/
Call for contributors: A good way to help changes like this land while being conscientious and aware is to take lots of screenshots and publish them as visual records.
https://make.wordpress.org/flow/handbook/
https://make.wordpress.org/flow/handbook/triage/
https://make.wordpress.org/flow/handbook/glossary/
https://make.wordpress.org/core/handbook/beta-testing/
This ticket was mentioned in Slack in #core-customize by sheri. View the logs.
9 years ago
#42
follow-up:
↓ 45
@
9 years ago
I tested 32678.3.diff and found that the W icon was missing on small screens:
I also found that the visit site / dashboard toggle was really nice on desktop but lost on mobile, so I added the dashboard icon back in (just for mobile) to the same placement as the visit site (home) icon so that you can use it more like a toggle which feels like a better match with how the desktop links currently work. Here is a screencast comparing 32678.3.diff and 32678.4.diff: 2m27s
This ticket was mentioned in Slack in #core-customize by sheri. View the logs.
9 years ago
#45
in reply to:
↑ 42
@
9 years ago
Replying to designsimply:
I tested 32678.3.diff and found that the W icon was missing on small screens:
I also found that the visit site / dashboard toggle was really nice on desktop but lost on mobile, so I added the dashboard icon back in (just for mobile) to the same placement as the visit site (home) icon so that you can use it more like a toggle which feels like a better match with how the desktop links currently work. Here is a screencast comparing 32678.3.diff and 32678.4.diff: 2m27s
My reflex is to like the Dashboard and Home pairing, and obviously the W menu needs to be shown on small screens now that it actually does something. In production, the W menu is not shown on small screens since it contributes nothing to flow (in fact, its offsite links harm flow).
Putting Dashboard up top means pulling it from the W menu, which creates a difference between the front page W menu and the admin W menu. Visiting index.php is done via the Dashboard icon but visiting other admin pages is done via the W menu. The behavior of Dashboard is changed vs. production. Currently it opens a menu of wp-admin links. The new behavior will take you straight to wp-admin/index.php.
I'm digesting all of that. I'm fond of the current Home, Dashboard icon pairing. This would be an even more straightforward pairing since they'll both be direct links. I like that they're both up top providing extra context and a clear way to the other side.
Flow testing notes (rough):
Start on the front page. Tap + to create a post. Publish that post and then come back around to the front page. What route did you take back? Did the toolbar assist that flow? If you're on desktop, the toolbar will show View Post or View Page when in the editor. After publishing, you can use that toolbar View link to get back. Mobile doesn't have View Post/Page in the toolbar. Another route back is the View Post link in the save/publish notification. Or, the View Post button in the Permalink edit area. Or, just tap the Home icon if you're not interested in traversing to the permalink page. Maybe seeing the post in the context of the front page is sufficient to you.
Start on a post's permalink page. Tap the Edit icon in the toolbar to edit the post. Save and work your way back to the front. Were you able to get back to your post with a tap? Two taps? Did the toolbar help?
Customize your site's title and tagline from the front page. Work your way back to where you started.
Test front-to-back-to-front flow.
#46
@
9 years ago
The patch adds the view post links on mobile FYI.
I'm not sure that I like moving dashboard out from the W. Things are starting to get way too cluttered here, especially on multisite, and I'm leaning towards dropping the separate visit site/home link in terms of coming up with a better way to integrate that flow with the main menu (since this frees up a lot of top=level space/clutter). With the current patch we'd need to adjust the breakpoint for switching to icons only, as the text overflows much sooner even without multisite.
#47
follow-up:
↓ 51
@
9 years ago
Right now I have paired Home and Dashboard icons that I like. They look good on phones. The Home Icon suffers on touch devices with an unnecessary visit site link that burns a tap, but that can be fixed.
If I lose those, what am I getting instead? A W icon that is a visual downgrade on phones. It compromises the toolbar for me on phones. I much prefer having that Dashboard icon first with the Home icon being the first thing after the hamburger menu in the backend. This is a lovely pairing.
I'm getting a W icon that will also be an admin menu actuator on small screens. On larger screens it will be a flyout that duplicates the admin menu below. Not sure how I feel about that.
The W menu will have Posts in it, that's good. I'd rather the Dashboard icon be retained and filled with what we're putting in the new W menu.
Customize deserves promotion to the top.
Which is to say, at least for phones, I like what we have now with Home and Dashboard. Just fix the contents of the Dashboard menu, remove the unneeded Visit Site sub from the Home menu, and add Customize. No W in sight.
#48
@
9 years ago
Look at this: https://make.wordpress.org/flow/#jp-carousel-2431
and this: https://make.wordpress.org/flow/#jp-carousel-2423
That's good. That shouldn't change. The Home, Dashboard pas de deux is one of the best parts of our mobile experience. I'd rather have the pas de deux than what feels like a persistent, branded utility drawer. The pas de deux has rhythm. Make the desktop bar look more like the mobile bar. Drop the W menu from all screens. Make the Dashboard menu useful. Remove Visit Site from Home. Add Customize. Get a better multisite icon. Move the multisite icon after Home and Dashboard. Done.
#49
@
9 years ago
I also found that the visit site / dashboard toggle was really nice on desktop but lost on mobile, so I added the dashboard icon back in (just for mobile) to the same placement as the visit site (home) icon so that you can use it more like a toggle which feels like a better match with how the desktop links currently work.
I think this works well. On desktop having the W that is directly the admin menu doesn't feel needing it to me, but on mobile it's a tap in either case, so feels quite a smooth transition to me. I wouldn't take away the Dashboard item from the menu however: it's important the menus are 1:1 identical. So it's fine to have a shortcut that is one tap away on the toolbar, but that doesn't require taking away the main navigation structure which is super important that stays identical, I agree with @celloexpressions. :)
However...
If I lose those, what am I getting instead? A W icon that is a visual downgrade on phones. It compromises the toolbar for me on phones. I much prefer having that Dashboard icon first with the Home icon being the first thing after the hamburger menu in the backend. This is a lovely pairing.
I disagree with this. Think about the usage: how often do you want to get to the dashboard itself and stop there? Unlikely. You often go to some sub-page. So this isn't a downgrade in any way because:
- Tap W → (dropdown) → Tap section
- Tap Dashboard icon → (loads dashboard) → Tap section
In practice, the dashboard icon optimizes the flow _only_ for people that want to get to the dashboard itself and stop there, which I'd guess it's an edge case. In any other instance, it's just faster to tap W and go to the specific admin page you want (because the dropdown is pre-loaded and won't require a reload).
With this I don't mean to take away the dashboard icon, I'm fine to add it on mobile only if we feel it's important, I'd just highlight that there's no benefit in terms of general flows (taps) between the two.
On larger screens it will be a flyout that duplicates the admin menu below
Uhm well... that shouldn't happen: on wp-admin on desktop the W shouldn't open the menu. Should go somewhere like the Dashboard or the front-end of the site. No menu.
So in short, given the feedback above, here's what I'd do:
- Add the "Dashboard" icon on mobile only.
- Keep the drop-down menu 1:1 identical _all the times_. This is super important.
- Remove the "Visit Site" dropdown from Home. It's a one-tap only action.
- On wp-admin / desktop tapping on W should either go to the dashboard, go to the front-end of the site, or do nothing. No double-menu effect should happen there.
- Add the "Houses" icon to My Sites.
- Add the "Brush" icon to Customize
Sidenote: in the i8 iteration above notice that I used full white icons for things that trigger a menu (W and My Sites) and light gray for things that are instant taps (Home, Customize, Edit, etc).
#50
@
9 years ago
Added concept i9b that implements all of the above (sorry for i9 above it had a few errors):
- Add the "Dashboard" icon on mobile front-end only.
- Keep the drop-down menu 1:1 identical _all the times_. This is super important.
- Remove the "Visit Site" dropdown from Home. It's a one-tap only action.
- On wp-admin / desktop tapping on W should either go to the dashboard, go to the front-end of the site, or do nothing. No 5. double-menu effect should happen there.
- Add the "Houses" icon to My Sites.
- Add the "Brush" icon to Customize.
#51
in reply to:
↑ 47
@
9 years ago
Update: from the list in comment:50, 1, 3, and 4 were already done. I just fixed 2 in 32678.5.diff. Will update 5 and 6 as soon as icons are ready. I need help checking the CSS because it's a bit unruly (diff 32678.3.diff and 32678.5.diff to see the changes I made). Some additional CSS work/polish will probably be needed.
#52
@
9 years ago
With this I don't mean to take away the dashboard icon, I'm fine to add it on mobile only if we feel it's important, I'd just highlight that there's no benefit in terms of general flows (taps) between the two.
The taps are the same but the experience is not. Even when I'm using a View Post link to get back to the front-end, that Home, Dashboard pairing is comforting. I like having them top-left.
My biases: I don't like logo branded nav. Tacky. I cherish my logo blindness. The core toolbar on phones is my favorite of all of the WordPress* bar incarnations because is has some taste and restraint. When looking through a bunch of browser windows on a phone, those Home and Dashboard icons call me home and give me some context. They give more context than a W. Having logo branded nav on a phone looks like lingering desktop bias. Freshly added lingering desktop bias.
I'm concerned that this is going to look like what's on wordpress.com, which I think is a downgrade from core. I use the .com and core bars every day on multiple devices, and I'll take core.
This change requires a lot of diligence. We need flow comparisons. We need to use the hell out of this. Which is why I've been trying to get this done as a feature plugin for a year or so.
#53
follow-up:
↓ 54
@
9 years ago
The taps are the same but the experience is not. Even when I'm using a View Post link to get back to the front-end, that Home, Dashboard pairing is comforting. I like having them top-left.
True: the dropdown is faster than Dashboard + Navigation. So, technically, the dropdown is faster for the same flow. ;)
That said, I'm not sure what downside of i9 you're pointing at (apart your dislike for logos).
Can you clarify? :)
#54
in reply to:
↑ 53
@
9 years ago
Replying to folletto:
That said, I'm not sure what downside of i9 you're pointing at (apart your dislike for logos).
Can you clarify? :)
I need to load up the latest patch and count taps. Taps being equal, I have a visceral and emotional preference for the Dashboard and Home icon pairing over a persistent branded menu, especially on phones. I look at "Admin / Mobile for single site" in i9b thinking that W menu is clutter that need not be there. There's a branded junk drawer clanging through the ballet.
I'll give i9b and future patches a workout and try to come to terms with my branding distaste.
#55
@
9 years ago
i9 pairs the front-end "Dashboard" with the back-end "Home" which works well, and keeps the W as the same, stable, consistent menu across any size and device (of course, just disabled on the backend since it's already open). So should be already what you want too. :)
Just imagine the "W" as a "Menu" icon for the sake of neutral testing then. ;)
#56
@
9 years ago
I'm getting a W icon that will also be an admin menu actuator on small screens. On larger screens it will be a flyout that duplicates the admin menu below. Not sure how I feel about that.
fwiw, I like the consistency in having the same far left icon trigger the same menu no matter your location. In the i9b design, I think most people will be able to find their way between front-end and dashboard pretty easily, but I also can see a possibility of getting a little lost at the dashboard page if they don't figure out that the W triggers the wp-admin menu. We can test that!!
Stepping back a little, this is from the original ticket:
At the very least, for 4.3, we need to resolve the issue of mixing customizer links in with dashboard links.
It feels like we've gone way past the original request in this ticket with a whole lot of untested changes at once—things that could work out but will need testing to sort out. We could switch back to solving just the customizer links issue in 32678 and moving the i9b design to a feature plugin as ryan suggested. Slowing it down and testing it a lot more could really help.
The problem we need to solve first is that some links take you into the customizer context without warning.
Instead of replacing the comments link with a customize link in the bar, would you consider simply adding "Customize" as a main item in the left navigation in wp-admin pages to solve the stated problem? It might also help with the misconception that the customizer is meant to replace the appearance menu or be theme-related things only.
#57
@
9 years ago
The problem we need to solve first is that some links take you into the customizer context without warning.
However unfortunately today is inside a menu that replicates, and mixes, elements of the admin, which is why we split that into a clear 1:1 admin menu and a single customize button along the way of this discussion. I'm not sure how we could not do that and still solve the initial issue, but maybe it's just me. ;)
So in my perspective it's just that change that we are polishing, and it's already quite along the way in that polish. :)
Can we maybe just test this out once the changes above have a patch? ;)
#58
@
9 years ago
Replying to folletto:
i9 pairs the front-end "Dashboard" with the back-end "Home" which works well, and keeps the W as the same, stable, consistent menu across any size and device (of course, just disabled on the backend since it's already open). So should be already what you want too. :)
Just imagine the "W" as a "Menu" icon for the sake of neutral testing then. ;)
It'd still be a generic, catchall kinda menu. I like the Dashboard icon being The Menu. It has meaning and a nice icon. A same, stable, consistent menu doesn't solve problems I have. It's just more stuff in a drawer that follows me around. wordpress.com has a persistent, branded menu on the bar that I've used quite a bit. I prefer the Home, Dash pairing.
I'll relent after more testing. I appreciate i9b, but I'm hung up on what feels like losing the soul of the bar. I really, really like the Home, Dash pair.
#59
@
9 years ago
It'd still be a generic, catchall kinda menu. I like the Dashboard icon being The Menu. It has meaning and a nice icon. A same, stable, consistent menu doesn't solve problems I have. It's just more stuff in a drawer that follows me around. wordpress.com has a persistent, branded menu on the bar that I've used quite a bit. I prefer the Home, Dash pairing.
We're not creating a catchall.
We're showing WordPress's admin menu.
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.
Plus, we are also solving all the flow issues you mentioned above, even better than what's currently in core on mobile:
- Core = tap on dashboard icon → go to dashboard → tap then on menu → open sidebar menu → tap section
- This ticket = tap on W → open menu → tap section
So we're comparing 2 taps and 1 pageload vs 3 taps and 2 pageloads.
So we get:
- Less taps on mobile
- Less taps on desktop
- Unified navigation
- Clear customizer action
How can you say it's worse?
#60
@
9 years ago
Core = tap on dashboard icon → go to dashboard → tap then on menu → open sidebar menu → tap section
Yes, that should be fixed by putting Posts and other things in the Dashboard menu. I'm fully down with that. I've wanted that for a long time. We could patch and commit a fix for the Dashboard menu right now without argument from me. I don't really like having everything in there, but I'll take everything so long as I get Posts near the top.
#61
@
9 years ago
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.
#62
follow-up:
↓ 68
@
9 years ago
At this point let's try to focus on making suggestions relative to the latest patch rather than what's currently in core, to avoid rehashing the same discussions over again.
Current status is that we have awesome consistency with the admin menu accessible in the admin an front end on devices of all sizes, and the Customizer also being accessible but from a distinct top-level context, to avoid confusion. Now that all top-level admin menu links are available from the frontend, the need for the dashboard is greatly reduced. I'd love to even be redirected right to the front page by default when logging in, as the toolbar provides the context I want via contextual edit links, the Customizer link that contextually opens to the front-end page I was viewing, and one-click access to nearly all of the admin pages I'd want to get to directly. The net effect is that I expect to get distracted by reading things from the Planet feed much less frequently now, which is basically the only thing the dashboard does for me. That's a discussion for another ticket though.
The remaining issue I see here is determining the best way to handle links to the front page and dashboard. Would like to avoid having duplicated links going anywhere in any context.
In terms of icons, I'll reiterate that we should not use a brush of any sort for Customize because it implies that it's only a design tool. That's an assumption that we're actively fighting to move past, so introducing an icon that reinforces it would not be good strategically, even though it's quite nice visually. The Customizer is a framework for live-previewing any change to WordPress.
#63
@
9 years ago
https://make.wordpress.org/flow/2015/06/30/toolbar-visual-survey-4-3-alpha-33003-mac-and-chrome/
We need some more visual surveys of the existing toolbar, particularly for tablet.
#64
@
9 years ago
Survey of 32678.5.diff on an iPhone 6+.
http://make.wordpress.org/flow/2015/06/30/toolbar-survey-with-32678-5-diff-iphone-6/
#66
@
9 years ago
I'm working on toolbar flow visual records, starting with an iPhone 6+ and the production toolbar.
Flows:
- Starting on a post permalink page, tap the toolbar's edit icon, delete the post from the editor, come back to front.
- Starting on the front page, tap + icon in toolbar, publish a post, view the permalink page for that post, tap the toolbar's edit icon to make some changes to the post, update the post, come back to the post permalink page. Test chain editing.
- From the front page, go to posts list table in the admin, edit a post, go back to front.
- Starting on the front page, customize and come back.
- Starting on a permalink page, customize and come back.
- Starting on an admin page, customize and come back.
Help needed. Grab a device. This is necessary pre-commit diligence.
After I get a set of flow vizrecs for the production toolbar, I'll start doing them with the latest patch here. Then we can do flow comparisons.
https://make.wordpress.org/flow/tag/flow-comparison/
Although the vizrecs will be comparing against the production toolbar, I'll really be comparing against what the production toolbar would be with a fixed Dashboard menu and Home icon. That's my litmus.
This ticket was mentioned in Slack in #core-flow by boren. View the logs.
9 years ago
#68
in reply to:
↑ 62
@
9 years ago
Replying to celloexpressions:
At this point let's try to focus on making suggestions relative to the latest patch rather than what's currently in core, to avoid rehashing the same discussions over again.
Kindly refrain from telling leads how to approach problems.
#69
@
9 years ago
I need to post a new version of dashicons but am waiting on final call for the customize icon.
This ticket was mentioned in Slack in #core by helen. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by obenland. View the logs.
9 years ago
#72
@
9 years ago
Any of 2, 3, and 4 of the icons above work I think, in terms of adequately representing the Customizer.
My personal preference would be 2, then 4, then 3, not that that matters here. Also, voting to get a first-pass in for beta 1 to get broader feedbck, then further analyze and iterate from there as needed.
#73
follow-up:
↓ 76
@
9 years ago
- Type changed from enhancement to task (blessed)
I need to know what the path of least resistance is for 4.3, whatever is happening with this patch is nowhere near ready. All I care about for this release is not mixing up links into different contexts. My take is that a separate Customize menu, with or without a submenu, on both front and back, is enough for now. All other links in both toolbar AND admin menu should go to admin screens, with the exception of the customize link under appearance. This means deciding on an icon - let's please steer clear of anything remotely implying layout. I would rather a brush than anything along those lines.
I'm making this a task but it needs to happen ASAP or it's a punt. I wanted to prompt a holistic conversation but we do need to reel back into being pragmatic at this moment.
This ticket was mentioned in Slack in #design by celloexpressions. View the logs.
9 years ago
#75
@
9 years ago
- Owner set to helen
- Status changed from new to assigned
Do you want to discuss it during today's UI chat?
#76
in reply to:
↑ 73
@
9 years ago
Replying to helen:
I need to know what the path of least resistance is for 4.3, whatever is happening with this patch is nowhere near ready. All I care about for this release is not mixing up links into different contexts. My take is that a separate Customize menu, with or without a submenu, on both front and back, is enough for now. All other links in both toolbar AND admin menu should go to admin screens, with the exception of the customize link under appearance. This means deciding on an icon - let's please steer clear of anything remotely implying layout. I would rather a brush than anything along those lines.
Aye. I'll talk this through to make sure I'm on the right page. Putting Customize at top-level in the toolbar is the easiest and most direct way to avoid mixing contexts. To avoid all context mixing, we need Customize to be accessible from both front-end and back-end toolbars. Customize can't be in a submenu of Dashboard because Dashboard is only on the front-end toolbar and because having Customize and Appearance in the same menu is context mixing. So, top-level toolbar it goes.
That means adding another top-level without taking any other top-levels away (i9b removes Comments to make some room for Customize). This visual record shows production menus on an iPhone 6+ for both a single site and multisite install.
https://make.wordpress.org/flow/2015/06/29/toolbar-survey-iphone-6/
Here's single site on the smaller Nexus 5.
https://make.wordpress.org/flow/2014/07/07/the-guises-of-bar-nexus-5-4-0-alpha-20140706/
It'll be a bit cluttered with an extra top-level, but we can live with it for a release. And, I'm pretty sure we'll end up with Customize remaining top-level, so this addition is in the direction we're headed.
#77
@
9 years ago
The new Customize icon should be used for the Customize button (to toggle back from the preview) within the Customizer also (currently uses the appearance icon).
This ticket was mentioned in Slack in #core by obenland. View the logs.
9 years ago
#80
follow-up:
↓ 81
@
9 years ago
Does one of these patches "just" add a top-level Customize link and switch the links in the existing dropdown to be admin-only (or remove ones that can't go into the admin)?
#81
in reply to:
↑ 80
@
9 years ago
Replying to helen:
Does one of these patches "just" add a top-level Customize link and switch the links in the existing dropdown to be admin-only (or remove ones that can't go into the admin)?
No, that scope was never really discussed initially on-ticket so it went right to the admin menu markup implementation. The menu addition can be extracted from any of the patches and then the links pointed to the alternate locations in a new patch.
#82
@
9 years ago
- Milestone changed from 4.3 to Future Release
- Type changed from task (blessed) to enhancement
Spun off the small part I think we can/should tackle in 4.3 to #32924. Let's keep on this, though, possibly in a plugin to test out bigger changes both in terms of content and things like a11y (#32495) and Menu Aim (#23731). This would also give us a chance to take a good hard look at how we can even access the horrid thing that is the admin menu without feeling like our hands are tied because of time.
#83
@
9 years ago
I feel the latest proposal i9b above is solid and can be tested as-is once a patch lands that in entirely.
Once we have tests results we can see if and where we need to go next. :)
This ticket was mentioned in Slack in #core by boren. View the logs.
9 years ago
This ticket was mentioned in Slack in #design by helen. View the logs.
9 years ago
#87
@
9 years ago
Here are a couple of toolbar flows I had laying around. Creating and then chain editing a post with front to back to front movement is a flow I use pretty often on phones.
#89
follow-up:
↓ 164
@
9 years ago
On the topic of networks with dozens of WordPress sites... it would be terrific if something like Kailey Lampert's My Sites Search plugin could be considered for the My Sites dropdown. Right now you're limited to 16-25ish sites displaying, depending on screen size and it's a hassle to change Dashboards unless you know the Site ID or URL.
#90
@
9 years ago
I agree, some kind of top-search that appears when there are more than N sites would be very good there. Regardless, that should be scrollable properly, still. ;)
This ticket was mentioned in Slack in #core by swissspidy. View the logs.
9 years ago
This ticket was mentioned in Slack in #design by celloexpressions. View the logs.
9 years ago
#93
@
9 years ago
I ported 32678.5.diff to plugin form and pushed it to https://github.com/helenhousandi/wp-toolbar-experiments. It needs some CSS cleanup still but is almost ready for testing and further iterations. Let's focus development on GitHub/with the plugin for now, then bring it back to this ticket once we're happy with the result. If someone could set the plugin up on .org & beta plugins list, and get the auto-sync from GitHub going there, that would be great for facilitating testing.
If we start working on this again now, we should be able to get it ready for 4.4.
This ticket was mentioned in Slack in #design by celloexpressions. View the logs.
9 years ago
#95
@
9 years ago
Let's revisit this. I think there was a fair bit of consensus on the approach prior to reaching beta for 4.3, but some larger questions and thoughts of doing a broader refresh of the toolbar beyond its contents seems to have caused the perception of enough effort required for us to skip an entire release cycle in terms of any movement here.
Do we want to continue iterating on wpadmin-bar-concept-i9b.png? Can we focus on content and navigation, and define secondary changes such as markup, accessibility (beyond things directly caused by changes here), dealing with lots of site on multisite, etc. as things that should be handled by other tickets? Should work continue on this ticket, or do we want to switch over to the feature plugin mentioned above for the time being? Is someone willing/able to work on user testing the proposed changes?
I'll note that the patch and plugin likely need some refreshing, but let's decide on how we want to go about this first.
Personal thoughts after revisiting this a bit:
- Access to the top-level admin menu from the front end is incredibly useful, esp. with unified design + icons
- The notification bubble is a nice touch
- Flow seems improved for both desktop and mobile
- Redefining the purpose of the W icon works nicely, but we may need to consider whether that's a concern if people are trying to mask the fact that the site's running WordPress by hiding this CMS branding (or whether we care). Regardless, it's nice to lose those links and that submenu
- Need to figure out site vs. sites menu hierarchy for multisite
#96
@
9 years ago
I agree, i9b is the most solid proposal there, and I feel it works really well.
Need to figure out site vs. sites menu hierarchy for multisite
I have a couple of ideas, working on these. I'll try to post something here asap. :)
#97
@
9 years ago
Ok I added a unified concept, i10, that has a solution for multisite and polish a little more the single-site navigation too. I think it's a rather solid idea, that optimizes desktop and mobile alike.
This ticket was mentioned in Slack in #core by morganestes. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
9 years ago
#102
@
9 years ago
@folletto should this be forked into a task so we can start planning? I'd like to start working on this and some related tickets that can become part of the updated toolbar.
#103
@
9 years ago
- Keywords needs-refresh added
@morganestes I know I converted most of the latest patch into the plugin that @helen started on github, so that may be a good place to start. Once it's updated and polished it could be re-patchified, potentially as more of a plugin merge with other changes. The underlying admin bar api lends itself fairly nicely to hooking in how we would need to. I probably won't have much time to work on it this cycle, so it would be great if you could pick it up!
#104
follow-up:
↓ 105
@
9 years ago
@celloexpressions do you know the github repo url for the plugin?
#105
in reply to:
↑ 104
@
9 years ago
Replying to voldemortensen:
@celloexpressions do you know the github repo url for the plugin?
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
9 years ago
#109
@
9 years ago
It looks like this ticket is on a stand still.
I am thinking of e-mailing plugin developers who are working on similar projects but need to know what still needs to be done. What is needed to get this ticket moving again?
#110
@
9 years ago
An interesting plugin:
https://wordpress.org/plugins/admin-bar-plus/
It has a very nice drop down in the frontend linking to the various sections in the backend.
This ticket was mentioned in Slack in #design by paaljoachim. View the logs.
9 years ago
#112
@
9 years ago
IMO we should add Active Plugins with the dropdown that will contain the list of the plugins that have their own Menu Position. This should be convenient if the client has a lot of the plugins active.
#113
@
9 years ago
Absolutely. As I mentioned above:
I'd personally suggest to keep (if possible, of course, maybe even post 4.3) the back-end and front-end navigations identical.
The keyword there is identical.
Which means loading all the menu changes from the plugins too. :)
I should have noted that in the mockup probably. ;)
#114
@
9 years ago
We need to rethink the way it gets the plugins that are installed on Admin Bar+, now it is only looking for 2 specific plugins (revslider & woocommerce) if they are installed and shows them in the list.
#115
@
9 years ago
Ideally, it should be the same API as adding admin menu items, so I guess add_menu_page()
, add_options_page()
and similar. In that way it would ensure that the two menus are identical. I guess however the problem there is that these are called only in the admin area? So not on the front-end? That's why I suggested to start first with the pure "default" menu as the first iteration to land in Core, which would be already a huge step forward, and then find a way later to make the two identical even for plugins. :)
This ticket was mentioned in Slack in #core-multisite by paaljoachim. View the logs.
9 years ago
#117
@
9 years ago
I made a plugin that covers the first main section:
The Frontend - has all the major sections.
#118
@
9 years ago
About #comment:115
Yes, definitely the API should be the same. And now, let's say you have 45 menu items in frontend, which is cool, but you want to quick access only 16 of them through the frontend.
We could simply add a setting to disable menu items in frontend - Something with checkboxes for all menu items, and when you mark a checkbox it disables the menu item for the frontend.
#119
@
9 years ago
I feel what you're describing is plugin territory if this feature lands :)
I think it's important that front and back are identical, zero difference. Otherwise it would take away the important bit of this very feature, having a consistent navigation back and front.
#120
@
9 years ago
It seems natural to have this feature in stages.
Stage 1 - Add the drop down in the frontend that includes a list of the backend admin pages. + whatever else is ready right now. So that we can have stage 1 included into 4.5.
#121
@
9 years ago
I agree, there's not need to expand further the scope here. This ticket is about the concept i10 above, and further refinement as needed after we test it. :)
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
9 years ago
This ticket was mentioned in Slack in #design-dashicons by paaljoachim. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by helen. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-multisite by paaljoachim. View the logs.
9 years ago
#127
@
9 years ago
Hi all, I'll make a patch based on this https://github.com/helen/wp-toolbar-experiments
Although I'm currently load styles (ONLY) from a plugin, it currently looks like this:
Anyone knows what changed in the latest versions of WordPress and causes this? I'm sure it's just a css conflict but need some opinions.
Also a question about css as I'm new to WordPress Core, WordPress loads the minified files, what's the best practice, where do I make the changes?
#128
@
9 years ago
@kosvrouvas 32678.5.diff is a better starting point than the plugin - the plugin was derived from that but has some issues such as the one you pointed out above. You don't need to patch the minified files - they're generated automatically. To force use of unminified scripts, define( 'SCRIPT_DEBUG', true );
in wp-config.php.
The patch only needs a few tweaks to match the wpadmin-bar-concept-i10.png concept that we seem fairly agreed upon (see also 50). But I think the bigger thing that @helen wants explored is how to better integrate the admin menu with the admin bar on a technical level. My preference would be to lean more on the admin bar API than the admin menu "API", since it's structured better, but not sure how exactly those could be merged best. There are also some related changes besides the changes to toolbar contents that have been proposed, but I'm not sure whether or not it makes sense to hold off on the content changes for that.
#129
@
9 years ago
Yes. Design wise i10 is the one we iterated to, and it's currently the agreed candidate to get to a prototype stage. :)
Great to see work on this picking up again! Kudos!
This ticket was mentioned in Slack in #core-multisite by paaljoachim. View the logs.
9 years ago
#132
@
9 years ago
I merged the patch you mentioned and continued from there, although CSS neeps a bit of work and I need help on that, only because I don't want to mess up the WordPress CSS standards.
Also I don't know if you want to follow a different method (api menu etc)
Should I make a patch and for someone to continue from this?
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by folletto. View the logs.
9 years ago
This ticket was mentioned in Slack in #design by folletto. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.
8 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
7 years ago
#141
@
7 years ago
Quick note - I've been using the plugin version of this for years now and it's great. If we can consider making the changes here without completely reworking the admin menu API, that's probably the best way for this project to get un-stuck.
#142
@
7 years ago
It would be amazing if we could push this forward, I agree. Having an API change would be ideal, but short of that the end goal here is an improved navigation experience across backend and frontend, and on mobile.
I tested the plugin too and apart from some fixes (color, hover, mobile view still has the dashboard icon, etc), from a UI point of view feels already an improvement. I haven't tested on multisite tho.
#143
follow-up:
↓ 146
@
7 years ago
Perhaps we could get an update as to what is still needed to get this in place?
How can we get there?
This ticket was mentioned in Slack in #core-customize by paaljoachim. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
7 years ago
#146
in reply to:
↑ 143
@
7 years ago
Replying to paaljoachim:
Perhaps we could get an update as to what is still needed to get this in place?
How can we get there?
If @helen is okay with exploring an initial core implementation that does not rewrite the admin menu API, then then next step would be for someone to clean up the CSS in the plugin and start encouraging testing and user testing for feedback. It could likely use additional work to ensure that the multisite experience is improved.
https://github.com/helen/wp-toolbar-experiments or 32678.5.diff are starting points.
Key question: are we okay with iterative improvements to work toward an idealized eventual solution, or do we want to tackle everything (content, appearance, interaction, multisite, API, etc.) at once? My preference is to focus on the content as outlined in wpadmin-bar-concept-i10.png first and then continue making iterative improvements to other aspects.
This ticket was mentioned in Slack in #core-multisite by paaljoachim. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by swissspidy. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by danieltj. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by swissspidy. View the logs.
7 years ago
#152
@
7 years ago
I've got an initial version of the design worked out into a plugin. If we can get this in as a feature plugin and go from there, hopefully we can reboot this project and get it into Core at some point. I'll update the ticket with information when I can.
-
I've attached a screenshot of the plugin based on the designs created above. Of course this is a work in progress but hopefully something we can move forward with from here.
This ticket was mentioned in Slack in #core-committers by danieltj. View the logs.
7 years ago
#154
@
7 years ago
Thanks for pushing this forward! :)
Can you do a quick breakdown of the state of the plugin you have... and where it is? :D
#155
@
7 years ago
Hi @folletto, so I'm currently waiting on @helen to see if she's okay with me taking this over.
I've created a plugin based on the designs above (as mentioned already) and it's available on GitHub to test right now. It's also approved in the plugin directory but I haven't had a chance to upload anything just yet. I'll do that tomorrow though.
GitHub repo is here: [edit]
(Quick edit: the plugin is located here: [edit]).
Some things to note:
- Works on single & multi site installations
- Multi sites 'site drop down' has been removed and needs adding back in
- Some other links have also been removed such as the themes, menus and widgets and replaced with the new drop down.
- Plugin currently has no filters or action hooks yet, that's to be worked out.
Not technically plugin territory:
- I'd like to have a new Slack channel created for this as it's a pretty big project (#feature-toolbar).
- Hopefully with anyone who is interested, I'd like to lead this feature project.
- New ideas and support with this is very welcome, please help me! :)
That's about it for now, thanks!
#156
@
7 years ago
- Owner changed from helen to danieltj
Hi again, just another update to say that I've rewritten the whole plugin so it now relies on a new Toolbar API and looks a little different. Version 2.0 seems to be stable from the testing I did but I'd like some more volunteers!
I spoke to Helen on Slack and it seems this might need a bit more work and organisation to kick-start this again. I was thinking we could perhaps get a meeting on Slack going and figure out where we want to head with this.
Anyway, version 2.0 is available (links above). Would love some feedback on it.
DM me in Slack if you're interested in a Toolbar meeting. We could probably do with a Toolbar specific channel really, all things considered so I'll try and figure that out too. Thanks!
#157
follow-up:
↓ 158
@
7 years ago
version 2.0 is available (links above).
Question: can we rename the plugin name from "Toolbar" to something more meaningful and easier to search, like "Toolbar Unification Experiment" or something like that?
Also "2.0" seems a tall order for something still in beta, no? Maybe "0.2"?
I worry people downloading an in-progress design expecting something done and fully working.
Would love some feedback on it.
At which level do you want feedback? In general, I'd consider reviewing it against the latest approved design above, iteration i10, and it's still fairly different even as a cursory review.
Should I go in detail, or are you ok aligning the design first (both desktop and mobile)?
Are you testing on multi-site too?
#158
in reply to:
↑ 157
@
7 years ago
Question: can we rename the plugin name from "Toolbar" to something more meaningful and easier to search, like "Toolbar Unification Experiment" or something like that?
I think the name is okay as is, it seems descriptive enough, no?
Also "2.0" seems a tall order for something still in beta, no? Maybe "0.2"?
I worry people downloading an in-progress design expecting something done and fully working.
The current version (2.0) is a work-in-progress and overhaul which uses elements of i10 but served as a personal test to see how far we can go with rewriting the Toolbar. So the version number is arbitrary really at the moment.
At which level do you want feedback? In general, I'd consider reviewing it against the latest approved design above, iteration i10, and it's still fairly different even as a cursory review.
I think the best thing is to get some Slack meetings going and reviewing the state of the ticket and project as a whole. I'd like to get a Slack channel set up for this though to conduct meetings. I'll try and get this sorted. The designs look great (I'm happy with them, 100%), but as this is somewhat of a refresh, let's get some opinions on how to move forward.
Should I go in detail, or are you ok aligning the design first (both desktop and mobile)?
3.0 would need to be released to fully align with i10 design, not only because of code changes but also because my playing around with the current version (2.0) that goes off the original designs is GPL v3, so we'd need to do a major release/rewrite to bring it to GPL v2.
Are you testing on multi-site too?
Yes, absolutely. v1 didn't support it (but follows design i10 closer than v2), but v2 does support multisite.
This ticket was mentioned in Slack in #slackhelp by danieltj. View the logs.
7 years ago
#160
@
7 years ago
I think the name is okay as is, it seems descriptive enough, no?
"Toolbar" is very generic, and doesn't tell what it does. Even just searching for it is hard. Let's change it to the above or anything else that is meaningful and descriptive of the change this project brings in.
work-in-progress [...] So the version number is arbitrary really at the moment.
Exactly, that's why I suggested to switch to a 0.x versioning. "2.0" sends a very different message from "work in progress".
I'm not sure if it's possible given it's already recorded as 2.0 now in the plugin directory, but if possible let's change to 0.1 or 0.2 in the next release.
I'll try and get this sorted.
Ok. :)
would need to be released to fully align with i10 design
Ok thanks for the clarification. Let's review once the alignment is done. :)
does support multisite.
Super. :)
#161
@
7 years ago
- Owner changed from danieltj to helen
I'm assigning this back to @helen as due to personal commitments I'm no longer going to continue working on this project and developing the plugin further.
This ticket was mentioned in Slack in #design by afercia. View the logs.
6 years ago
#164
in reply to:
↑ 89
@
5 years ago
- Focuses javascript multisite added
- Version set to 5.3.2
Replying to dryanpress:
On the topic of networks with dozens of WordPress sites... it would be terrific if something like Kailey Lampert's My Sites Search plugin could be considered for the My Sites dropdown. Right now you're limited to 16-25ish sites displaying, depending on screen size and it's a hassle to change Dashboards unless you know the Site ID or URL.
It's surprising that 5 years later, there's no core fix to the sites list issue. Thanks for this link, glad this solution still works.
@folletto has some mockups and we discussed this at length in Slack.