Please follow post-commit follow up activity here: #1846970: [meta] Responsive Toolbar follow-ups
This issue is too long to be loading frequently.
In Drupal 8, navigating as an administrative user on a cell phone looks like this:
You can find many different depictions of the general rise of mobile that's exploding all over the world. The mobile initiative is one of the strategic initiatives for Drupal 8. It's not acceptable to ship Drupal 8 like this.
After numerous rounds of prototyping and more prototyping and revision after revision after revision of the design based on community feedback and usability testing, the current design (as of 2012-10-27) looks like this:
(See http://invis.io/PK83F76X for a clickable version)
On a mobile device, the toolbar extends vertically down the page, showing the top-level navigation by default (Content, Structure, and so on) along with icons (implemented by scalable SVG vector images that both a) scale to any screen dimensions, and b) are simply a CSS override away from customization) and arrow symbols that allow people to drill down further into the navigation.
When drilling down, the navigation looks like this:
9 levels of navigation are supported, which is the maximum that the menu system supports.
Support of "drill-down" is an important facet of the mobile design; it's incredibly annoying on a mobile device to have to click 1, 2, 3, 4... or more levels deep in order to get from where you are now to one level above.
Similarly, the icons are an important facet of the design; they are used to communicate key items in the top-level bar where there is not enough space to put textual descriptions of everything.
In horizontal / desktop mode, only the top-level navigation items are shown (parity with current D7 & D8 toolbar), rather than the sub-navigation, in order to defer discussion about what to do about drill-down on desktop to a follow-up issue (e.g. leave as-is, or do what Admin Menu does, or...)
The orientation switching implementation hooks off a configurable breakpoint from the Breakpoint module that was added to Drupal 8 recently. When the width of the viewport exceeds a given size, the orientation flips to horizontal instead (although there are icons on the far right that can be used to toggle horizontal vs. vertical orientation manually, if one so chooses).
The desktop orientation also better exposes the idea of the "action zone" of the toolbar (the black part) where modules such as Shortcut, Menu, User, and Search (shown) can expose their own things to add to the toolbar. In mobile view these will collapse down to just an icon.
By far, the biggest thing that puts this issue in peril of being solved before feature freeze is continued disagreement over the spec and design. The issue has yet to even receive a single "needs review" patch because of this constantly changing spec, despite having been worked on and iterated on for over 2 months. Community consensus is not yet achieved, and it is quite clear that it cannot be achieved in time for feature freeze, allowing time for a workable patch that passes code review by then. Every moment that we spend arguing in this issue trying to achieve design perfection is a moment we are not spending getting "real world" user experience that could help inform further design changes on the basis of data, rather than opinions. Therefore, the recommendation from the folks working on this is to eliminate any critical design blockers ASAP, so that it can be iterated on based on feedback from more than the handful of people active in this issue. There remains disagreement on what "critical design blockers" are, however.
At the moment, here is my (webchick)'s best read of the situation, and is NOT guaranteed to be correct, but here it is:
Before the patch can be committed
- Get to "I can live with this" on the design (not perfection) so we can freeze the spec. At the moment, the biggest blocker to achieving this seems to be getting the horizontal navigation to show the top-level navigation only, without sub-navigation, which would allow us to save discussion on how this should be done for a follow-up.
- Get a "needs review" patch up once the spec is locked down (all patches to-date have been "needs work" as they were merely prototyping the design for feedback).
- An in-depth code review of said patch, including for JS/CSS standards, documentation standards, customizability, etc.
- Accessibility review to ensure there are no critical regressions.
- Caching strategy for performance: #1814932: Caching strategy for D8 toolbar
- Dependency: #1815602: Introduce a polyfill for matchMedia
After the patch is committed
Likely numerous spin-off issues, based on how users react to the toolbar when interacting with it on a daily basis, possibly including:
- Evaluation on "how deep is deep" in terms of the menu (e.g. deciding whether to include "local tasks" such as add/edit/view, as Admin Menu does). See #1811998: Decide which local tasks to add to toolbar navigation and #1812016: Does usability testing show any value of going more than 2 deep? where this is being discussed.
- Evaluation on whether or not the entire menu item itself (versus just the arrow next to it) should expand down to the next level in vertical mode.
- Implement the jump bar: #1781422: Implement the auto-complete menu jumpbar in the responsive core toolbar update, and evaluate at that point on whether or to keep it separate or merge with the search bar.
- Evaluation on whether or not to add Admin Menu-esque fly-outs make sense for the desktop experience, or if we should keep to top level only
- Evaluation on whether or not styling changes need to occur (e.g. icons, colours)
- Probably lots of other things, too, that we can't even imagine until we get 100s of people testing this. This list will be expanded as they come up in discussion below.
The bottom line: we are not going to get this right in one shot. So let's figure out together what we must do to get it in core, so we can then focus on getting it really right in several more shots. :D
User interface changes
// TODO, based on final spec.
Ongoing development work is taking place in a sandbox project.
Normally the branch will be node/1137920-responsive-toolbar,
but until the CTools Dropbutton issue [node/1608878] is resolved, we'll be working in node/1137920-responsive-toolbar-with-dropbutton-patch where the latest patch will be committed to the branch to enable development on it. Commits to the branch with the dropbutton patch will be cherry-picked to the node/1137920-responsive-toolbar branch on a rolling basis.
Please contact jessebeach for further details.
Pre-code freeze tasks
#1814932: Caching strategy for D8 toolbar
#1834822: Reestablish test coverage of the toolbar module that was disrupted by mobile update work
#1827296: Mark up the currently active menu trail in the menu list
#1827284: Preserve the open state of the toolbar for individual users across page loads
#1827302: Preserve the orientation state of the toolbar for individual users across page loads
#1830526: Toolbar module should implement and document its own hooks.
#1827330: Fix overlay placement which is broken in the current D8 ToolBar patch
#1782576: Remove the toolbar drawer and move the shortcuts to the toolbar tray
Post-code freeze follow-on tasks (ordered by priority)
#1827318: Fix tableheader placement which is broken in the current D8 ToolBar patch
#1847084: Measure/track displacing elements better + provide change events for them (fix overlay + toolbar)
#1839514: Establish test coverage for toolbar module.
#1829532: Implement RTL styling
#1829326: Convert Overlay to leverage core breakpoints and media queries to determine its presence and styling
#1781422: Implement the auto-complete menu jumpbar in the responsive core toolbar update
#1811998: Decide which local tasks to add to toolbar navigation
#1781402: Prototype the responsive navbar flyout menus
#1847116: Provide users with an easy-to-access action to create content from the toolbar
#1772724: Remove most of toolbar things and put that in shortcut
#1260800: Kill the overlay for widths below 640 pixels
#1805054: Cache localized, access filtered, URL resolved, (and rendered?) menu trees
#1812016: Does usability testing show any value of going more than 2 deep?
#787940: Generic approach for position:fixed elements like Toolbar, tableHeader
Original report by lewisnyman
- It must not interrupt any mobile navigation solutions produced by the front facing theme.
- It must still work when the front facing theme is not mobile friendly
- A link to the /admin page, utilize the available space for action buttons. (Prototype)
- The Left Nav Flyout ala Facebook. Also comes with gestures and a stacked cards metaphor. (Prototype)
- Tap button to slide down (Twitter bootstrap) Also see dodoramas demonstration.
- Pull down for navigation
I'm proposing we:
- Move the markup for the toolbar to the bottom of the screen — This won't affect the current design anyway as it is fixed.
- Unfix it from the viewport — it takes up too much real estate and is known to cause issues with mobile browsers.
- Give each item full width of the screen similar to jQuery Mobile UI
- Increase the height of each toolbar item to play nice with fat fingers.
- Add a "Skip to nav" link at the top that shoots down to the toolbar at the bottom of the page.