Notice

Please follow post-commit follow up activity here: #1846970: [meta] Responsive Toolbar follow-ups

This issue is too long to be loading frequently.

Problem/Motivation

In Drupal 8, navigating as an administrative user on a cell phone looks like this:

Everything is smooshed.

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.

Proposed resolution

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)

Mobile
Mobile version shows in vertical orientation

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:

Drill-down vertical orientation view showing sub-navigation.

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.

Desktop
Toolbar in horizontal mode.

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.

Remaining tasks

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:

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

See above.

API changes

// TODO, based on final spec.

Development

Ongoing development work is taking place in a sandbox project.

http://drupal.org/sandbox/jessebeach/1749042

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.

Dependencies

#1815602: Introduce a polyfill for matchMedia

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: Expand test coverage for Toolbar module: test a top-level tab without a tray
#1829532: Implement RTL styling
#1829326: Convert Overlay to leverage core breakpoints and media queries to determine its presence and styling
#1781422: Add search/jump/command functionality to toolbar
#1811998: Decide which local tasks to add to the toolbar menu tray — mimick D7 admin_menu?
#1781402: Prototype the responsive navbar flyout menus
#1847116: Provide users with an easy-to-access action to create content from the toolbar

Related issues

#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

Solution requirements

  • 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

Potential Solutions

I'm proposing we:

  1. Move the markup for the toolbar to the bottom of the screen — This won't affect the current design anyway as it is fixed.
  2. Unfix it from the viewport — it takes up too much real estate and is known to cause issues with mobile browsers.
  3. Give each item full width of the screen similar to jQuery Mobile UI
  4. Increase the height of each toolbar item to play nice with fat fingers.
  5. Add a "Skip to nav" link at the top that shoots down to the toolbar at the bottom of the page.
CommentFileSizeAuthor
#326 1137920_responsive-toolbar_325.patch113.92 KBjessebeach
#326 interdiff.txt16.87 KBjessebeach
#316 IE8-Vertical dropdown.JPG29.27 KBShyamala
#310 ie8_horizontal_toolbar.PNG100.31 KBShyamala
#308 ipad_landscape_verticalmenu_accountsettingspage.PNG92 KBShyamala
#308 ipad_landscape_verticalmenu_extendpage.PNG93.52 KBShyamala
#308 ipad_landscape_verticalmenu_findcontentpage.PNG84.86 KBShyamala
#308 ipad_landscape_verticalmenu_peoplepage.PNG97.39 KBShyamala
#308 ipad_landscape_verticalmenu_regionalsettingspage.PNG94.58 KBShyamala
#305 1137920_responsive-toolbar_305.patch113.31 KBjessebeach
#303 1137920_responsive-toolbar_303.patch113.28 KBjessebeach
#303 interdiff.txt12.1 KBjessebeach
#301 1137920_responsive-toolbar_301.patch108.73 KBjessebeach
#301 interdiff.txt16.61 KBjessebeach
#299 Text_size_toolbar.PNG90.38 KBmbrett5062
#299 FF_ugly.PNG80.34 KBmbrett5062
#299 FF_Pretty.PNG81.12 KBmbrett5062
#297 1137920_responsive-toolbar_297.patch102.08 KBjessebeach
#297 interdiff.txt3.44 KBjessebeach
#293 1137920_responsive-toolbar_293.patch100.96 KBjessebeach
#293 interdiff.txt17.2 KBjessebeach
#291 bad.png2.56 KBdanillonunes
#291 good.png2.53 KBdanillonunes
#290 9-levels-without-coloring.png28.23 KBjessebeach
#290 9-levels-with-coloring.png32.97 KBjessebeach
#290 interdiff.txt95.79 KBjessebeach
#290 1137920_responsive-toolbar_290.patch104.81 KBjessebeach
#287 Chrome-Shortcuts-Toolbar-Broken.JPG10.42 KBShyamala
#287 Chrome - 250px - sub menu below config misaligned.JPG21.98 KBShyamala
#287 ipad - landscape - wide expanded menu.PNG63.37 KBShyamala
#287 ipad - landscape - wide expanded menu2.PNG78.19 KBShyamala
#287 ipad - potrait - wide expanded menu.PNG51.08 KBShyamala
#286 firefox.png37.84 KBeigentor
#286 Alignment.png38.38 KBeigentor
#286 Galaxy-Nexus-Jelly-Bean.png106.67 KBeigentor
#284 1137920_responsive-toolbar_284.patch104.58 KBjessebeach
#284 interdiff.txt58.3 KBjessebeach
#282 interdiff.txt10.02 KBjessebeach
#282 1137920_responsive-toolbar_282.patch98.92 KBjessebeach
#281 Scroll in chrome.JPG33.84 KBShyamala
#280 1137920_responsive-toolbar_280.patch95.89 KBjessebeach
#280 interdiff.txt18.85 KBjessebeach
#272 horizontal_scrolling.png25.05 KBbenjifisher
#271 toolbar-icons-left-padding-before.png4.13 KBjessebeach
#271 toolbar-icons-left-padding-after.png4.2 KBjessebeach
#271 ff-final-break-no-tools.png21.3 KBjessebeach
#271 ff-final-break-with-tools.png25.86 KBjessebeach
#271 1137920_responsive-toolbar_271.patch94.29 KBjessebeach
#271 interdiff.txt2.52 KBjessebeach
#269 mobile-nav-target.jpg22.94 KBdodorama
#264 Narrow_FF_Fail.PNG102.85 KBmbrett5062
#264 Before_final_collapse.PNG116.58 KBmbrett5062
#264 Breakpoint_where_page_is_displayed.PNG163.52 KBmbrett5062
#264 Chrome_reports_client_width_without_scrollbar.PNG111.37 KBmbrett5062
#264 phone_landscape.jpg1.42 MBmbrett5062
#264 phone_portrait.jpg1.88 MBmbrett5062
#262 interdiff.txt1.42 KBjessebeach
#262 1137920_responsive-toolbar_258.patch93.83 KBjessebeach
#245 interdiff.txt8.41 KBjessebeach
#245 1137920_responsive-toolbar_245.patch93.35 KBjessebeach
#244 menu-centre.png29.66 KBMustangGB
#238 First_Open_horizontal.PNG65.92 KBmbrett5062
#238 Vertical_IE10092_FF1602_GC23012.PNG66.44 KBmbrett5062
#233 core-toolbar-1137920-233.patch90.39 KBnod_
#233 interdiff.txt22.57 KBnod_
#232 android_potrait.JPG86.25 KBShyamala
#232 android_landscape.JPG77.37 KBShyamala
#232 iphone_potrait.PNG89.54 KBShyamala
#232 iphone-landscape.PNG81.23 KBShyamala
#229 toolbar-formatting.png39.87 KBwebchick
#229 toolbar-vertical-sub.png11.45 KBwebchick
#227 1137920_responsive-toolbar_227.patch94.58 KBjessebeach
#227 interdiff.txt20.39 KBjessebeach
#220 interdiff.txt31.74 KBjessebeach
#220 1137920_responsive-toolbar_220.patch93.01 KBjessebeach
#216 1137920_responsive-toolbar_216.patch90.96 KBjessebeach
#216 interdiff.txt9.64 KBjessebeach
#206 toolbar-scroll.png35.59 KBbenjifisher
#212 ie9.png150.43 KBcorbacho
#212 ie8.png37 KBcorbacho
#212 Capture2.PNG3.19 KBcorbacho
#210 1137920_responsive-toolbar_208.patch85.4 KBjessebeach
#210 interdiff.txt1.91 KBjessebeach
#207 ipad-potrait.JPG31.84 KBShyamala
#207 ipad-landscape.JPG41.78 KBShyamala
#205 1137920_responsive-toolbar_205.patch88.07 KBjessebeach
#191 toolbar-user-orientation-toggle.png55.36 KBjessebeach
#184 toolbar-210px-wide.png18.29 KBjessebeach
#184 toolbar-210px-wide-submenu.png17.2 KBjessebeach
#184 toolbar-320px-menu-open.png19.25 KBjessebeach
#184 toolbar-650px-menu-open.png49.27 KBjessebeach
#184 toolbar-800px-menu-open.png27.78 KBjessebeach
#184 toolbar-800-shortcuts.png22.59 KBjessebeach
#184 toolbar-400-shortcuts.png18.46 KBjessebeach
#184 toolbar-600-shortcuts.png25.27 KBjessebeach
#184 1137920_responsive-toolbar_184.patch133.2 KBjessebeach
#172 toolbar-horizontal.png206.52 KBwebchick
#167 icon_left.jpg154.89 KBcorbacho
#167 whole_button.jpg53.6 KBcorbacho
#164 Google.gif219.19 KBcorbacho
#164 fb.gif1.21 MBcorbacho
#164 atrium.gif653 KBcorbacho
#163 toolbar-switcher.png.png8.48 KBry5n
#159 2nd-review.png48.06 KBBojhan
#153 toolbar-vertical-flaw.png255.28 KBsun
#151 toolbar-horizontal-design-flaw.png61.98 KBsun
#150 toolbar-horizontal-open.png27.62 KBjessebeach
#150 toolbar-horizontal-closde.png22.67 KBjessebeach
#150 toolbar-closed-narrow.png22 KBjessebeach
#150 toolbar-open-narrow.png21.28 KBjessebeach
#150 1137920_responsive-toolbar_150.patch121.39 KBjessebeach
#150 toolbar-horizontal-subnav-open.png38.45 KBjessebeach
#150 toolbar-narrow-open-subnav-open.png45.15 KBjessebeach
#149 desktop-vs-toolbar-1.png46.36 KBwebchick
#148 mock.png35.75 KBBojhan
#139 horizontal-toolbar-d8ux.png84.02 KBBojhan
#126 1137920_responsive-toolbar-126.patch67.63 KBeffulgentsia
#126 interdiff.txt2.72 KBeffulgentsia
#119 toolbar-mobile-1137920-119.patch1.6 KBDavid_Rothstein
#119 mobile-page-load.png34.21 KBDavid_Rothstein
#119 mobile-after-clicking-administer.png33.46 KBDavid_Rothstein
#117 D7 toolbar at 608px wide-2.png19.85 KBjessebeach
#117 screenshot-of-d7-site-at-50em-width.png45.97 KBjessebeach
#117 screenshot-of-d7-toolbar.png11.51 KBjessebeach
#117 screenshot-of-googleplus-sidetray.jpg14.72 KBjessebeach
#117 vertical-menu-presentation-in-Google-plus.png59.13 KBjessebeach
#117 word-press-vertical-menu.png47.78 KBjessebeach
#114 1137920_responsive-toolbar-114.patch65.81 KBwebchick
#97 Screenshot_2012-10-04-09-18-03.png85.4 KBcosmicdreams
#97 Screenshot_2012-10-04-09-20-21.png103.68 KBcosmicdreams
#79 drupal-drupal-7-toolbar-on-iphone.png114.07 KBjessebeach
#70 1137920_responsive-toolbar_69.patch89.33 KBjessebeach
#70 toolbar-mobile-phone-not-high-enough.png104.89 KBjessebeach
#70 toolbar-actions-zone-2.png36.49 KBjessebeach
#69 drupal8-mobile-patch-applied.png40.61 KBBojhan
#69 d8-mobile-menu-targets.png47.54 KBBojhan
#69 image-styles-configuration-on-mobile.png58.54 KBBojhan
#59 1137920_responsive-toolbar_59.patch60.26 KBjessebeach
#48 Admin,_content,_structure_level_6.jpg108.9 KBjessebeach
#48 Admin,_content,_structure_flyout_2.jpg101.33 KBjessebeach
#40 1137920_responsive-toolbar_40.patch83.32 KBjessebeach
#36 Screen Shot 2012-08-27 at 4.42.42 PM.jpg18.76 KBjessebeach
#35 analysis-combnied.jpg103.53 KBBojhan
#35 admin-nav-mobile-slideout.jpg65.11 KBBojhan
#35 navigation-2.jpg58.08 KBBojhan
#34 dashboard_tablet_vertical.png335.73 KBwebchick
#32 Screen shot 2012-08-20 at 5.17.47 PM.png14.28 KBtkoleary
#32 Screen shot 2012-08-20 at 5.18.02 PM.png18.03 KBtkoleary
#12 toolbar-expanded.png47.17 KBdodorama
#12 toolbar-collapsed.png63.39 KBdodorama
#6 android-dolphin-1.jpg123.64 KBJeff Burnz
#1 iphonedashboard.jpg26.57 KBLewisNyman
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

LewisNyman’s picture

FileSize
26.57 KB
Jeff Burnz’s picture

Do we need everything - for me I'd probably be most interested in "Content", but not really anything else. Maybe we need to find out what the common use cases are (when using your mobile device to admin your site)?

LewisNyman’s picture

Issue tags: +#d8ux

I have been busy hacking away at core with a prototype of how the navigation bar could function on touch devices.

http://d8mux.lewisnyman.co.uk

Hopefully this layout will allow us to maintain the current architecture of the admin interface without sacrificing too much real estate...

I also did a little bit of hacking of the Seven theme to get it to play a little bit nicer.

Jeff Burnz’s picture

Wow, great demo, looks like a good start on this - any chance of a patch Lewis?

I'm getting some touch errors, I think the font in the buttons needs to be a big bigger and the buttons taller overall, (even though they look huge in a normal browser) I'm having to be really precise, especially when they touch the bottom of the screen for some reason - I hit Configuration but get Help unless I am very precise - using Android 2 Samsung & Dolphin.

Granted, I have fat fingers :) Good though because it forced me to look at Seven also and clearly we need some work there as well. Another issues of course.

How can we make Shortcuts work with this?

LewisNyman’s picture

Thanks for the feedback, my smartphone is actually being repaired by Nokia so I'm having to lean on iphonetester.com for the moment.

I actually thought they were too big and reduced them to under Apples recommended height of 44px. I've increased the font size and padding now, tell me what you think.

Interesting about the bottom of the screen being an issue, we will definitely need to do some wide device testing.

This code is no good for patching, it's amateur hour over here. I had to modify the mark up so we are going to have to find mark up that works for touch and desktop and then work out when we are going to conditionally load the styling. Should it be for all touch screen or just below a certain resolution? I will pop in to an Apple Store today if I get the chance.

Jeff Burnz’s picture

FileSize
123.64 KB

Just for clarity I am adding screenshot taken from my Android phone in Dolphin browser.

It actually looks better in the screenshot because the linear gradient on the buttons doesn't look as good on the screen, and this is galaxy 2 with LCD super clear screen also.

This is good start and I think and conceptually on the right track. Perhaps we can start wireframing this now and discuss how we might solve the UI issues, work on a design and start getting some code rolling.

1. Shortcuts needs to work I think, not sure where we can put it.
2. Skip to Navigation - could this be a small button with suitable metaphor?
3. Is there good data on fonts and font sizes for mobile UI design we can draw on?

android-dolphin-1.jpg

LewisNyman’s picture

I popped into the Apple store at the weekend to give the test site a look on the iPhone 3GS , iPhone 4 and iPad.

It is pretty clear how useless the simulators are now...the toolbar areas are just about touchable, it could do with being a bit bigger in order to feel comfortable navigating the site.

Font size is another obvious improvement, it's going to take some thorough testing to see when we need to increase the font size (resolution / screen size?).

I've got an idea for short cuts involving select boxes, it will be leveraging the native UI of each device so I have now idea how feature phone will handle this.

Jerome F’s picture

Wow - subscribing this looks great

jasonsavino’s picture

lewisnyman - I am doing some work work jQuery Mobile and D6/D7 with the eventual move to D8. The toolbar has been a total pain so I am looking into modifiying it for my module and theme. hit me up if need some help.

LewisNyman’s picture

Hey Jason, that sounds great. I'd like to see some designs you have in mind.

I've got a contrib project set up so we can do some experimental work first:
http://drupal.org/sandbox/lewisnyman/1265890

JohnAlbin’s picture

Issue tags: +mobile

Nice design/usability explorations. :-)

dodorama’s picture

FileSize
63.39 KB
47.17 KB

I've been working on a proof of concept for a responsive admin toolbar that builds from the current design.
There's a working prototype here http://www.trentaquattro.me/drupal/
user: demo
pass: demo
When you resize the browser the admin menu turns into a drop down while the user menu (Hello Admin and Log out links) are moved in the page_bottom region.
The code is ugly but I think it's a sensible strategy. All the code is in a module, right now.
A few of links on responsive menu patterns that I think might be interesting.
http://filamentgroup.com/lab/responsive_design_approach_for_navigation/
http://bradfrostweb.com/blog/web/responsive-nav-patterns/#toggle

Toolbar Collapsed

Toolbar Expanded

LewisNyman’s picture

Hey dodorama.

This issue is kind of old. It's a shame we have the discussion split across two threads (http://groups.drupal.org/node/191593)

This is a good implementation but I'm concerned from a design angle of how this will play with a mobile drupal site that also uses the same techniques.

Back before we started high level prototyping I thought using a common technique from regular websites was a good idea. What if the mobile site you're administrating has the same navigation? Then you have two toolbars fixed to the top next to each other that do the same thing. I wondered if they would conflict or get in each others way. Also for technical reasons having a fixed toolbar is just a no go on mobile.

Then I realised that a top level administration tree list already exists in Drupal 7. So why not simplify it and add a link straight to it? We get complete separation between back and front end nav and we have the whole screen to space out our links.

Maybe we should jump on irc and discuss our options? Either option is a lot better than what we have now.

dodorama’s picture

I understand your concerns but how do we navigate to another section of the administration without a menu?

(Have you stumbled upon this article? It describes common mobile navigation patterns. This might be of interest too because it doesn't even require media queries. It detects when the menu doesn't fit anymore and then it makes it into a drop down.)

On top of that what I'm trying to do with this prototype is to find a solution that could be eventually be applied to Drupal 7 using a module. That would mean providing a solution for sites running Drupal now and at the same time testing an approach that could then eventually integrated in D8. I'm afraid that if we go too far from the current implementation we'll never find time and support to code and test it. I'm following your work on the sandbox and I definitely like it; I'm just worried it could require a big patch that won't easily find support. Here I'm taking baby steps. If we can find a solution to make the toolbar responsive we could try to get it included in core right away. Than we could move to tables, then forms, than the overlay. What do you think?

P.S. I'll try to be on IRC for the next Mobile initiative meeting. I hope to meet you there.

kika’s picture

Toggle navigation pattern seems to get more and more common, have a look at http://twitter.github.com/bootstrap/examples/starter-template.html (resize browser). Also there's a pulldown option http://inspectelement.com/tutorials/pull-down-for-navigation-a-responsiv...

LewisNyman’s picture

I'm going to update this issue with a reference to a new design prototype I made, it uses a sliding toolbar and is currently touch only.

altnav.d8mux.org

LewisNyman’s picture

Issue summary: View changes

Removing "meta" issue.

LewisNyman’s picture

Issue summary: View changes

Updating summary

LewisNyman’s picture

Issue summary: View changes

Changed first header

gmclelland’s picture

Just curious, what happened to the "The Left Nav Flyout ala Facebook. (Prototype)?" I'm starting to see this trend more and more.

There is even a jquery plugin for it http://srobbin.com/jquery-plugins/pageslide/

gmclelland’s picture

Here is some other ideas for the page slide concept:
You could create one "admin" button that does a page slide from left to right. Inside it would contain an expandable accordion with drupal navigation menu.

On the right you could have a user avatar that when clicked does a page slide from right to left that shows a user menu. Example. My dashboard, My bookmarks, My profile, My activity, Sign Out, etc.

Examples:
Path - http://itunes.apple.com/us/app/path/id403639508?mt=8

Facebook mobile site - http://mobile-patterns.com/#/i/27

National Geographic National Parks iphone app -
http://pttrns.com/www/imgcache/320x480/screens/navigations/National-Park... and http://www.nationalgeographic.com/mobile/apps/national-parks-by-national...

http://meer.li/designs/menu-concept
http://meer.li/designs/marmiton-restos-2
http://meer.li/designs/pintale-menu-view
http://meer.li/designs/festcollect - shows menu icon on left, user avatar on right

gmclelland’s picture

Maybe there is some way contrib modules could hook into and use these navigation patterns.

For example, maybe the media module could use the http://srobbin.com/jquery-plugins/pageslide/ technique and the ajax drill down horizontal sliding navigation technique, or both together?

For example, see #1678106: Mobile Friendly Media Browser

effulgentsia’s picture

Thanks for all the great ideas and prototypes. How close are we to converging on a decision? Am I correct in understanding that:

- lewisnyman's recommendation (http://nav.d8mux.org/) is to remove navigation links (e.g., "Content", "Structure", "Appearance", etc.) from the toolbar entirely; when on a non-admin page, have a single "Administer" link; and when on an admin page, have a set of context-specific icons (action links) appropriate for that page (e.g., an icon for "Add content" when on admin/content).

- dodorama's recommendation (#12) is to retain our current toolbar, but within a slidedown, and when the slidedown is open, to have one link per line.

- gmclelland's recommendation (#18) is similar to lewisnyman's, but for the "Administer" link to be on the left, and to add a user avatar on the right that when clicked would page slide from right to left with user-related links and actions (e.g., "My dashboard", "Log out", etc.).

Has there been any discussion elsewhere that's proposed other options or steered us towards one of these three? We only have 4 months left till D8 feature freeze, so would be great to pick one soon and start implementing.

webchick’s picture

Definitely talk to Kevin from the Spark team; he's got a design for a collapsible-sidebar-based admin toolbar (ala Admin module) that might be worth looking at as well.

effulgentsia’s picture

Here's a list of tasks that I can think of based on the http://nav.d8mux.org/ prototype:

Toolbar tasks:

  1. Basic toolbar setup:
    - Make toolbar taller (touch screen friendly).
    - Remove all of its current links.
    - On non-admin pages, populate with page title on left and "Administer" button on right.
    - On admin pages, populate with page title on left and an "eject" icon on right.
    - Clicking the eject icon should return you to the non-admin page you were on when you clicked "Administer".
  2. Action link icon:
    - On admin pages that have 1 action link (e.g., "Add content" on admin/content), remove that action link from its normal location and instead add a "+" icon in the right area of the toolbar.
    - What about pages with more than 1 action link (e.g., admin/config/services/aggregator)?
  3. Tableselect icon:
    - On admin pages that have a tableselect (lists with checkboxes and bulk operations), show just a simple list, but add a "checklist" icon in the right area of the toolbar.
    - Clicking that icon should add checkboxes to each list item and replace the right area of the toolbar with a "select all" icon plus buttons for each available bulk operation.
  4. Filter icon:
    - On admin pages that have a filter widget, remove that widget and instead show a "filter" icon in the right area of the toolbar.
    - What does clicking that icon do?
  5. Search icon:
    - On all admin pages, add a "search" icon.
    - What does clicking that icon do?

Non-toolbar tasks:

  1. Add a page slide animation when navigating from one admin page to another.
  2. For pages that are just admin navigation trees, preload the next level (or the entire tree if not too bandwidth heavy) to allow fast "page" transitions.
  3. Style primary tabs (e.g., "Manage Fields"/"Manage Display"/etc. on admin/structure/types/manage/article) as tall wide rectangles.
  4. What to do with secondary tabs (e.g., "Default"/"Teaser" on admin/structure/types/manage/article/display)? Some sites can have a lot of view modes where the secondary tabs can wrap and look bad even on wide viewports.

I have not yet opened issues for these, as I'm not yet clear if this UX has reached sufficient consensus. If there's already existing issues for some of these, please add links to them (either in a comment or the issue summary). If I missed something or got something wrong, please comment about that too. Once there's agreement on the UX, we can turn this list into issues and work on implementing them.

effulgentsia’s picture

FYI: While this issue is about removing navigation links from the toolbar for mobile, there's also a Spark issue, #1586374: New toolbar, that wants to add more navigation links to the toolbar (based on usability tests linked from that issue). I'm trying to track down other major toolbar UX discussions as well; hopefully we can somehow converge on a battle plan.

JurriaanRoelofs’s picture

I just posted a proposal that relates to this issue: http://groups.drupal.org/node/247073

webchick’s picture

Here's a post and video describing the approach the Spark team is planning to go on this issue: http://buytaert.net/spark-update-mobile-administration-in-drupal We borrowed heavy inspiration from Lewis's work. The hope is to turn this into a real module on D7 at http://drupal.org/project/navbar and then forward-port it to D8 core if there's community buy-in around it.

Bojhan’s picture

I have a hard time following what Spark is doing, compared to this - it looks like your changes stretch far beyond the mobile realm in terms of admin user interface changes.

In my conversations with lewis, we found that most of the challenges covered here stretch beyond just navigation. Should the navigation capture page elements? We figured we should at the very least explore, what it means if it did. Because in the end the actual page should make sense, and navigation could be part of that.

One of the biggest challenges is having clear signaling where you are in the navigation tree. This can be done in many ways, an apps center (iphone/android), moving down a tree (spark), sliding through the navigation (lewis), and many more (http://bradfrostweb.com/blog/web/responsive-nav-patterns/). We should do further research which cues are required to convey this information, it might just be that clear labels whether you are in "config" or "structure" would do the trick - this is what Android does.

I am having a hard time following how the Spark solution scales to the desktop and/or how it handles broad and deep tree's. Could we have a demo up? Also it would be helpful if Kevin, jumps into these discussions rather than doing it in private channels that way the community can benefit from seeing the conversation.

LewisNyman’s picture

I would like to mention that the reason I chose to completely avoid any fancy slide down/out navigations for navd8mux.org is because it increases the likelyhood that we will run into:

  1. Compatibility issues with the front facing theme. What happens if the front facing theme implements the same type of navigation or something complex that conflicts with the admin interface?
  2. Performance issues, especially true of the slide out navigation, what happens when we try and animate a whole page with 10,00 html elements on it. There's no way we can reliably test for CPU speed so device diversity also complicates this.

I'm not saying these aren't an option, I'm just explaining my thought process when I made my decision.

tkoleary’s picture

So yeah, I am guilty of being kind of heads-down on this but we do have a prototype and the state of the spark distro right now including the ember theme and the navbar module goes a long way towards what we originally envisioned.

The prototype was created by Preston So we will post a link to it here by tomorrow. We also plan to roll an alpha 5 release of Spark tomorrow which will give everyone in Munich a much clearer picture of how ember, edit and navbar work together.

To your question about the navigation capturing page elements, i think that's an excellent point. Along those same lines I think that there are pages within the admin structure that can fall away (or at least get less traffic) in this paradigm because they are really nothing more than glorified menus anyway. I'm talking about the main admin page, structure, reports and to some extent configuration.

Dharmesh will also be testing all of this soon so we'll get some good actionable data.

prestonso’s picture

@Bojhan Here is a link to the responsive dashboard prototype for Spark, which includes a prospective responsive toolbar (inspired greatly by lewisnyman's work) as well as a responsive pullout menu (based on the Admin tools module). The current iteration of the Ember theme as it stands now incorporates Admin tools with lots of hacky overrides.

https://dl.dropbox.com/u/34693193/dashboard_prototype/index.html (please excuse the rough edges)

Our current thinking is that on smartphone screens (you will see this if you resize the prototype), the left-side pullout menu (à la Facebook, as gmclelland mentioned) will expand to take the entire mobile viewport. This will allow users to switch easily between the pullout menu and whatever screen they are actually on quickly and seamlessly (although we think the pullout toggle in its current state is a little too small). Furthermore (click on the "Content" link), you will notice that the trees expand as part of the tab itself. I hope this gives a clear idea of how we envision this working on any viewport.

I agree with Lewis in that there is definitely a clear concern that other navigational elements can conflict with any pullout that is built. However, this is somewhat alleviated by the fact that toggling the pullout menu will push aside the content in a smooth transition as Admin tools does right now (the Ember theme has this transition, but the prototype above does not). Our hope is that users would be able to identify the administrative pullout after such a dramatic transition.

Bojhan’s picture

@prestonso Could you explain a little how this tree pull out works with Site configuration? How deep does it go, how does it handle that? This design pattern seems designed primarily for flat hierarchies, I don't really understand the benefit of having depth in such a tiny area.

tkoleary’s picture

@bojhan, Preston asked me to field that question. Our current thinking on the menu tree in the drawer is that it will be no more than three levels deep, which covers a great many of the admin pages. From there the primary and secondary tabs can cover deeper levels of hierarchy. Have a look at how this is working in spark alpha 5. It's not quite there yet, particularly the expanded child menus in the drawer, but it will give you a sense of how the drawer and the tabs work together to create a consistent navigation experience without taking up too much space.

tkoleary’s picture

@lewisnyman after reading comments from yourself gmclelland and others I have re-designed the toggle for the drawer visibility to be fixed and more out-of-the-way of the users theme. I think this works better and it uses the affordance for menus that is rapidly gaining ground in mobile. See attached images for the open and closed states.

LewisNyman’s picture

Tabs aren't designed to be different levels of navigation that just look different. They imply a good deal about the information architecture. I don't think it's a good idea to use them to cover a hole in the implementation of the main navigation.

The sub-navigation items looks pretty small and close together. It's kind of a shame we aren't making the most of the screen space available to us. This is a reason why I implemented the navigation system like I did in my first and second prototype.

Maybe it would help to explain your reasoning behind the collapsible toolbar pattern?

webchick’s picture

FileSize
335.73 KB

Here's what I think are the latest designs in full, along w/ the dashboard stuff. I think this might be a Fireworks png but I have no way to check and Kevin is on vacation this week.

Bojhan’s picture

I want to post my initial analysis on the proposal of tkoleary, its clear to me that we are on the right track here. I want to give a short analysis - although I understand, that much of this still has to be thought out - I also think its valuable to give early feedback.

I think we should establish what standards we are going to apply to our mobile site, what DP are we aiming for? I think it makes most sense to follow http://developer.android.com/design/style/metrics-grids.html, because these standards are formulated after a wider range of mobile phones than the iOS standards. For the screen size I have standardized on 320x480, the android standards boil down to:

  • Target size of 7-10mm for touchscreen objects
  • Spacing between UI elements 2mm

Either way, this probably needs some more discussion. For the screen on the right, I used LukeW's book to provide direction on mobile screen estate usability.

analysis-combnied.jpg

The first thing I noticed was the concentration of important navigation elements in the top left, which according to LukeW is the hardest to hit area on your mobile phone. Although this adds a high level of information density on the top left, it has as side effect that we might be creating hard to hit buttons, especially if you consider the likeliness that you hit another button.

Lewis his comment regarding placing secondary tabs here, mostly focuses on the part that we should try to list common functionality together in a scalable pattern. Given the fact that secondary navigation is a less often used navigation item (probably even more so on mobile), we can if needed place them elsewhere on the page.

I am not very fond of tree based navigation on the phone. I have just used this, and I noticed that the touch targets became nearly impossible to hit (this is fixable - I assume you just didn't get to it yet), but also the text becomes hard to scan - this because of the level of indenting required, text overflowing two levels, a lot of vertical scrolling. Given the fact that "Configuration" will require 3 level deep navigation, I am not sure - whether this is a pattern we want to pursue.

I agree that we should consider dropping shortcuts from initial view, at least for mobile. Although on principle I don't like limiting functionality to mobile users, I see that its not very useful for them and takes up considerable screen estate.

I have spend a little bit of time discussing this with jbeach and lewisnyman at Drupalcon Munich, my proposal is below.

Keep in mind that this is still a early wireframe, not a visual design.

admin-nav-mobile-slideout.jpg

As suggested above, we could be using the facebook/path pattern of expanding the "page" area. This has the benefit that it is a much stronger affordance than the drawer, but a big drawback that it takes up much of the real estate.

I suggest we use a sliding navigation, as shown in lewisnyman his prototypes. Jesse Beach even made a library for this to be found at https://github.com/jessebeach/flexiPanda. It allows for people to very quickly move down and up a tree, but more importantly it allows us to leverage almost the full screen estate for just navigating. Given the fact that Drupal has a deep, rather than flat IA (like most mobile app's) we have to really make sure we support this well. I have used an > to indicate, it has more levels - however this could be misinterpreted as it being the only "linked" item in that list.

The tree dots is a way to show/hide the admin nav bar. When expanded users should be able to see the full width as illustrated below. This allows for more navigation items to be placed on the left, such as a "quick search" as shown in lewisnyman his prototypes and a possibility to toggle profile/logout as shown in kevin's designs. The primary thing I haven't designed yet is, how to get home and how seven would look like in this.

navigation-2.jpg

That's my review for now, I am sure there are more ideas. Lets make sure we timebox consensus on the direction to the next 2-3 weeks so we can get a move on all of the difficult implementation parts.

jessebeach’s picture

The LukeW image is really helpful. I hadn't seen that before; thanks for posting it.

I had a look at Facebook's mobile navigation and I see a lot of compelling parallels between their work and Bojhan. I will argue that Facebook's mobile experience has a lot thinking and research behind it, so modeling our approach on theirs is good for two reasons: (1) we leverage their design experience and (2) we implement patterns that all Facebook mobile users will be familiar with.

A screenshot of m.facebook.com with the mobile menu tray expanded from the left-hand side.

Could we move the shortcuts into the side tray as a top-level, expandable/collapsible list?

gmclelland’s picture

@Bojhan I really like these ideas. Is there any demo of flexiPanda? a jsfiddle or something to see how it works?

http://www.aids.gov has a similar drilldown navigation though instead of it sliding in from the left to the right, it slides in from the bottom to the top.

One benefit of the menu button being displayed in the top left hand corner is that it could be combined with a logo to make it a bigger hit target. (Google+ app does this on Android)

webchick’s picture

The shortcuts in Spark are being moved to the main Dashboard page (which of course we haven't implemented yet), rather than the toolbar, which would free up the area the Shortcut bar takes up for "contextual actions" (e.g. "Save / Publish" buttons on content creation/edit, mobile previews on layout futzing, etc.). The idea is that those per-role menus would be underneath the "Add" / "Configure" / etc. buttons on the main dashboard page eventually. Drupal 8 no longer has a dashboard module, but the conclusion in that issue was that if we came up with something decent (much easier if Views is in core), it could be added back in later. As a stop-gap, we could possibly move them to a collapsible/expandable list, though.

gmclelland’s picture

For what it is worth I just ran across this today
http://bradfrostweb.com/blog/web/complex-navigation-patterns-for-respons...

The http://www.sony.com site has a similar sliding navigation.

jessebeach’s picture

Status: Active » Needs work
FileSize
83.32 KB

So, we're more than a week past DrupalCon Munich and I've had some time to invest into the toolbar redesign. These are the major highlights:

  1. We introduced a toolbar tray that slides from the edge of the screen into view when the menu button is pressed (top left corner).
  2. The management menu has been moved to toolbar tray. The entire menu is now printed and not just the top items.
  3. The management menu is navigated through a side-slide technique similar to mobile application list navigation patterns.
  4. The shortcuts are moved into the toolbar tray.
  5. The toolbar tray has the search form element that will eventually provide access to a quick search for menu items.

This patch represents very early work. It's not meant to be a proposed change in its current form. Rather, we're still debating the design and having something to interact with.

@Everett Zufelt, if you happen upon this thread, I'd love to know if moving the toolbar from the page_top region to the page_bottom region is a good move, a bad move or neutral in terms of your interaction with the page. Also please give me your general impressions. Everything is very fluid in terms of structure at this point.

I also incorporated (temporarily) a plugin named flexiPanda that I've been working on for several months now. This plugin powers the slidey menus and can render dropdown menus as well. The plugin itself needs work and I plan to finish it as a part of this redesign effort and get it whitelisted. We can then either incorporate the plugin as an external library into core or simply copy the code from the plugin into a core file. I'm cool with it either way - the plugin was always meant to be liberally licensed.

This patch is just for review of work so far. Improvements and critiques are welcome!

nod_’s picture

Quickly looked at the patch:

  • First and foremost: flexiPanda is like a panda. Huge. 32kb uncompressed, 8kb compressed and min+gzip is 4kb it's just too big for what it's supposed to be doing. To me that's a blocker. we want to solve issues for small screens with as little JS as possible.
  • It shouldn't be in the ui folder, that's not actually shipped with UI.
  • flexipanda use .delegate, .bind, should just use .on()
  • Has some trouble with overlay :p
  • I'm seeing a lot of positions stuff, UI is already on the page, can't use http://jqueryui.com/demos/position/ for this kind of stuff?

It's pretty nice to use it's just that the code behind it feels way to complicated for what' it's actually doing. Need to shrink a lot before that can be core material.

yannickoo’s picture

Is it bad when I tell you that there are lot of whitespaces and tabs in the patch?

Bojhan’s picture

I am having a bit of difficult getting the slide-mechanism to work, is there a particular browser I should be using?

jessebeach’s picture

@yannickoo, the whitespace is there to remind us this isn't a commit-ready patch :)

@Bojhan, I've been working in Chrome during the dev stage.

@nod_, I agree with all your comments re: size and complexity. I threw in the plugin because it works, so it at least gives us a sense of the interaction, and because we have complete control over the final product, so we can strip it down to any level of minimal viability. I originally wrote the plugin to target jQuey 1.4.4, so I ended up writing my own support for a lot of features that jQuery 1.7+ has out of the box now.

Bojhan asked that I get a patch in this queue. You can also see the repo in the sandbox we've been working in: http://drupal.org/sandbox/jessebeach/1749042

There's a mobile initiative meeting today: http://groups.drupal.org/node/251933

Join up and I'll give a demo with join.me. Then we can determine next steps.

jessebeach’s picture

Issue summary: View changes

Changed name to left nav flyout

jessebeach’s picture

@nod_, you bring up a great point about overlay that's been bothering me. Overlay makes no sense on a small screen and with the impending introduction of in-place editing, the usefulness of the overlay quickly fades.

jessebeach’s picture

Moshe just pointed me at this issue regarding the overlay #1260800: Kill the overlay for widths below 640 pixels.

jessebeach’s picture

Issue summary: View changes

Updating the issue summary.

nod_’s picture

Oh yeah, but on desktop it still show up and the navigation goes on top of it. But maybe that's a feature :D I don't know.

jessebeach’s picture

I put together two videos to illustrate different interaction options for the side tray menu presentation. The first is an iOS/mobile list interaction style that slides from menu to sub-menu.

1137920-toolbar-slidey-menus

The second interaction style is similar to a classic folder directory interaction with twisties.

1137920-toolbar-folder-menus

Kevin has put together designs that further detail the folder directory approach. This is the one I'm favoring at the moment because it uses an established pattern and it's highly scalable.

Sidebar tray menu, using the folder directory interaction style, showing 6 levels of menus

We can also extend the UI to work well with pointing devices, as well as touch. Pointing devices would trigger flyout menus for quick navigation without clicking; or, a user can click the twisty and lock the submenu open.

Sidebar tray menu with directory structure navigation style, show flyouts for submens when the user interacts with a pointing device

attiks’s picture

Nice work, my 2cents and a bit of dreaming:

  • slidey-menus for mobile devices (read phones, tablets in portrait) because there's not much room
  • folder-menus can work, but the problem is that they push everything down, and you probably have to scroll, with the flyout you have to scroll less. Would be ideal for tablets (landscape) and lap/desktops.

New feature request: any change both can be implemented? ;-)

jessebeach’s picture

@attiks, both kinda work now, but the code for the slidey menus is diiiirty. My plan is to get the folder interaction working well.

My reluctance to make the interaction behave differently based on MQs or viewport sizes is that I don't want to bake those sizes into core. If the JavaScript is written with the intent to switch methods, perhaps I could put the slidey menu code in a small module and allow folks to switch out the interaction.

gmclelland’s picture

@jessebeach and Kevin - great job, IMO the horizontal sliding pattern as seen in the first video would be the best option. It allows for unlimited menu depth and it works on all the screen sizes touch and non-touch devices. This UI pattern works and is tested to work, as proven by the success of the ipod and it's drilldown navigation.

Video #2 - it works, but navigating the menus can start to get difficult when there is more than three levels deep.

I would stay away from the horizontal flyout menus(third pattern). That would require extra code to check the window viewports to make sure the menus don't flyout offscreen. Typically those also are controlled by hovering, which you can't do on a mobile device.

Couple of questions for you:
1. Will it be possible to create multiple page sliding menus from icons in the toolbar? If so, can we make the user account icon/user name a sliding menu as well? I could see people wanting to add links to that menu. For example, My dashboard, My favorites, My profile, etc

2. Would there be any way to use CSS3 animations with a javascript fallback for the sliding menus and page slide? This type of menu would be mainly for mobile devices anyway which have good CSS3 support.

3. Maybe there should be a module that provides the sliding menus and module that provides the page slide like Admin module does? That way you can put multiple sliding menus stacked on top of each other in one page slide. Note: maybe the admin module already supports this, I'm not sure if you can have multiple page slides?

4. Could the search/filter menu items input field be moved into a separate block so it could be disabled if you didn't need that?

Thanks again for showing the ideas.

webchick’s picture

The one thing that I can't really visualize from those videos is what the 320px view would be. Does the toolbar come out only partially so you still see a little bit of the page behind, or does it take up the entire view?

<opinion origin="PHP hack" trust_level="-5">
Between the two I think I like folder-menus better, because:

1) It's clear how many "back" levels you need before you're up at the root, else I think one could end up feeling hopelessly lost in a never-ending sea of backlinks if I'm direct-linked to somewhere like admin/config/content/formats/add from somewhere like admin/modules and trying to get back to where I was.

2) It better contextualizes "Where am I?" in relation to the larger navigation structure, to help me learn how Drupal's administrative interface is laid out.

OTOH, I think the "endless scrolling" concerns are also valid. Could we alleviate that with smart ID targets, so the navbar would automatically scroll down to #admin-config-content when I expand it from admin/config/content/formats/add? (Similar to how the "jump to module X permissions" links from the admin/modules page works?)
</opinion>

botris’s picture

Wow it all looks very promising. My 2 cents:

The folder option does give you the most perspective on where you are in the navigation structure. Which I think is most important for content editors.

I would definitely offer the flyout option as well (by contrib module or core). This would seem the most used by site builders who have access to all menu items and probably always build a site with a larger screen and mouse.

LewisNyman’s picture

Hello,

Nice work guys. The horizontal scrolling, at least from a small screen perspective, is by far the better option. It keeps user grounded in the same location and keeps the previous destination easily in sight.

One concern I have from a small screen point of view is the perception of the top menu sliding in from the left initially and then level below that sliding in from the right after. It might throw people off to see the same types of elements sliding in from two different directions.

I haven't seen a lot of direction towards how touch interactions would be handle differently if at all. Is there any scope for that in either design?

jessebeach’s picture

Thank you all for the feedback

@gmclelland, regarding the flyouts, I've got a lot of the viewport collision code written already. It could use some refinement, but I've done it once, so it's not such a far throw.

"Will it be possible to create multiple page sliding menus from icons in the toolbar?" - I'm not sure what you mean. Can you illustrate with a quick sketch?

"Would there be any way to use CSS3 animations with a javascript fallback for the sliding menus and page slide? " Yes, I'm looking at this today.

"Maybe there should be a module that provides the sliding menus and module that provides the page slide like Admin module does?" Yes, agreed. As I refactor the JavaScript, I'm making sure that it follows an architecture that will allow developers to easily knock-out the default interaction strategy and introduce their own.

"Could the search/filter menu items input field be moved into a separate block so it could be disabled if you didn't need that?" - That's a great suggestion, I'll bring it up with some the more Drupaly folks on my team to figure out how to do it.

@webchick, re: "Could we alleviate that with smart ID targets[?]" - Yes, this should be the behavior of the menu, that it remembers the sections you've had opened and also brings you right to the active page with the path to that page link exposed and fore-fronted.

@Boriss, re: "I would definitely offer the flyout option as well (by contrib module or core). This would seem the most used by site builders who have access to all menu items and probably always build a site with a larger screen and mouse." - thanks, I think so too. Others have mentioned that they don't want to click endlessly to get to nested menu items while working on the desktop. I'd really like to unburden folks, including myself, from a repetitive and slow interaction pattern if a better one is achievable.

@lewisnyman, I think touch is the primary interaction method in this design. The flyout menus are an enhancement for pointer interactions. Does that come across or could we do more to make the touch experience better?

gmclelland’s picture

@jessebeach - Not sure about the js code quality, but I believe http://drupal.org/project/dhtml_menu already provides collapsible menus and http://drupal.org/project/nice_menus provides the flyout style of menus.

"Will it be possible to create multiple page sliding menus from icons in the toolbar?" - I'm not sure what you mean. Can you illustrate with a quick sketch?

- I think it would be cool to have ANY menu with nested menu items be able to drill down using the github style horizontal sliding as shown in video#1. I was thinking maybe you could place that type of menu in any region like a sidebar or other small space. I'm not sure if that is possible? maybe the menu has to be a fixed width?

In fact, I have looked at some others as well. Here is a run down of the ones I have seen with some rough notes:
1. http://www.designchemical.com/lab/demo-wordpress-jquery-drill-down-ipod-... - tested on Android and ipad
2. http://codelove.herz-as.net/jquery/jquery-multi-level-slide-menu/ - like #1 - works really well on Android - demo doesn't work in any IE because the demo doesn't use onDomReady, it justs executes immediately, works ipad, android
3. http://www.dynamicdrive.com/dynamicindex1/drilldownmenu.htm - tested on Android, works well
4. http://filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/ - tested on Android, works - but is a pop up and not a pop down
5. http://codecanyon.net/item/nice-menu-v10/135661? WT.ac=category_thumb&WT.seg_1=category_thumb&WT.z_author=AA-Team - tested on Android and ipad
6. http://codecanyon.net/item/deviant-menu/78432?WT.ac=category_thumb&WT.se... - I like this one, but it wouldn't run on Android and uses MooTools
7. http://codecanyon.net/item/jquery-infinite-sliding-menu-plugin/164115?WT... - tested on Android, works but not very smooth
8. http://jamesarosen.github.com/jquery-ui/demos/menu/ios-menu.html - tested on Android, works but screen sometimes jumps around
9. http://www.sonicradish.com/labs/jGlideMenu/current/index.html - tested on Android, works but not very smooth
10. using CSS3 - http://tympanus.net/Tutorials/CSS3ContentNavigator/ - works, but sluggish on phone, sluggish on ipad
11. http://jamesarosen.github.com/jquery-ui/demos/menu/ios-menu.html - jquery ui menu for 1.9 - http://wiki.jqueryui.com/w/page/12137997/Menu

nod_’s picture

@jessebeach about css animations, it's quite tricky actually Wim can tell you about it too :) #1605960: Replace JS animations in core components with CSS transitions

Since we're talking about a list, with nested elements and how to navigate that on mobile, we could use the same pattern for tabledrag maybe? #1261002: Draggable tables do not work on touch screen devices #1524414: Rewrite tabledrag.js to use jQuery UI

Wim Leers’s picture

#57: I've passed on all relevant explanations & info to her. Without the explanations, but still all the relevant references: https://pinboard.in/u:wimleers/t:acquia:spark+animations.

jessebeach’s picture

Not much on the surface has changed in this updated patch. Please bear in mind this is still a pre-pre-alpha patch. I'm not proposing this for inclusion. I just want to keep regular updates in the queue for those who may not be following the gritty commits in the sandbox (199 commits!).

Major changes in this patch:

  1. I started testing on mobile devices and simulators. I've improved the interaction of the menu tray; it was quite broken on actual small devices. The interaction still isn't great. I've talked to Kevin. We may need to revisit the design if I can't get the tray to display in a while that pleases the eye.
  2. I ported the code for the accordion menus from the flexiPanda module and removed all traces of the plugin from the patch. I put the plugin in originally as a way to quickly demonstrate an interaction option. It was way too much code for what it was actually doing, so I just pulled out the pieces we need.
  3. I started refactoring the JavaScript in toolbar.js to be in line with recent JS refactorings in core (still not done in my case) and I've started refactoring the CSS as well (also still not done).
  4. Top level menu icons are in. We're still discussing with Kevin how we can make the icons more interchangeable for admin themers. Kevin is pushing for a font-based icon set and I like the idea, I just don't know how that'll work in core.

What I'm planning to do in our current 2 week sprint:

  1. Incorporate Shortcuts into the tray
  2. Introduce some sort of hook for page actions (e.g. edit module actions) *and* the ability for other modules to add more actions *and* the ability for modules to override how the expansion works (dropdown/accordion/…)
  3. Type ahead menu item autocomplete
  4. Backport D8 changes to the Navbar module for D7.
  5. Turn the User actions in the Toolbar into a dropdown
  6. Testing, testing, testing

If you'd like to play with the menu changes, head over to http://d8.qemistry.us/
The credentials are

u: sparkles
p: SparkItUp

I reset that site every couple of days when I rebase to 8.x, so don't go writing anything there you want to keep :)

@gmclelland, thank you for the tips! I'm looking through your suggestions.

webchick’s picture

In addition to everything Jesse said, we also think we should kick the "flyout" part of the menu to a subsequent patch, after this one is done. It's an enhancement, and thus could probably even get in post-feature freeze, whereas getting something basic in so that Drupal 8 doesn't look like this out of the box:

Toolbar wrapping nastiness.

... is probably a good idea to solve ASAP. :)

Wim Leers’s picture

Testing (and typing this message) on an iPhone 4S, with the default browser, I noticed the following:
- the menu does not get kinetic scrolling
- the menu slides in, have fades out instead of sliding out?
- there is a significant and I would say "killing the magical UX" when tapping the arrows
- once you've tapped the menu button, it's text gets underlined, and it never goes away. It doesn't fade out properly anymore either.
- the "menu" button is fairly wide, and the icon+text only cover a small, non-centered area of it
- is it really necessary to have two rows? It means there is less screen estate left for content.

jessebeach’s picture

The kinetic scrolling issues are known, I'm trying to figure out how to get it ti work. I think we may need to change the design a little because of the way the viewport size is calculated on phones.

"there is a significant and I would say "killing the magical UX" when tapping the arrows" -- ya, I'm not sure why yet :(

"the "menu" button is fairly wide, and the icon+text only cover a small, non-centered area of it" -- hmm, interesting, I'll look into it.

"is it really necessary to have two rows? It means there is less screen estate left for content." -- see todo item #5 in comment #59 :)

The slide out got broke while I was fixing issues on the phone. It was, if you can image, much worse than even what you see in the patch late last week!

Wim Leers’s picture

Oh yes, it's much better already! Just trying to give useful feedback :)

moshe weitzman’s picture

Introduce some sort of hook for page actions (e.g. edit module actions) *and* the ability for other modules to add more actions *and* the ability for modules to override how the expansion works (dropdown/accordion/…)

Core has a lot of these hooks already. The menu system offers action links, local tasks, and secondary tasks. Individual emelemts on the page can have contextual links. Lets try not to add another system :). Am happy to discuss this more.

moshe weitzman’s picture

Issue summary: View changes

Added a link to http://drupal.org/node/1260800 in the description.

jessebeach’s picture

Issue summary: View changes

Added a link to issue #1781402

jessebeach’s picture

Issue summary: View changes

Removed a note about old solutions.

jessebeach’s picture

Issue summary: View changes

Added a link to issue # 1781422

jessebeach’s picture

Issue summary: View changes

Added a link to #1782576

webchick’s picture

Trying to review this tonight, I noticed that both the demo site is b0rked and the patch doesn't apply because:

"error: missing binary patch data for 'core/modules/toolbar/images/toolbar.png'
error: binary patch does not apply to 'core/modules/toolbar/images/toolbar.png'
error: core/modules/toolbar/images/toolbar.png: patch does not apply"

I has a sad. ;(

webchick’s picture

Issue tags: +Spark

Tagging.

webchick’s picture

Category: task » feature
Priority: Normal » Critical

Shipping a CMS in 2013 without the ability to edit it on a mobile device without it looking like utter shite would be a death knell for Drupal. Escalating this to a critical feature request.

Bojhan’s picture

Title: Redesign Administration Tool bar for Small Screens & Touch Screens » Redesign navigation for smaller screens
Issue tags: +Usability

Also, lets pick a title that isn't super long in describing what we mean.

Bojhan’s picture

A full review that was long overdue, I am going to attempt to put some more intensity around all this mobile stuff.

Let me start by saying that I am really excited by the fact that we have patches we can try out, although there is much too discuss the path that lewis took in the beginning to just prototype that is extended by this effort is definitely something I love to see.

I will try not to address known bugs; toolbar covering two rows, sliding, overlapping items (contextual links). Let me know when I cover anything that is already discussed.

Fundamentally I would like to split of discussion about changing the navigation on the desktop, although the principle of aligning the mobile and desktop experience is great. I don't feel comfortable at all changing such a important part of the Drupal UX, without a broader discussion.

drupal8-mobile-patch-applied.png
Showing the patch from #59

Overall

  • Big +1 for retaining, the slide out pattern, I really liked being able to toggle to the front.
  • The interaction for showing/hiding items below a dropdown is a little clunky. I often found myself clicking the title, to find that I should really be clicking the dropdown icon. While clicking the dropdown icon, is not necessarily hard but not super easy.
  • We use "Management" menu for this, which to me feels very random. For example in Structure, you can expand "Menu" to see the menu options below it. But this concept does not exist for content types/taxonomy. I noticed similar weird issues in content comments is listed as dropdown where as on People permissions and roles are not. We should find a way to mimic much of admin_menu is doing to consistently show levels. Although this is out of scope, it makes for too much of a random navigation experience.
  • Just playing a bit with it, I was surprised to see the panel doesn't run the full height. Just wondering what the rationale is behind that.

I would love to see how you incorporate shortcuts, that's definitely a challenge.

d8-mobile-menu-targets.png

Row

  • The indent styling is often too little, to quickly notice what it belongs to. As shown above its hard to see how File system, falls under Media. We rely heavily on color and dropdown icon, but with so many dropdown icons you have to really spot it and the different shades of gray fell away as I tested this more lightning in my surroundings.
  • The hit target for menu items in a dropdown (Configuration) is very small, it was already noted this might be to small. I found myself misclicking.
  • The borders seem to be bugged, sometimes they are ticker.
  • The click event, could benefit from something more than just an underline.

Although search is part of the design, I am not sure if we need them in this patch? Because in terms of design, I initially thought this wasn't an input field, there are no affordances to signal that.

image-styles-configuration-on-mobile.png

Every time I see Seven on my mobile phone, I get a little excited. Occasionally a very wide page caused bugs; e.g. the toolbar wouldn't stretch the whole width.

Toolbar

  • There is too little spacing between the icons and the labels. I am not even sure the labels are necessary.
  • I am a little bit sad, that we break with the pattern almost all other apps have with similar ux patterns of placing the menu collapse button in the top right.

There still seems to be a lot to iterate upon, using a relatively new mobile pattern to navigate mobile is obviously going to bring its challenges. The whole collapsing thing, now feels clunky both in terms of interaction as visually - but I feel we have actionable issues to solve. We should however keep the big picture in mind, the goal is that this new pattern allows you to easily move down without losing orientation - we should validate that it actually does that.

I look forward to more discussion and patches :) It'd be good to also get some of the other Seven conversions started.

jessebeach’s picture

I'm leaving this issue as "needs work" because this patch is not meant to be considered a candidate to commit. Rather, it's a continuation in a discussion about the design and implementation of a responsive toolbar in Drupal core. And hopefully a jumping-off point for others to get involved. I see the core Toolbar as the simplest possible expression of a flexible, usable navigation mechanism for Drupal. There are numerous modules in contrib that have more features and more complex interactions. What we need here is a great out-of-the-box experience that doesn't try to do too much, but that doesn't fail at doing enough and doing that well.

The following are improvements from the patch in #59.

  1. Responsive layout of the toolbar from 0 to infinite width screens. No jumping to two levels.
  2. Cleaned up CSS
  3. Cleaned up PHP. I removed crufty elements left over from refactoring.

The following are issues that still need to be adressed. This is where you can help out with code!

  1. The info in toolbar_help needs to be updated to reflect the new interactions patterns of the Toolbar.
  2. On mobile devices, the toolbar tray doesn't extend to the bottom of the screen when the content is longer than the toolbar. I've been looking at m.facebook.com for inspiration, but unlike a dedicated web app, our implementation has to take into account an unstable DOM environment that any module can alter. I'm still spinning on the best way to approach this. Input would be great.
  3. Although the sidebar tray improves the "mobile" (small screen, large text size) experience, it may not be the ideal interaction for a desktop use case. We need to explore how to augment the responsive Toolbar so that desktop users have an optimized experience given the larger screen real estate available to them.
  4. It would be great to be able to swipe the toolbar tray off the screen once it's activated. Have experience with touch-base interactions? Pitch in!
  5. The center area of the toolbar is intended for modules to inject page-specific actions or controls. We've experimented with using MENU_LOCAL_ACTIONS to register these actions, but that just doesn't seem to be the right mechanism. At the moment I've fallen back to carving out a space in .toolbar-bar .section.actions that flexes its width to fill in the available space between the navigation and user buttons. Module could use JavaScript to plunk their controls into this space. Not ideal, I know. Better options would be much appreciated.
  6. I can only imagine this code is an accessibility nightmare. I apologize. It's not a reflex for me yet, but it is a standard, so we'll get there.
  7. The separation between base.css and theme.css is not quite right yet. I keep improving it with each pass. It needs a solid pass working with Stark without the theme.css file loaded to get it right.
  8. Introduce keyboard shortcuts to access the toolbar. This is something any modern webapp worth its salt has in place. Normally, pressing shift + ? will bring up an overlay with keyboard shortcuts. Try it on gmail or twitter.com. For the toolbar, it would be nice to be able to dismiss the tray with the esc key and open the tray without another combination.
  9. And incorporate Bojhan's comments in #69
webchick’s picture

Issue tags: +Accessibility

We also had a long discussion in IRC about the point about mobile vs. desktop navigation and how to handle that. Right now, this patch assumes that we're replacing Toolbar entirely with this, so this same interaction happens on both wide screens and small screens. This might not be the ultimate thing we want to do, and we haven't really discussed the desktop navigation experience as its own thing.

Bojhan advocated making the navigation in this patch only work on mobile devices as a stop-gap. Unfortunately, doing so would introduce a severe JS performance penalty on every single authenticated page load for every single desktop user, because the only way to do this right is to show mobile first and then use fancy JS math to expand out to the old UI from there.

Consensus was therefore to work on getting this patch in its current form to RTBC and commit it soon in order to satisfy feature freeze, and tackle the larger problem of enhancements for desktop UX in #1800618: Improve the desktop (large screen) UX of the responsive Toolbar as well as a discussion in the Usability group to a broader audience. With this patch in core, that conversation becomes "Download Drupal 8 and try it" and not "Check out this sandbox from Git, apply this patch, and..." :P

The only issue in Jesse's list in #70 that I think is not puntable to a follow-up is #1800614: Improve the responsive toolbar accessibility. While I'm comfortable postponing accessibility perfection to post-feature freeze, the toolbar itself is absolutely critical to navigating a Drupal website and we can't go from being the #1 most accessible open source CMS to Everett suddenly unable to use it in one patch. :) We need to ensure at least a baseline of accessibility via keyboard/screenreader in order to proceed. Tagging.

Bojhan’s picture

Sorry, but I don't think it is reasonable to put in a massive change to the UX of navigating for all users (desktop), with almost no discussion nor user testing data. Could you please read this sentence again, and think about how ridiculous that sounds.

There can be a million technical reasons, but there is no way to justify the fact that we are changing a fundamental, most important concept of Drupal - with no research or discussion. It's all cute and all that we can fix it afterwards, but that rarely happens and promises that it does - rarely come true.

I don't think I was just advocating, this is the navigating of everything - its not something small. I don't really see the point to being the UX-maintainer if I am not even in control of what the primary navigation method of core is.

catch’s picture

I'm not at all convinced about shipping a tonne of HTML around on every request for the menu tree, especially if it's going to includes things like every admin link on the entire site - that means a much bigger DOM etc.

I also agree with Bojhan that this needs some more serious usability testing and discussing before it goes in. The toolbar and Seven are the only things from D7UX that I actually use, and part of why I use the toolbar is I hate drop-down menus, especially given the lop-sidedness in terms of core admin IA at the moment (content vs. config for example).

Also there's no consensus if someone vetoes.

moshe weitzman’s picture

@catch - this can be what we want it to be. If we only want to show menu items 4 levels deep, we can. And we can limit the number of siblings if we want. Folks can always navigate down using links in the body of the page. Or we document that modules should not create hundreds of visible menu items. That goes along with our thinking to reduce number of routes.

jessebeach’s picture

Bojhan, Catch, then what we're left with is criticism, stalemate and no viable alternative. If we do nothing, we have a very broken admin UI on small screens. If you're going to completely toss out this line of design, I think an alternative design should be proposed. As the UX-maintainer, what design direction do you think we should take? We might still have time to redo this work, but we're losing or have lost the time to do anything complicated. We're left with time for a simple fix if we change direction.

webchick’s picture

I guess from my POV, this has been discussed already for nearly 12 months in various g.d.o discussions, here in the issue queue, videos, BoFs, etc. etc. We're now less than 2 months prior to feature freeze, and we have a viable patch here which incorporates the main ideas from everyone in the community who's worked on this problem space so far. It's definitely not a perfect patch, but it does solve the critical problem of mobile navigation being utter shite on stock D8 today, and can continue to be iterated on from now until release.

Acquia has dedicated some people towards solving this issue (well, for now... if it looks like this is headed to nowheresville, we'll need to re-allocate our folks on other issues, or back to contrib entirely :\), but we can't work with feedback that's not clear/actionable. "Needs more discussion" and "needs serious usability testing" is neither clear, nor actionable. What are your specific concerns with the design, and what improvements/tests could we perform to help assuage them?

sun’s picture

Outputting the entire administrative menu link tree definitely needs a lot of careful considerations. Doing it without any advanced techniques definitely adds a significant amount of server-side as well as client-side processing overhead to all pages, in addition to the vastly increased total page size.

The negative consequences were so large that admin_menu (3.x) had to introduce a smarter way to handle the toolbar/menu, commonly known as client-side caching. And that was even required for desktop already, before the rise of mobile.

In general, I agree with the need for a mobile compatible styling for the toolbar, but I strongly disagree with the chosen approach to attack the problem space here, which turns the entire toolbar into a sidebar in all cases. The sidebar approach is detrimental, does not scale, and has many negative consequences that only become apparent during actual usage. (We explored it for admin_menu some time ago.) In fact, the entire current efforts remind me again of the Toolbar in core effort for D7, for which years of experience was straight-out ignored. Anyway. We've been there, done that for D7 already, so I don't think I have anything positive to add to this and related issues, so I'll stop here.

Bojhan’s picture

@jesse I do not toss out the whole design, as mentioned in both comments above - I only disagree with replacing the desktop ux - without any discussion. Again, I fully support moving forward on the design for the mobile UX

@sun During D7UX we did ignore much of your knowledge, and I am sorry that we did. Although I do still stand by the reasons we had than not to include it. All that a side, I agree that a horizontal menu has much more problems than a vertical dropdown.

@webchick Feel free to point me to one place, where it was a discussion by the larger community to replace the desktop UX. We discussed the mobile ux, that's all - and that's also what we are pushing forward on. Somewhere down the road it was decided we also need to radically replace the desktop UX, that was not discussed nor agreed upon by the larger community.

The fact that we now decided that changing mobile UX is dependant on desktop UX seems wrong to me, although its technically no-doubt harder to change the desktop UX afterwards - its not impossible.

There are a many concerns, regarding the desktop UX (this only concerns, the fly-out menu approach):

1) The usability testing done, identified serious issues - mostly attributed to the IA. Proposals by jeff and dharmesh, focused on providing better navigation to actions, and tools in structure. How is that reflected in the new design?

2) Conceptually, why do we go with a horizontal bar (other than consistency). When admin_menu has proven itself to be a effective interaction pattern (in general, the top-down menu approach, is really effective), that we now replace with a horizontal menu that to my knowledge is less effective with depths (most horizontal menu's go 1/2 levels max).

3) The menu options available are quite random as I noted in #69, is this by design or was this simply not yet considered? Much of the issues that admin_menu has is not with its interaction pattern, but the usability of the actual items (logical labels, clear hubs and spokes and their relationship).

4) This model basically assumes we have no overlay - because otherwise you are left with a very small horizontal space. At what point did we decide after all that battling, that the overlay as a concept isn't useful? (Yes, once Edit is in, we lose one reason, but contextually editing blocks/layout/views etc still to me is a great reason to keep it).

5) Is there a reason for the navigation to be this prominent, we are basically taking 30% of the page. Which is valuable real estate, when you are deep inside the field ui, blocks ui, views etc. The reason I always liked admin_menu, toolbar and other concepts is that they didn't require much screen real estate - so at all time you could focus on your task.

These are just the larger conceptual questions, I am not even commenting on the details. And the issue queue is not necessary a good way to discuss these, where as the g.d.o/usability group is.

Last night we discussed over IRC what the action items would be - so lets repeat I thought we agreed upon:

1) A discussion/proposal is opened about the desktop UX change on g.d.o/usability (through discussion we outline, what we want to test, and whether this is the right direction).
2) We remove the desktop UX change from this patch, so we can focus the discussion on providing a great mobile UX.
3) We get more publicity on these mobile UX improvements, because navigation is just one of the issues we need to solve - it has very little visibility.

Its sad that the Spark team hasn't gotten significant improvements into core, but there is a review process and that always takes twice/three as long as fitting to any deadline.

jessebeach’s picture

On the contrary Sun, I think you do have extremely valuable input for this issue. You've essentially built this type of menu already. You're warning us there be dragons with this approach and we need to heed that.

So let's step back and ask what the fundamental problem is and solve that first. I think it's this.

Screenshot of the iPhone simulator showing a stock D7 site with the Toolbar smushed into the upper third of the screen.

We can't ship D7 like this, with 1/3 of the screen real estate eaten up by the Toolbar and Shortcut bar. I think we all agree on that.

The simplest solution I can think of is fold what's there now into a single slidedown menu like Twitter bootstrap does and be done with it. Don't touch the PHP or template for Toolbar. We leave Shortcuts as is.

msonnabaum’s picture

Concerning the performance issues that catch and sun have raised:

What if instead of rendering the entire menu tree, we instead pass the return value of toolbar_get_menu_tree() as JSON via #attached. We could then use a custom Drupal.theme function to render each level of the tree client-side as they are requested. That way you'll never have more DOM elements than are being displayed at any given time and it'll likely be fast enough to not introduce an unacceptable amount of delay like ajax would.

Noyz’s picture

Couple thoughts on this issue.

First, there are points made above that are I think are only half the story and should be vetted via usability testing (which we'll do), but wanted to call attention to a few since testing won't flush out all of them.

  1. Fly-out menus can be designed to work without usability issues. See any OS. Pre D7UX, I heard a lot of people hail the 'usability flag' over Admins' fly-out menus, but Admins' IA wasn't right, and the hit targets were very small
  2. Sidebar, vertically stacked nav is not a bad idea. Large trees that cause performance issues, maybe, but let's separate the two. The themebuilder in DG is horizontal, and man, what a mistake. There's so much more horizontal real-estate than vertical. Additionally, many tools use a sidebar nav effectively: Squarespace and Wordpress are both decent examples. Last, there's nothing saying that this new toolbar couldn't have a toggle to set the orientation to be vertical or horizontal, with the caveat that the vertical setting will orient to horizontal on mobile devices (or similar)
  3. While there seems to be an endorsement for a mobile toolbar over a mobile AND desktop toolbar, that idea seems driven over A) possible usability concerns (which we can vet) B) time (which we can keep a close eye on). We should shoot for a comprehensive, unified toolbar and let testing tell us if that's a bad idea.
  4. The decisions made in D7UX to flatten the toolbar to a single level have produced issues. Some of you may like it, but make no mistake about it, getting oriented in Drupal now takes longer because now multiple clicks and multiple page loads are involved to reach a destination. If you're not sure of your destination, that's a serious pogo-sticking problem.

Second, I agree with @Bojhan @catch regarding testing. We should be sure this works. For that, let's have Dharmesh run some tests to guide us.

Last, if there are performance issues with stacked menus, that seems like one of the more important issues raised. Im not sure how real those are, but it seems that Spark team can validate this and adjust accordingly.

catch’s picture

@webchick, I raised two specific concerns:

1. There's no sign of usability testing on this issue. Currently the proposal is not only to add a new UX for mobile users but to radically change the desktop UX, that needs verification.

2. There's an obvious performance issue with the current implementation.

In fact some more detail on the performance issue, because there's two parts to it:

- the large HTML tree of links means more bytes to transfer, and more work for the browser.
- presenting every single admin menu link on every single page means checking access to every admin path, this can have a very, very serious performance hit, similar to the problem in #296693: Restrict access to empty top level administration pages. We also do no caching of rendered menu HTML at the moment and rendering menus is very expensive too.

I'm not sure why this is dismissed as 'criticism with no viable alternative' and 'what are your specific concerns?'. Thankfully other people have responded to the points raised.

@msonnabaum, yes that might improve things, even if it takes a bit of time to load the json, it's a question of the trade-off vs. the initial page load time.

Also this needs much, much more explanation:

Unfortunately, doing so would introduce a severe JS performance penalty on every single authenticated page load for every single desktop user, because the only way to do this right is to show mobile first and then use fancy JS math to expand out to the old UI from there.

We can do that calculation during the first authenticated hit to the page, then store it in session, which should be unique to mobile vs. desktop browsers even for the same user (although I have a feeling that chrome has a feature which might break that assumption, but that feature scares me so I haven't tried it). Either way doing it right means a lot more than strict adherence to 'mobile first' with no regard for anything else.

tkoleary’s picture

@sun I think we can offer both options as admin tools does. I'm working on a horizontal design.

jessebeach’s picture

Sorry Catch for the "criticism" jab. I let my frustrations bleed into my comments rather than being constructive myself. I won't let it happen again.

What I wanted to express is that we're left with no alternatives if we simply tear apart proposed solutions without offering alternatives or ideas to correct the issues raised with the current solution. Could we not add a cacheing layer around the menu retrieval function menu_tree_all_data?

I was left with a feeling of "well now what do we do"?

dcmistry’s picture

Hello all,

I have started working on the usability testing study (with @bojhan) and the plan is posted in the usability group. We want to test this as soon as possible, so please provide your feedback and we will update the guide so that we can begin testing.

Important note to consider the focus of the study for now is on the toolbar on a mobile device (iPhones and Android) [not the desktop experience atm]and want to data around the interaction pattern. What about the IA? Yes, we know that has been an issue. A while back, I wrote a blog post about that. But that is a discussion for another thread.

What do you say?

Dries’s picture

There appears to be some emotions in this discussion, and some appear to be somewhat personal. We should try to put these aside, and make decisions in the interest of the Drupal community at large.

I hope we can all agree that we can't ship Drupal 8 without a good mobile toolbar/experience.

We'll have to commit the best solution, even if it is not perfect. Let's all work together the next couple of weeks to resolve the outstanding issues and evolve this to something we like.

I appreciate the desire for openness and feedback on the design from the usability group, but it should not hold up the patch. There has never been a mandate to discuss things in the usability group on g.d.o. There was plenty of time for feedback, starting with Lewis' designs that were shared months ago, to videos being shared, to designs being presented at DrupalCons and more.

Design is very personal, and we’ll never both make bold changes to Drupal and make everyone happy with them at the same time. If we find real issues based on UX testing, we can and will make changes to the design.

I still want to see a coherent user experience across mobile and desktop navigation, and that is what we should try to achieve. So I support the patch in its current form, which unifies these experiences. Hopefully the UX testing will help guide us on this as to the proper approach.

The things we must resolve before this can be committed are: usability testing and accessibility testing. It sounds like we're starting with UX testing over the weekend with Bojhan's, Dharmesh's and Kevin's help. Great!

Performance testing can be done after feature freeze; we know we can make it performant because admin_menu is performant. We can learn from admin_menu which should make it fairly straightforward and why I think this can be postponed.

I'd really like to make a decision on this in next couple of weeks, so let's all work together the next couple of weeks to resolve the outstanding issues. To sum it up, we should really focus on usability and accessibility testing, and address performance and broader design discussions after feature freeze.

catch’s picture

I'm not prepared to see this go in without performance testing. We have gates for a reason, and have committed performance regressions knowingly when they're part of massive deep refactoring efforts that should improve performance (or be neutral) eventually, but this isn't doing that - it's a straight change to an end-user facing feature, so it needs to not make things worse.

If we're going to start committing performance regressions willy-nilly because "they can be fixed after feature freeze" then we need to have a serious discussion about the schedule because that's never been my understanding of it and I've no intention of adjusting my understanding to a world where that's the case - sounds far too much like Drupal 7 to me.

Everett Zufelt’s picture

@Dries wrote: "Performance testing can be done after feature freeze". I don't understand how this aligns with the D8 gates.

catch’s picture

@jessebeach:

Could we not add a cacheing layer around the menu retrieval function menu_tree_all_data?

Menu item access is completely arbitrary, it usually depends on permissions but it could depend on anything at all, so we've never, ever cached that except as part of full page caching for anonymous users, and I'm not aware of any issues to do so. I'd love to see work done on that, but no-one's doing that at the moment and it's an area that's in massive flux now the new router's gone in (we're not even sure what access is going to look like for the new router except that it'll likely be a lot more complex than it is currently for the menu system).

Bojhan’s picture

We are only going to test mobile right now, although this will give us some insights its not enough to go on for the desktop UI decision, that will need separate testing and discussion.

I feel we are getting the no, for just the normal review/discussion process - it is not unreasonable ask to have some discussion about the desktop UX (again, I am not asking for a full UX-team process iteration/research/validation/proposal). But I am asking to have a proper discussion about it, like we do with all changes. It now sounds like all we need is testing, which is not a replacement for discussion.

dodorama’s picture

Can anybody clarify if this proposal ditches the overlay for mobile AND desktop?

LewisNyman’s picture

I don't want to throw another spanner in here but as well as 'mobile vs desktop' this patch also an effect on 'tablet'.

The original title of this issue avoided the word 'mobile' and phrased the requirements as 'small screen and touch screen devices' for this reason. There are two variables that can be combined, the size of the screen and the method of input.

  1. Small screen without touch
  2. Small screen with touch
  3. Large screen without touch
  4. Large screen with touch

Whatever pixel width breakpoint we choose to define 'small screen' is minor issue. I just want to make sure when we are talking about what UI we have on 'mobile' or 'desktop' we are specific about which of the device groups above we are talking about.

Not trying to hold anything up, I just want everyone communicating on the same page. Some of these UI elements or interactions make sense for a small screen, some make sense for touch screens.

moshe weitzman’s picture

Overlay is already disabled for narrow screens. That went in a couple months ago. See #1260800: Kill the overlay for widths below 640 pixels

Noyz’s picture

@Bojhan "We are only going to test mobile right now, although this will give us some insights its not enough to go on for the desktop UI decision, that will need separate testing and discussion.

Dharmesh will test both to help alleviate or validate any issues brought up.

catch’s picture

Title: Redesign navigation for smaller screens » Redesign toolbar from the ground up so it works on mobile/tablets as well as desktop

Re-titling so it's more obvious/accurate what the issue is about.

cosmicdreams’s picture

Title: Redesign toolbar from the ground up so it works on mobile/tablets as well as desktop » Redesign navigation for smaller screens
FileSize
103.68 KB
85.4 KB

Can we keep the expandable sidebar but only list the top level of links? Like this without the arrows:
Screenshot_2012-10-04-09-18-03.png

Also here's the styling glitch I with Firefox Mobile I mentioned last night:
Screenshot_2012-10-04-09-20-21.png

Edit: Whoa! sorry folks, I had no idea these screenshots were so big.

cosmicdreams’s picture

Title: Redesign navigation for smaller screens » Redesign toolbar from the ground up so it works on mobile/tablets as well as desktop

Looks like I stepped on catch's title change

tarekdj’s picture

Hi all,
I worked quickly on this module responsive admin menu . Not perfectly coded but can be useful ;)

Dries’s picture

To make this perform, can we not base a solution on whatever admin_menu module uses to successfully address similar performance problems?

Maybe sun is willing to help with this as he is the expert here, and it could mean admin_menu becomes a bit smaller as it could leverage helper code in core?

tarekdj’s picture

@Dries this is just a sandbox that will not evoluate to a module. It's just an experimental work to see different approaches.

dcmistry’s picture

Quick update on UX testing

Based on the initial feedback on the test plan, Bojhan and I have changed the plan that will focus on mobile and desktop experiences. The new plan will focus on the following:

  • How do users use the toolbar on their mobile devices and on their desktops?
  • Are the users able to easily navigate to the tasks that they want to perform?
  • Do users understand the interaction pattern of the toolbar?
  • How does the experience differ when on mobile and when on desktop?

Please take a look at the updated plan and provide feedback. It is crucial that we agree on this before we start testing on October 5, 2012.

Do note that we will be testing only iPhone and Android users for this study. It gets complicated to get meaningful results if we don't segment users into "categories".

effulgentsia’s picture

I think this issue could use an updated summary that mentions the current state of things, and what the remaining agreed todos and areas of disagreement are.

effulgentsia’s picture

Menu item access is completely arbitrary, it usually depends on permissions but it could depend on anything at all, so we've never, ever cached that except as part of full page caching for anonymous users, and I'm not aware of any issues to do so.

25% of D7 sites use admin_menu 7.x-3.x, which caches the result of menu_tree_all_data('management') plus various admin_menu enhancements and altering plus rendering all that into HTML links into {cache_menu} with $cid = 'admin_menu:' . $user->uid . ':' . session_id() . ':' . $language->language;. It only does so if variable_get('admin_menu_cache_server', TRUE) is true, but a) that's the default, and b) admin_menu provides no UI to change that setting.

Would this be an acceptable thing to do for this issue, replacing 'admin_menu' with 'toolbar'?

Admin menu also implements client-side caching, but that's a separate issue. It helps reduce some kb from subsequent requests, but doesn't offload {cache_menu} from getting populated with lots of entries, because each session's initial request is still cached server-side.

moshe weitzman’s picture

My memory is hazy, but I think admin_menu has had trouble with excessive menu rebuilding in the past. This suggests invalidating that cache may be tricky. I'd love to hear more about I call this acceptable.

geerlingguy’s picture

Just a quick note on the performance hit: I'm in agreement with catch in #87.

(First of all, jessebeach et all—great work on this patch so far! It does look nice and function well!).

In evaluating how admin_menu worked on a few different sites, I found that it caused noticeable lag on mobile devices (especially on slower Android phones and tablets) on the front-end—the lag wasn't terrible, but it was noticeable. Additionally, the amount of extra work in determining menu access for a few hundred links and users on an active site would kill D8 performance on the back end (caching is not a very good solution if there are hundreds of sets of menu items to cache!), and having all that data available on the front end, and the DOM manipulation to handle it, will also noticeably slow down the front end.

For sites where you have just a few admins with access to admin_menu (or this kind of toolbar), the problem isn't so bad... but for any site where there are more than a few active authenticated users, you will not be doing them a favor by enabling admin_menu-like functionality by default.

I'm in favor of at least reducing the menu tree levels that would be accessible. I have no problem tapping a link to get to an admin index page (like 'Configure'), then choosing my option there.

mgifford’s picture

tagging

effulgentsia’s picture

Re #105 and #106: do your comments apply strictly to admin_menu 3.x? I ask, because admin_menu 6.x-1.x (which is the only one with full stable releases) does no caching at all.

geerlingguy’s picture

effulgentsia - admin_menu 7.x-3.x-dev exclusively.

catch’s picture

@effulgentsia/Dries: i don't know about trying to re-use admin_menu caching.

I'd love us to try to cache menu HTML output because that would be a win elsewhere, but it feels like we could come up with something that's built into the menu output functions rather than hard-coded to the toolbar - so it benefits other places menus are output oo. afaik there's no open issue to discuss caching menu HTML output either.

Apart from the access/invalidation issues menu also sets the active menu item in PHP - iirc (and it might be out of date), admin_menu has custom js to update the markup on each page request - that's not acceptable for core so we can't simply transpose it, we'd need to fix the markup to make it cacheable in the first place. sun obvously knows a lot more about this topic than me.

None of this gets past the fact that it's still a massive, massive chunk of HTML to schlep around.

@moshe I don't think the admin_menu menu rebuild issue was necessarily related to caching, I think it's because admin_menu was keeping it's own parallel menu separate from the actual admin menu or something, but that's also half-remembered and way out of date at this point.

effulgentsia’s picture

I'd love us to try to cache menu HTML output because that would be a win elsewhere... afaik there's no open issue to discuss caching menu HTML output

I opened #1805054: Cache localized, access filtered, URL resolved, and rendered menu trees as a critical task.

I'm in favor of at least reducing the menu tree levels that would be accessible.

How far would we need to reduce it to in order to not have to solve the server-side caching problem? If we manage to agree on what that level is, and on changing the designs to it, then I'll downgrade #1805054: Cache localized, access filtered, URL resolved, and rendered menu trees to not critical.

dcmistry’s picture

Bojhan and I have completed the usability study on the toolbar.

Summary of findings
Overall, the toolbar prototype tested well on desktop and iPhones.

“This is a big improvement from where we are at [right now]” (P4)

Most of the participants (4 out of 6) had positive reaction. The rest of the participants (2) had a neutral response to the change. The mobile version was significantly better received than the desktop experience.

It is also worth noting that participants were mostly neutral about having different mobile vs. desktop versions of the toolbar.

Major Positives:

  • Participants thought that the design was clean, usable, with “nice” icons and was visually appealing.
  • Participants responded very positively to using it on a mobile phone, it was recognizable and easy to navigate.

Major Issues:

Detailed findings of the study can be found here: http://groups.drupal.org/node/260203

tarekdj’s picture

webchick’s picture

Here's just a re-roll against current 8.x. Leaving at needs work.

The user testing results have been up for a couple of days now, and so far we haven't seen any comments on them, other than tarekdj's design proposal at #1807432: Collapsing menu items through > are not discoverable - nice! :D The findings reported that "Overall, the toolbar prototype tested well on desktop and iPhones" and "participants were mostly neutral about having different mobile vs. desktop versions of the toolbar." Menu caching performance is being dealt with at #1805054: Cache localized, access filtered, URL resolved, and rendered menu trees. Kevin's also putting together a blog post and video to talk about the design a bit more in-depth.

Does this unblock us from proceeding with cleaning up the design/code in this patch and getting it ready for review? Feeling a little stuck at the moment. :\

sun’s picture

I don't have time nor will to prove and convince you that it is wrong, but if you want to pursue a vertical sidebar interface orientation change for desktop, then you should collaborate with the architects, designers, developers, but also users of

and at minimum ask them about their real world experience, problems, ideas, and criticism first.

For admin_menu, this will just mean another, new visual style for D8 (just like the "Toolbar" style for D7), and turning styles into plugins, as well as turning the actual toolbar elements/parts/contents into plugins, is on the roadmap anyway already.

tkoleary’s picture

@sun The existence of supernav, navigate and admin is a validation of the user need here. All the interaction patterns of those modules are in place in navbar. Like I said before, though, I don't think the two approaches are incompatible. If users want horizontal orientation they should be able to configure that.

jessebeach’s picture

I always reach a point of design paralysis when I go through the thought game considering how a split "mobile" and "desktop" UX for toolbar would work. Here's the process.

  • Let's acknowledge that the "desktop" presentation of the toolbar doesn't work on a narrow screen.
    • Screenshot of the iPhone simulator showing a stock D7 site with the Toolbar smushed into the upper third of the screen.
  • Let's accept that we won't change "desktop" toolbar experience -- a horizontal presentation of the menu.
    • Screenshot of a D7 toolbar, displayed well in a 992px wide screen
  • We must now define what "desktop" is.
  • Let's assume "desktop" is anything as large or larger than a tablet.
  • We must now define what a "tablet" is.
  • Let's assume that a "tablet" is 50em wide (~800px). Yes, it's an arbitrary number, but we need to assume something. Samsugn Galaxy Note.
  • The current D7 toolbar breaks at 50em width
    • Screenshot of a D7 site at 50em width
  • Let's widen the screen until it doesn't wrap. At 54em (~868px), the toolbar doesn't wrap. That's not too much larger. We could perhaps reduce the size of some items in the toolbar, but we probably can't get the toolbar much smaller than 800px minimum width, so a horizontal presentation must start at 50em for "tablets" and "desktop".
  • Everything below 50em width is "mobile".
  • If ANY modules add a top-level item to the management menu, the horizontal menu will wrap or they will need to override the breakpoint between "mobile" and "tablet/desktop" of the toolbar.
  • Let's assume no module will ever add a top-level menu item, no module will affect the text size of the toolbar and it will never wrap (big assumption).
  • So now we have a breakpoint between "mobile" and "tablet/desktop".
  • Let's assume some kind of vertical presentation is necessary on narrow screens -- a side tray or a push-down list of items, that's arbitrary this point. Just details.
  • A side tray presentation has precedent in other "mobile" experiences e.g. m.facebook.com and Google+
    • A screenshot of m.facebook.com with the mobile menu tray expanded from the left-hand side.
    • Screenshot of a side tray menu presentation on the Google + web app.
  • This is where I also note to myself that a vertical menu presentation has precedent in other "tablet/desktop" experience as well, such as WordPress and again Google+
    • Screenshot of the vertical admin menu in WordPress 3.5
    • Vertical menu presentation in the desktop experience of Google+
  • But we accepted that we don't want to change the "tablet/desktoop" UX, so I ignore these examples of successful vertical menu presentations.
  • Now I consider the technical challenges of maintaining two different toolbar UX presentations.
    • There's more code to write/maintain
    • We have to choose when to switch between the two (see assumptions above)
    • We have to switch between the two, so that either means mobile will take a performance hit or "tablet/desktop" will take a performance hit to shift the default UX to a different location in the DOM (assuming this would be necessary, but it might not be true) and a different structure (we'll at least need to unbind events, bind new events and change up classes) at the very least on screen resizes.
    • We'll need to account for screen resizing and vary the behavior of the toolbar accordingly. We might need this any case, though.
  • Then I think, well, do we want to take on so much extra work when there are examples of successful vertical administration menu presentation across "mobile" and "tablet/desktop". What really is the conceptual blocker and what are the technical blockers to a unified administration menu UX?
  • This is where I reach paralysis, because in this thread, we have equal-weight community voices advocating for and against the unified UX approach. And I have to question my resolve because they obvious know something I don't, but the alternative they're suggesting still itself requires design work and has significant technical hurdles as well (as far as my assessment goes).

So to sum up, it seems we have two proposed approaches in this thread.

The split "mobile" vs. "tablet/desktop" admin toolbar UX

We decide to keep the "mobile" and "tablet/desktop" UX presentations separate (retain the current desktop UX more or less). What are this issues as I see?

  • There are still technical hurdles with this approach. We presumably can solve these as well.
  • We still need to solve the "mobile" presentation issue. All of the problems from the unified admin toolbar approach are still present with the added challenges of the desktop UX. Maybe we leave the UX of "tablet/desktop" as is, though.
  • This approach will involve more code and presumably more processing on the front end to switch the default "mobile" UX to a "tablet/desktop" UX. Our "tablet/desktop" users will take a performance hit, perhaps only a small one, sure.
  • Design and UX behind this approach are lacking. At the moment the design is "don't change the desktop UX". Is that enough?
  • "tablet/desktop" users don't need to learn a new admin UX.
  • User who switch regularly between "mobile" and "tablet/desktop" need to learn two UXs. This is not unprecedented, for sure.

The unified admin toolbar UX

The issues I see with it are.

  • There are technical hurdles to overcome with a vertical menu presentation. This is made very clear in the comments of this issue. Can we not overcome these?
    • As sun points out in #115, We have several excellent contrib module efforts to guide us.
  • We gain a consistent administration experience across any screen size.
  • No need to decide what constitutes "mobile" size and what constitutes "tablet/desktop" size and ensure that is a future-friendly decision.
  • Less code -- we don't need to switch between UX presentations of the toolbar.
  • We have design resources behind this approach.
  • Users need only familiarize themselves with one admin UX experience.
  • There are small improvements we can make as we go along, such as pinning the side tray open on larger screens, reducing the interaction by one click.

Closing thoughts

I remain open to alternatives. Always always always. I work on the basic assumption that we're all smart people with good intentions and strong opinions. I'm not convinced that unified admin UX approach is THE best. I am convinced that it is a solid approach with legitimate precedent in the current market of web properties. In a very real sense, I'm simply a development resource that will build what we propose here, as long as we agree on an approach.

Of course the concerns raised in thread give me pause. What I'm struggling with is that the concerns are not offered with alternatives, just admonitions of how not to proceed. We can't improve this toolbar UX by simply defining how we shouldn't do it -- that's an infinite set. In this case change will be better than no change because no change means we ship with broken UX.

So for folks who want to keep the "tablet/desktop" UX experience the same, do you think the technical and design challenges I raise above are legitimate? Are they more easily addressable than the challenges posed by the unified experience? Personally, I think both approaches will be challenging -- and both are achievable. I simply see more work involved with keeping the "tablet/desktop" UX intact and the possibility for more trouble at the breakpoint between "mobile" and "tablet/desktop". I like to remind myself that we're not building the ultimate Drupal responsve toolbar experience; rather, we're building the solid Drupal responsive toolbar experience that contrib modules will of course improve and replace. What we want now is something quick to implement and simple to maintain -- and something that works better than what we've got.

effulgentsia’s picture

Thanks for #117. That's helpful, at least for me, in getting a bit more up to speed on the problem space here.

Is there consensus at this point that we need/want a vertical toolbar for narrow screens?

If so, would it help unblock anything if we approached this issue as a create a toolbar_vertical.module rather than a change toolbar.module? That way, we can work on solving all the technical issues that need solving for that. Then, after we have both a toolbar.module and toolbar_vertical.module in core, we can do more testing on which is a better wide screen experience. If it turns out that we can't make toolbar_vertical as good on wide screens as toolbar is, then we can brainstorm on how to make it swap responsively, smoothly, and quickly. Feel free to shoot this idea down if it's stupid.

David_Rothstein’s picture

As far as I can see, the issues we have with the toolbar on mobile are actually pretty minor. Redesigning the entire admin interface (either for mobile or for desktop also) seems like overkill for the purpose of fixing these issues.

That is not to say redesigning it is necessarily a bad idea, but that discussion really needs to stand on its own and the bar for that has to be a lot higher.

So, in the spirit of @webchick's comment in #60 ("getting something basic in so that Drupal 8 doesn't look [terrible] out of the box"), I wrote a quick patch that addresses what appear to be the biggest issues with the toolbar. The patch is attached, and screeneshots are below. Basically all it does is hide the toolbar menu under an "Administer" link when the screen is too small (and makes a couple other tiny adjustments). It does not require a mobile breakpoint; instead, the behavior adjusts naturally regardless of the screen size. For large screens, it's exactly the same as it is now.

I don't claim this code is any more than a rough prototype at this point; however, it only took me about 15-20 minutes to write so I figured it was worth posting in its current state :)

After I wrote it, I realized this is very similar to what @dodorama proposed in #12... oops. (And @dodorama's code is likely further along than mine, although I'm not sure where the code actually is.) In any case, after reading this issue, I don't see any fundamental reason why this very simple direction was rejected in the discussion above.

So I'm curious what people think of the general concept. Here's what the patch looks like on mobile (initial page load):

mobile-page-load.png

And after clicking the "Administer" link:

mobile-after-clicking-administer.png

Clicking the "Administer" link again causes the menu items to be re-hidden.

There are some obvious refinements that could be made to make it look and behave nicer. And we could apply the exact same pattern to the shortcut bar also (which actually even has this problem on desktop to some extent, since some people like to add lots and lots and lots and lots of shortcuts). But I thought it was a good start for 15-20 minutes of effort...

corbacho’s picture

Nice summary Jesse!
I agree on the absolutely need of vertical menu for mobile/tablets. But I would prefer a horizontal toolbar after a breakpoint of 960px? or whatever px. As sun said.. there is many reasons why horizontal top bar is better.

btw, have you visited google.com in mobile phone lately? Some hours ago they redesigned the navigation with a sidebar flyout thing. But if you go to google in the desktop, what do you see? yep.. a horizontal top bar menu

Edit. David #119, I don't have 4 years-old kid fingers. That's not the way to go imho

David_Rothstein’s picture

Edit. David #119, I don't have 4 years-old kid fingers. That's not the way to go imho

Let me repeat once again where I said "There are some obvious refinements that could be made to make it look and behave nicer".... One of the obvious ones is of course to make the links bigger.

corbacho’s picture

... as big to fit a finger?... then it becomes the same than a vertical menu (at least in mobile phones) something similar also was mentioned in #15: http://twitter.github.com/bootstrap/examples/starter-template.html
EDIT. I see now that you were trying to make emphasis on "with only 3 lines changed, it becomes a possible solution", and it's something to be praised !. Sorry for being sarcastic before.

David_Rothstein’s picture

Yup, exactly... thanks and no worries!

It could very well make sense to turn it into a vertical menu (the version in #12 does that already, actually). I think that would just be a bit of CSS. But my main point is, as you said, that it seems like we could have a decent solution without too much code.

Perhaps it's so simple it could even be deferred until after code freeze (I don't really have time to work on it more right now either way). And if people want to try to get something more complicated committed in the meantime, that's fine too. But my motivation for posting it here was that it seems like this issue was at a bit of a stalemate between "do nothing and have a bad mobile experience" vs. "redesign and rewrite everything", but hopefully it's the case that there's actually a middle ground which is more like "tweak the existing implementation a bit so there's a toolbar-like experience which works reasonably well on mobile" instead.

JohnAlbin’s picture

But my main point is, as you said, that it seems like we could have a decent solution without too much code.

Fair enough. But that is not this issue. (Thanks, Catch, for updating this issue’s title appropriately!)

Perhaps it's so simple it could even be deferred until after code freeze

Works for me. Go and create a new issue and defer until after code freeze.

I'm not meaning to be glib, but this issue is one of the top 3 priorities of the Mobile Initiative. If we don't redo the toolbar so that it is amazing on mobile devices, then we will be left with a… well… a lame toolbar that “works”.

Right now, there is a lot of experimentation going on with mobile navigation in the greater web development community. I love this! And I want Drupal to be a leader in this space! :-) And not a follower that finally gets a proper mobile navigation experience in version 9. :-p

Also, menu caching would be nice to make this feature better. But I don’t see that this feature is dependent on that performance improvement.

David_Rothstein’s picture

If this issue moves in a direction where it would be possible to do both patches (#118 being an example of that, perhaps) then it's a good idea to open up a separate issue, but otherwise it's kind of an either-or situation so it makes sense to keep the discussion in one place.

I think my patch is consistent with the purpose of this issue, at least for the first 16 months of the issue's existence :)

effulgentsia’s picture

catch in #73:

part of why I use the toolbar is I hate drop-down menus

moshe in #74:

If we only want to show menu items 4 levels deep, we can.

geerlingguy in #106:

I'm in favor of at least reducing the menu tree levels that would be accessible. I have no problem tapping a link to get to an admin index page (like 'Configure'), then choosing my option there.

David's patch in #119 retains the HEAD toolbar that's one deep.

So, here's the addition (to #114) of a configuration setting to control depth. Defaults to 9, but catch can set to 1, geerlingguy can set to 2 or 3, and others can play with it too. Maybe at some point, we'll want to turn this into a per-user setting, but for now, it's just a site wide one.

nod_’s picture

Quick review :p

I doesn't work well with overlay, at all. The overlay shows below the menu, meaning below the fold all the time.

setHeight = ('debounce' in Drupal) ? Drupal.debounce(setHeight, 250) : setHeight;

This is unnecessary.

event.stopImmediatePropagation();
Is there a particular reason to not use stopPropagation?

var $wrapper = $root.wrap($('<div>')
        .css({
            height: '100%',
            position: 'relative'
          })
          .addClass('fleximenu')
        )
        .parent()
        // Bind event handlers.
        .on({
          'setup.toolbar': context.accordionSetup
        });

Can't the height and position attribute be set in the CSS along with the fleximenu class?
Also separate the wrapper and the $root element manipulation please, this is confusing.

var listUpdate = $.Callbacks();

I don't see the benefit of using callbacks since there is no way for contrib to hook into that.

      listUpdate.add($.proxy(context, 'markListLevels', $root));
      listUpdate.add($.proxy(context, 'setLevelVisibility', $root, 1));

Honnestly I don't really like that we don't send functions to proxy. That'll mess things up when we get around to using JS .bind.

  cleanItem: function (event) {},
  activateItem: function (event) {},

If it's empty it shouldn't really be there without a use-case (read, documentation).

 accordionToggle: function (event) {
    // The toggle.
    var $toggle = $(this);
    var $item = $toggle.closest('li');
    var $list = $item.children('ul');
    var isHidden = $list.hasClass('dormant');
    // Toggle the item open state.
    $item
      [((isHidden) ? 'add' : 'remove') + 'Class']('open');
    // Toggle the item list visibility.
    $list
      ['slide' + ((isHidden) ? 'Down' : 'Up')]()
      [((isHidden) ? 'remove' : 'add') + 'Class']('dormant');
    // Twist the toggle.
    $toggle
      [((isHidden) ? 'add' : 'remove') + 'Class']('open');
  },

That should be using .toggleClass(). It's not just there, it's all over the place.

// Initialize items and their links.
    $li
      .each(function (index, element) {
        $(this).data('toolbar', {
          processed: false,
          type: 'item'
        });
      })
      // Add a class to item links.
      .children('a')
      .wrap(
        $('<div>', {
          'class': boxClass
        })
      )
      .end()
      // Add a handle to each list item if it has a menu.
      .each(function (index, element) {
        var $item = $(this);
        if ($item.children('ul').length > 0) {
          $item
            .children('.' + boxClass)
            .prepend(
              $('<span>', {
                'class': handleClass,
                text: ''
              })
            );
        }
      });

I won't be maintaining that :þ please simplify and take it apart so that we can understand what it actually does.

$lists
.addClass('level-' + level)
.each(function (index, element) {
  $(this).data().toolbar.level = level;
});

This is wrongly indented. Several places like this.

 $('<span>', {
                'class': handleClass,
                text: ''
              })

theme function maybe? if not at least use .attr() not the jQuery shortcut.

Overall the JS seems overly complex to display a sidebar, and toggle the visibility of submenus.

Bojhan’s picture

I had a chat with @webchick about this all. We should have all just had that chat, it seems this issue got more out of control than needed.

I do not consider @David_Rothstein his proposal a very good compromise, to me that's close to not even trying to create a good UX and just putting something so its responsive. That strategy might be acceptable when this is not a very important part of our future, but given that mobile is very important I do not see creating a "well its works" UX as a good approach.

I will try to address this comment by following @jbeach her train of thought, she captures the concerns quite well. I am still advocating for a split "mobile" vs. "tablet/desktop" admin toolbar UX approach. However to much confusion, I am not advocating two modules. We should have one module, the toolbar that provides the correct UX depending on the screen size - a bar with only top levels on desktop/tablet and a sidebar with top levels plus depth on mobile.

User who switch regularly between "mobile" and "tablet/desktop" need to learn two UXs.

Yes, this is true. This however is fairly common, that the desktop experience and mobile experience have varying navigation methods. We tried to get a feeling whether people feel strongly about this, but in the testing we saw that people where largely neutral about this. Although I understand the philosophical reason to do this, I am not convinced that users find it such a big deal or whether creating the best UX per screen-size vs. creating the best unified UX has a clear winner.

What really is the conceptual blocker and what are the technical blockers to a unified administration menu UX?

There are a couple of conceptual ones, some could be solved while others are fundamental:

  • The usability of vertical menu's that go deeper is not very good (losing orientation), although the design basically only goes with a depth of one (top level -> categories/items). This is rather ineffective if you know where you are going. Much of the design stands or falls with this decision, I do not think we can truly find an answer to that in usability testing other than prolonged useage (which tha_sun apparently did with negative results). Most of the modules in this vertical menu space seem to allow this depth. The whole idea of the proposal seems to be that we get them quicker to where they want to be, and somehow it was decided that stops beyond one level. I find this decision somewhat puzzling, because we either provide them a quick way to get where they want to go or we provide them with a full page as to not overwhelm them. Now we provide them with a half-way there. On the desktop we have only top categories so the pages you land on can guide you, e.g Configuration allows for scanning where items are even if you can't find the appropriate category, that is now lost.
  • Fly-out menu's although arguably able to solve some of this depth, seem less fitting to me than dropdown menu's. Which is an established pattern, that is used in most applications. Although there are many examples of vertical menu's you will likely not find many that successfully go several levels deep.
  • The reason we never went with admin_menu was 1) In D7 navigating, wasn't just the problem it was mostly the IA 2) Admin_menu overwhelms people with all the options 3) Admin_menu still has a number of usability problems. Just exposing the top levels, means we allow people to not get overwhelmed and instead be guided by the structure of the page (e.g. on Configuration through categories, and on actual pages by tabs/actions). If we not choose to get them quicker to the admin items, and we only get them half-way I do not see the point of exposing depth. I can't believe I am advocating for the admin_menu pattern :')

Those are the larger UX conceptual reasons, besides the one I already noted in #78 of 2) admin_menu is a more proven interaction model, 3) menu options available are not streamlined 4) we have no overlay in this model as it would even further decrease width. Than I think there are still a couple of practical issues, from the shortcuts not scaling much beyond 2 lines to the critical issue of people not clicking the > on desktop.

Design and UX behind this approach are lacking. At the moment the design is "don't change the desktop UX". Is that enough?

No its not, but if we do decide to do only top-levels for the desktop version. I can imagine we should be able to hash out matching visual styling and similar placing of items. I do not necessarily see this is a big challenge.

So for folks who want to keep the "tablet/desktop" UX experience the same, do you think the technical and design challenges I raise above are legitimate?

Yes, and I think that's maybe what got this issue so fired up is that there are many pro's and con's to each solution. This is changing the heart of how everyone navigates, so it should be expected that such a radical change as this gets a lot of opinions. I do understand that either way, its going to be difficult to get this in both in getting it performant and getting the breakpoints desktop working.

I'm sorry if this issue caused frustration, lets see if we can sensibly give it the right direction. We can open up other issues, and trow patches at this. But I think we didn't really get to discussion, other than people waving red flags. @jbeach clearly outlines the concerns, and I tried to outline mine in #35 ,#69, #78 and now this comment.

effulgentsia’s picture

Thanks for the write up. I'm confused about:

The whole idea of the proposal seems to be that we get them quicker to where they want to be, and somehow it was decided that stops beyond one level. I find this decision somewhat puzzling, because we either provide them a quick way to get where they want to go or we provide them with a full page as to not overwhelm them. Now we provide them with a half-way there.

Was it actually decided anywhere to limit the mobile toolbar to depth of 2? That's not the behavior of #114 or #126: the behavior of both of them is unlimited depth. I opened #1812016: Does usability testing show any value of going more than 2 deep? to learn more about the usability benefit beyond depth of 2, but I didn't mean for that to imply any decision to not do it.

I do think it's worth thinking seriously about whether depth=2 on mobile makes sense, because IMO, it's *much* better than applying desktop's depth=1 to mobile (i.e., David's #119 suggestion), and it avoids many of the difficulties that admin_menu has in supporting depth=infinite. Sounds like you're saying that it doesn't make sense, and I'm willing to defer to your expertise on that, though I don't understanding the reasoning you gave. If any further discussion on that is needed (and maybe it's not), let's do it in #1812016: Does usability testing show any value of going more than 2 deep?.

effulgentsia’s picture

Issue summary: View changes

Added the sandbox development repo.

tkoleary’s picture

I want to challenge everyone on this thread to consider that we are not building Drupal navigation for ourselves.

Look at it this way. Every developer in the Drupal is building sites for Drupal users. If we make an extremely conservative assumption that each Drupal developer will build three sites with three authenticated users each (who are not developers), that means that all of us in this discussion, and on d.o in general, represent less than 10% of the total population of users of the toolbar. In fact I would guess that it's probably significantly less than 5%.

I understand that it is tempting to extrapolate from our own experience. I hear it over and over, "when I use the toolbar, I...". But I ask you to please forget that you have ever used a toolbar in Drupal. Why? Because every single one of us has already completely internalized the information architecture of Drupal. Most if not all of us could disable the toolbar and still navigate our sites just by typing urls in the address bar. Because we know the landscape we are completely blind to the extreme pain of beginning and intermediate users for whom the D7 admin is a murky catacombs.

This is absolutely not trivial, and it's not just about improving the mobile experience (though that is equally important) it's about fixing the desktop experience. Anyone who thinks that the current navigation of Drupal in D7 is not badly broken has never watched a user new user flail in a usability test.

We owe it to this silent majority of users to erase our own day-to-day experience, look at the tests, and design like every user has never seen this before.

catch’s picture

Title: Redesign toolbar from the ground up so it works on mobile/tablets as well as desktop » Toolbar completely broken for small screen sizes
Category: feature » bug

I have no idea why this is filed as a feature request by the way.

effulgentsia’s picture

Since it looks like tkoleary and Bojhan agree about wanting Toolbar navigation to unlimited depth without intermediary page loads, we need to tackle the performance issue. I don't think #1805054: Cache localized, access filtered, URL resolved, and rendered menu trees is sufficient, so I opened #1814932: Caching strategy for D8 toolbar, which I think is sufficient without #1805054: Cache localized, access filtered, URL resolved, and rendered menu trees.

David_Rothstein’s picture

Since it looks like tkoleary and Bojhan agree about wanting Toolbar navigation to unlimited depth without intermediary page loads, we need to tackle the performance issue.

What's missing from this issue so far is any discussion of why that would be expected to improve Drupal's user experience.

I think it's a complicated question, but I believe that what we know from usability studies is that for new users:

  • Drupal's information architecture and terminology are the biggest obstacle in navigating around the administrative areas of the site.
  • Drupal 7 is actually a lot better for this than Drupal 6 was, but it's still a serious issue.

Given that, I can't really make the connection as to why exposing more of the information architecture and terminology on fewer page loads would be expected to improve the user experience.

I think it's hard to predict exactly what the effect would be, but anecdotally, given how much we've seen people bounce around menu items when they're confused, exposing more menu items (for them to more easily bounce around) seems like it could be a recipe for more confusion.

Furthermore, the limited usability testing that has been done on Admin Menu (during the Google UX Study in February 2012) tentatively backs this up. According to the study findings:

"It is easy for users to get lost and confused with the daunting amount of options in admin menu."

The findings then link to two video clips (Clip 1 and Clip 2) which illustrate the problem.

While Admin Menu isn't quite the same thing as the toolbar prototype proposed here, the essential aspect (exposing the whole menu tree at once) is similar, and suggests that we should be very cautious about the effect this will have on new Drupal users.

The usability testing that was done on the toolbar prototype for this issue, meanwhile (at http://groups.drupal.org/node/260203), is different because it was specifically testing "intermediate Drupal users" only, which is a different group of people with different needs.

Bojhan’s picture

@David_Rothstein You are right, I am not actively advocating for unlimited depth. However I am advocating that if we do have depth, that its not half-way there - because that leads to a even more confusing situation. I don't know what the argumentation is for tackling the confusion around the mass of options (keep in mind that we never actually iterated on admin_menu with this issue, so its hard to determine whether its truely fundamental or part of certain design decisions). Contray to what @effulgentsia is driving towards it is my understanding the Spark team is atm working on a horizontal no-depth bar like the toolbar for desktop.

tkoleary’s picture

@Bojhan Actually that's not the case. We are working on a 9 level deep horizontal option as a northstar design. We have also deignsed a one level deep responsive horizontal version that matches the styling of the vertical menu as a minimally viable version for immediate implementation. I will post both of those designs later today in an invision prototype.

tkoleary’s picture

Here is the latest design prototype (again invision, there's no code under this just images) http://invis.io/MW7OS23K

Some things to keep in mind when viewing this:

  • The only children that are built out are content and structure
  • The prototype is for testing the interaction pattern, so the menu items don't represent the actual information architecture of Drupal
  • There is no hover state in invision (because it's an image map). Assume that all the text links will underline on hover and load the link on click
  • Also assume that when this happens the menu will persist with whatever children the user has expanded still expanded regardless of whether they belong to the active trail.
  • There is a difference between the width of the vertical menu here (190px) and in the prototype at http://toolbar.qemistry.us/ (270px). I did not have time to expand the width in this design but it will be expanded to 250px. At that width child items at even the ninth level will still have plenty of space as long as they have fewer than 30chars., after that they will hide with elipsis.

The data from testing and community feedback that we worked into this is:

  • People would like a horizontal version for desktop (click the icon at the bottom of the vertical menu). The horizontal version uses the same styling and affordances but changes the orientation so that the user has a unified navigation experience in each orientation.
  • The affordance for expanding the children was not strong enough to be discoverable as separate from the text link. The introduction of color makes the down arrow much stronger than the text link making it likely to be the first item the user clicks. This then provides and instant learning experience for it's function. The collapse (up arrow) affordance is less prominent so that the user can more easily distinguish it from other parents that have children.
  • The affordance for expanding the children was mistaken for a hover affordance for fly-outs. Changing from a right/down to a down/up toggle makes it clearer to the user that this expands items below.

Still to do

  • The affordance for changing the orientation of the menu (at the bottom in vertical and all the way to the right in horizontal) needs to be more discoverable.
  • Width of the vertical menu to 240px
  • Lisa Rex came up with the fabulous idea of a "where am I" link somewhere in the toolbar that instantly opens all relevant children to reveal the active trail and displays a pop-up pointing at the last item saying "You are here!"
  • Implement these changes in the live prototype so we can see how it works with the actual IA.
  • Have Dharmesh run a second test
tkoleary’s picture

@David Rothstien I talk about this in great detail in my blog post here: http://typographia.drupalgardens.com/content/responsive-toolbar-drupal-8# (please forgive ugly styling that came into gardens from Google docs)

Again the Google study issues IMHO are primarily a result of the IA, which is the next thing we need to tackle.

Bojhan’s picture

FileSize
84.02 KB

A picture of the horizontal UI as proposed by tkoleary.

horizontal-toolbar-d8ux.png

Is this the north-star or the MVP? You mentioned the "one level deep responsive horizontal version" in your previous comment, is that still coming or should we imagine this design minus the > dropdown icons?

dcmistry’s picture

In the last study, we also found that the shortcuts were not discoverable and needed emphasis. In this prototype, we can see the shortcuts only when the menu is collapsed. I am not convinced yet, is it a good thing or bad but certainly something needs testing.

@David_Rothstein: The goal of the previous toolbar study (Oct 2012) was to focus on the interaction and not the IA, which I 100% agree needs major help (especially for new users)

catch’s picture

Just to come back on this:

I understand that it is tempting to extrapolate from our own experience. I hear it over and over, "when I use the toolbar, I...". But I ask you to please forget that you have ever used a toolbar in Drupal. Why? Because every single one of us has already completely internalized the information architecture of Drupal. Most if not all of us could disable the toolbar and still navigate our sites just by typing urls in the address bar. Because we know the landscape we are completely blind to the extreme pain of beginning and intermediate users for whom the D7 admin is a murky catacombs.

Well there's two parts to this

1. Yes, we should rely on user testing rather than personal opinion when evaluating new experiences. When I wrote #73 that hadn't been done, so there was only opinion vs. opinion. David's post in #134 nicely sets out some of the considerations from previous usability testing.

2. Anecdotal experience isn't completely useless. I use the toolbar module in Drupal 7 because it's actually useful to me despite being a 'power user' or whatever. I have to switch between Drupal 6 and 7 sites quite often, and remembering whether it's admin/build/modules or admin/modules (or admin/structure/modules on an off-day) often goes wrong, clicking one link is faster than typing the wrong URL then typing the right one.

The fact that core developers actually use core modules tends to mean those modules get maintained a bit better. If there's a performance regression in the toolbar I'll likely notice it because I have to profile Drupal 7 sites fairly often, I'll never notice a performance regression in overlay module (unless specifically looking for it) because I immediately disable it and have zero motivation to fix one if there was.

That doesn't mean that user interfaces need to be built for 'us', but it definitely doesn't do any harm if they're unobtrusive to 'power users' or remain useful as people get more experienced - because those will be the people maintaining them for the next 5-6 years.

tkoleary’s picture

@dcmistry Yeah. The shortcuts are hidden when the menu is exposed by design. However this is I think the optimal situation because

  • Shortcuts are by definition something you want to access quickly so they should be exposed even when the menu is hidden
  • When the user clicks on the menu icon they are implicitly stating by their action that the thing they want is not available in the shortcuts

That's my assumption. I'm all for adding a shortcut-specific task to the next test, though to validate that hypothesis since we have never hidden the shortcuts like this before.

tkoleary’s picture

@catch Sure, that's absolutely true. We don't want to get in the way of the power user or "dumb it down", and core devs eating the dogfood will help improve the product for everyone.

It's pretty universally understood that he balance between the power user and the new user requires progressive disclosure. Exposing the depth of the menu structure will actually make it easier for us to re-structure the IA to be more progressive. The flat menu structure of 7 has led to a flat IA with a large amount of top level and second level items. The new user must now internalize manu categories and what they contain in order to accomplish any task. The Google study clearly shows this. With a deep menu structure and a deep IA a few things can happen:

  • The number of top level items (and items at any level) can be smaller because exposing the children does not require a page load. This is important because in categorization the amount of cognitive processing power increases exponentially for each item added to a category. Three to five is optimal.
  • The IA can expose the most frequent tasks high in the tree and less frequent tasks further down. This should not be difficult because there are far fewer fequently performed tasks.
  • For the power user who knows the page they want the "jump box" circumvents the time spent digging fot the less frequent task.
corbacho’s picture

I like a lot the new demo Kevin (Mostly the vertical menu). I recommend to see his walk-through http://youtu.be/bVa5TqmnktI

Specially will be great if the menu remembers & highlights automatically where you are, that's a huge usability improvement, isn't it?

From performance point of view I would like to suggest couple of tricks to handling better the menu sliding. And not changing the body size (performance penalty with unnecessary re-flows)
But where is the code?. Or is it still a internal prototype of Acquia ?

Then, the horizontal bar looks promising at first, but has some flaws that can be annoying after some use:
* Long mouse-travelling distances. Click in the "Menu" icon (in the left-corner), then click "Configuration" in the right extreme of the screen, opens you a sub-menu again in the opposite side of the screen. (This zig-zag behavior is really annoying in desktop computer with a wide-screen. Not so much with touch-devices)
* The demo is shown with submenus with 5-6 items.. but what happens when there are 20 items ? The top bar height is going to be bouncing up & down everytime you click a menu or expands a new level?

jessebeach’s picture

@corbacho, I'm working a couple days behind tkoleary with implementation. He moves much faster than me :) I'm pushing to have an updated patch by the end of this week with the horizontal toolbar framed out so folks can interact with code. I'll also get a demo site up and running.

The latest "stable" patch is from #70.

You can follow along with the bleeding-edge code in the sandbox in the node/1137920-responsive-toolbar branch.

corbacho’s picture

Thanks Jesse.. I will wait probably to the weekend

tkoleary’s picture

@corbacho thanks for the input. Your points about the zig-zag behavior and deep menus are good ones. It's tough to make judgements on this till we have it in fully interactive prototype that pulls in the actual admin menu but I'll keep both of those things in mind.

tkoleary’s picture

Issue summary: View changes

Fix url to altnav.d8mux.org

jessebeach’s picture

Issue summary: View changes

added #1815602

Bojhan’s picture

FileSize
35.75 KB

I have spend some time, letting this sink in and reading through Kevin's blog post, video, his responses and the issues in the Spark queue around this.

If I understand this correctly, on the desktop you can now switch between horizontal and vertical alignment (vertical being the default, or at least the default in the prototype). And in the horizontal alignment, you dropdown into a horizontal tree menu.

*pogo-stick = Requiring the user to go down a level or two, to see if the action they desire to do is there and then go back up.

Navigation through depth

  • You name upon progressive disclosure as the reason for doing depth like this. However the reason we did a flat structure, is to not disclose them all the options right away (and overwhelm them) - instead to disclose only the links absolutely necessary to get to the site-building hubs (structure, config) from where you would then continue. Making especially the content creator hubs (content, people) easier accessible, and allowing for exploding admin pages like admin/config to disclose the information in bits using categories and full links (for when you don't know whats under the category).

    Don't you need to remember in your solution too, where each option is under? You can just pogo-stick faster than with a full page load? For configuration categories, you will do more pogo-sticking as its not on your page in one view. I don't understand that your saying faster pogo-sticking > overwhelming = overwhelming them (mostly beginners) with all the options or half the options (if we stick to using 'management' menu as is) is less cognitive workload than having a quicker way to pogo-stick your way to the right page.

    Your argumentation is to do this for beginners, but we found in D6 -> D7 that the whole idea of exposing them every single link (in management menu, as is) was mostly overwhelming for beginners and that our power users loved it. We in D7 chose essentially to largely reduce the number of options to only the top level hubs, so site-builders knew they had to be either in structure (which is to be kept to <7 so, the cognitive workload isn't too high) or configuration.

    So, I'm a little lost why this is better for beginners other than allowing them to quicker pogo-stick. If that's the primary argumentation, I think that should be fine other than maybe overwhelming them? (which we may be able to solve through interaction?)

Interaction

  • Why would you require the user to click the "Menu" button to show the links you will use 80% of the time. Having a "Menu" button made a lot of sense in the vertical menu option, because its taking a lot of horizontal width it might cause clutter on dense admin pages (e.g. views) - but vertically this isn't really a problem, so there should be no need to click menu.
  • Why is there an +Add on the top bar. Do we really expect people to customize this? We have already seen so many usability problems with adding shortcuts, that we have had to scrap it from our testing plans. And people will want access to the hubs from there, not a second place to add shortcuts.
  • Why are there two search bars? Will you have to remember that the on on your left is for quick jumping, and on your right for searching content? Why don't we just merge them into one.
  • With the current working patch there is little depth (admin/config only showing the categories) I imagine you expect this to go down, till the deepest level. In #1811998: Decide which local tasks to add to the toolbar menu tray — mimick D7 admin_menu? you mention this still needs a system, I'd love to figure out that - because that has a huge impact on how usable all of this is.
  • Let's keep the prototype to the real options, that allows us to better understand the impact - because @corbacho is totally right - how would this work with 20 categories under admin/config. A way to tackle the bouncing, is having this collapse over the overlay instead of bouncing it down?
  • Is it required to put "Shorcuts" in front of shortcuts? We never had to, is it not clear enough to just have the buttons?
  • Finally, if I look at the invision prototype expand 3/4 rows I am visually quite lost. Besides the expected zig-zag pattern, there is just so much going on in that top bar all the menu/home toggles, two search boxes, 8 hubs with icons and dropdowns. But more importantly collapsing deeper to me, is also lost - where flyout/dropdown menu's like admin_menu use both vertical and horizontal spacing to allow for orientation, we are reserved to just horizontal orientation which increases the clutter - some of this might be solved if you style the active trail more explicitly (e.g. adding top/bottom border, bolding, adding color).

Actually, from my talk with webchick in #129 I understood the route was to just align the visual styling because the dropdown creates a overwhelming effect and horizontal flyout menu's are arguably harder to scan. Below is what I imagined would be produced from this discussion, the top menu + shortcut bar basically drop into the Menu button when the screen gets to small.

mock.png

This is not an actual proposal, just shows what I thought the direction was.

I am very disturbed by the fact that there are very few deep design reviews of what is proposed

@tha_sun basically leaves it at, I know how to do the design well but I am not gonna tell you! @webchick would be great to hear your voice on the actual design. @jbeach has been a hero implementing our ever changing designs. I have been outlining problems with the design since #35, #69, #78, #129 and although the horizontal/vertical thing is partly addressed it feels to me like we are skipping over many of the fundamental concerns with the models proposed (infinite depth, horizontal depth interaction, why not admin_menu, local_tasks) focusing mainly on solving a number of detailed issues (even these issues, seem to be getting more and harder to solve).

EDIT: Removed some useless whining about the review process, did another 2-hour talk with angie which should address how to discuss the concerns raised.

webchick’s picture

FileSize
46.36 KB

We went over Bojhan's review in UX meeting today on IRC. Here's some of the excerpt of that, plus some next steps. I'm attempting to summarize over an hour of discussion (+ add in some of my own 2 cents), so hopefully didn't mess it up too badly; feel free to correct me if so.

Bojhan is frustrated because he feels that he's given several detailed reviews and he feels that those reviews have not been acted on/responded to adequately. We are also frustrated, because we feel we have been responding (performing a co-authored usability test, incorporating vertical/horizontal orientation switching, creating a blog post / video to further articulate the thinking behind the design, creating sub-issues to work on performance, etc.), as fast as humanly possible. Hopefully after the discussion today we're all a lot less frustrated going forward. We'll see. ;)

Mainly, Bojhan's feedback boils down to:

Highlighting bottom area of toolbar and asking what shows up here, and how does it work.

Because we are not straight-up copy/pasting the interaction with either the existing Toolbar (which doesn't do depth at all, so as not to overwhelm the user with options) or Admin Menu (which does unlimited depth, but also incorporates things like overview pages and local tasks as a result to help make pogo-sticking faster), there are what Bojhan feels to be some unanswered fundamental questions about this design, namely:

1) What is the justification for deviating from the design used by both Admin Menu and other Desktop applications, where sub-navigation branches out from the parent item, vs. it all being in a single row? The toolbar is using a more "OSX Finder"-like navigation pattern here. Will users understand this?

In other words (or, well, pictures):

Desktop applications, as well as admin menu, traditionally move the sub-navigation out below the parent. Toolbar, as well as OSX Finder, keep a standard height across the sub-nav container below, and you move through it horizontally.

Will users find the horizontal movement between sub-navigation items easier / more intuitive than the admin_menu / desktop application movement? I don't think we'll know this without testing.

I will say, one thing I conceptually like better about Kevin's approach than the Admin Menu approach is there are sites out there that I can't even see the ~S-Z items under Configuration because they scroll completely off the screen, and this is on tiny, tiny fonts that Admin Menu uses (that would be totally un-clickable on a mobile device), and on a desktop with a 21" monitor. In a world where we're trying to make a toolbar that works great on any type of device, including ones with wacky dimensions we haven't even thought of yet, I think Kevin's approach is a nice solution for this because it provides a consistent vertical height, regardless of what level of depth you're at in the tree. I would also argue that a desktop application comparison doesn't really wash for me; desktop applications know in advance exactly what their IA looks like, because they designed it inside/out. Conversely, a Drupal site's IA is completely at the mercy of whatever contributed modules are installed and what sort of bastardization they do to the sensible default IA that core attempted to lay out for it. An all-horizontal/vertical design like Kevin has laid out here seems like it will scale a lot better to me than a horizontal / vertical mix.

Bojhan's lingering concern though is "how deep is deep?" For example, does it include local tasks + action items (e.g. "Add / View / Edit")? If not, why not? We haven't discussed that at great length, but we have an issue to do so at #1811998: Decide which local tasks to add to the toolbar menu tray — mimick D7 admin_menu?.

2) In D7 we made a deliberate decision to not expose more than the top-level IA in the toolbar, so as not to overwhelm users. This decision came from observing their behaviour on the D6 /admin page and being completely paralyzed by the number of options. Kevin's design puts the full depth of the menu tree in users' faces. Is this really a good idea?

I believe the reason this was done (Kevin can confirm), is because we feel that allowing for faster "pogo-sticking," and improving the learnability/user orientation around Drupal's IA, is a reasonable trade-off for overwhelming people initially. (Conveniently, it's also what power users prefer.) The basic use case for this, as I laid out in #52, is say you are on the Modules page, and you click the "Configure" link next to Filter module. This will plonk you down into admin/config/content/formats. You click into one of those (admin/config/content/formats/filtered_html) and twiddle some settings and save the form.

Now you want to add a new one.

With the existing D8 Toolbar, this involves:

1. Configuration. (click, wait for page to refresh)
2. *Scan completely overwhelming list of ALL THE THINGS*
3 - N? *Hope that you somehow magically find "Text Formats" in that list, even though you probably have to try other 6-8 options first, each of which involves click, wait for page to refresh.*
4. Text formats! (click, wait for page to refresh)
5. "Add text format" (click, wait for page to refresh)

With the design as outlined, this would involve:

0. (optional) Expand the Menu, if it wasn't already. (click + instant feedback)
1. Click "Text formats", which is already open as the parent of the item you're on now. (click, wait for page to refresh)
2. "Add text format" (click, wait for page to refresh)

And, if we decided to move local tasks and action items into the toolbar's sub-menus like Admin Menu does, that's potentially just one "click, wait for page to refresh", or one click altogether if the toolbar's already open.

That "click, wait for page to refresh" is slow. Slow + mobile == frustration. We should aim to eliminate frustration, given we want Drupal to be a "mobile-first" CMS. The toolbar currently is nothing but "click, wait for page to refresh," by design. This is what exposing the depth is attempting to eliminate, although it admittedly comes with some additional mental overhead for new users.

Bojhan asked why breadcrumbs are not sufficient for this, and I think it was because of lack of horizontal space on mobile devices, but I can't recall. Kevin?

Responding to a few specific points:

If I understand this correctly, on the desktop you can now switch between horizontal and vertical alignment (vertical being the default, or at least the default in the prototype). And in the horizontal alignment, you dropdown into a horizontal tree menu.

In the current prototype, the horizontal/vertical orientation swap happens automagically based on a configurable breakpoint from the Breakpoint module. It's also intended that the user can override this behaviour if she for example wants vertical nav on all the time. (Murdocke made the suggestion to move this to the user settings page as a "set it once and forget it" kinda thing, rather than have it in-place configurable, which seems sane to me.)

Why would you require the user to click the "Menu" button to show the links you will use 80% of the time. Having a "Menu" button made a lot of sense in the vertical menu option, because its taking a lot of horizontal width it might cause clutter on dense admin pages (e.g. views) - but vertically this isn't really a problem, so there should be no need to click menu.

I also asked about this. The idea is that that Menu toggle is "sticky" like the decision to show shortcuts or not. So you can get it out of your face when you are just browsing the site, and then keep it in your face when you are in an admin context. Not sure if this will be part of the initial issue or not, since there are a few ways technically to implement it that could use some discussion.

Why is there an +Add on the top bar. Do we really expect people to customize this? We have already seen so many usability problems with adding shortcuts, that we have had to scrap it from our testing plans. And people will want access to the hubs from there, not a second place to add shortcuts.

I believe that's shortcuts for "Add FOO content". Unless Kevin violently disagrees, I don't think this is part of the MVP, nor part of this issue. We can discuss adding it in another issue, as a post-feature freeze enhancement.

Why are there two search bars? Will you have to remember that the on on your left is for quick jumping, and on your right for searching content? Why don't we just merge them into one.

Yeah, that's confusing, I agree. Once again, unless Kevin violently disagrees, I don't believe the search bar in the toolbar is part of the MVP (nor is the one on the toolbar itself, although there is some working code in #1781422: Add search/jump/command functionality to toolbar we hope to incorporate once this patch is committed), I think it's intended to show the kinds of things that would go in the "Action Zone" that Jesse laid out in #70, since you asked about it. In any case, separate issue to discuss if we want that.

Is it required to put "Shorcuts" in front of shortcuts? We never had to, is it not clear enough to just have the buttons?

I assume this came from user testing. Dharmesh/Kevin, can you confirm? But in any case, I don't think we need to tackle it in this issue, can be discussed separately.

Finally, if I look at the invision prototype expand 3/4 rows I am visually quite lost. Besides the expected zig-zag pattern, there is just so much going on in that top bar all the menu/home toggles, two search boxes, 8 hubs with icons and dropdowns. But more importantly collapsing deeper to me, is also lost - where flyout/dropdown menu's like admin_menu use both vertical and horizontal spacing to allow for orientation, we are reserved to just horizontal orientation which increases the clutter - some of this might be solved if you style the active trail more explicitly (e.g. adding top/bottom border, bolding, adding color).

I think this is good feedback, and warrants a bit of design tweaking, esp. with the "Where am I and how did I get here?" question. I noticed that in OSX it handles this with background colour highlighting.

Actually, from my talk with webchick in #129 I understood the route was to just align the visual styling because the dropdown creates a overwhelming effect and horizontal flyout menu's are arguably harder to scan. Below is what I imagined would be produced from this discussion, the top menu + shortcut bar basically drop into the Menu button when the screen gets to small.

That was also what I had pictured, but seeing it in action I understand why it needs to be done the way it's done now. For performance reasons, we need to serve the mobile version of the design first/by default. And it's a bad idea to do complex DOM manipulation which is CPU/memory intensive,  and slow, on every single page load for > X px screen width (which IMO will still be the majority of them for a good while, even with the explosion of growth around mobile). So for every way in which the desktop and mobile version look radically different from one another, that's more computations and rejiggering that slows down the desktop experience.

I am very disturbed by the fact that there are very few deep design reviews of what is proposed

Me too. I've tried all the tricks I can think of—blog posts, videos, tweets, Spark releases, interim patches, etc.—to attract attention here. There are 69 people subscribed to this issue. I don't know why more aren't providing feedback, and wish that they would.

However, this is a critical bug and we can't hold it up forever, hoping that people will someday chime in with their 2 cents. We have 40 days left before feature freeze. So I think a better approach is to come to agreement on the fundamentals and get something in sooner than later, accepting the fact that we will need to further iterate on it after feature freeze to get it to something we're really happy about shipping with.

@tha_sun basically leaves it at, I know how to do the design well but I am not gonna tell you!

This has been my read of his comments too, and it's been extremely frustrating.

In case it's not clear, we are not married to any of this code. We're more than happy to pull in stuff from admin menu and would love to collaborate with sun or any other maintainers of other navigation modules in contrib. But belittling, snide remarks about how you know better than us really aren't helping push this forward, and are just demoralizing us.

Action items

Here are the action items we came up with coming out of this meeting.

We need to decide on two fundamental parts from a UX perspective:

1) Depth, what are the pro's and con's from a UX perspective to include all the levels. Additionally, what goes into the menu, is it just top-level links, sub-links, local tasks - more?

#1811998: Decide which local tasks to add to the toolbar menu tray — mimick D7 admin_menu?

2) If we choose full depth, what interaction model makes most sense - horizontal interaction, or admin_menu like interaction?

Additionally:

3) We should clarify what is part of MVP and what is not, design-wise.

Technically, we need:

4) An updated patch that reflects the current state of the toolbar code in terms of the updated designs, and some additional publicity (twitter, blog, etc) to get more reviewers.

Jesse Beach is actively working on this right now. Later this week or next, I'll roll a new release of Spark with this, plus Aloha/inline editing stuff so people can try it all together without futzing with patches, which should hopefully help broaden the base of testers.

5) Clear picture on the performance impact of going full depth, and how to solve that?

Alex is tackling this in #1814932: Caching strategy for D8 toolbar. Needs reviews.

jessebeach’s picture

This is a status update patch. It is not, repeat not to be considered a candidate for core at this stage. I don't want development on this issue to go dark for too long, though. If you'd like to keep up with the most current commits rather than waiting for patches, you can see them in this sandbox repository viewer.

The big changes since #70 in this patch focus on implementing changes to the desktop toolbar UX. The switch between the mobile and desktop UX is achieved with a combination of CSS media queries and JavaScript event handlers triggered on window.matchMedia (polyfill patch: #1815602: Introduce a polyfill for matchMedia). The polyfill is included in this patch, but won't be included in the core proposal patch. The breakpoint between the mobile and desktop UX is configured with the breakpoint module #1734642: Move breakpoint module into core.

On a wide screen, with the menu closed, the toolbar looks like this:

toolbar-horizontal-closde.png

When the site navigation menu is open, it replaces the shortcuts.

toolbar-horizontal-open.png

Opening subnav items shows them in a mac-style finder view.

toolbar-horizontal-subnav-open.png

When the screen width is narrowed, the menu retains the disclosure of subitems.

toolbar-narrow-open-subnav-open.png

With submenu items closed up.

toolbar-open-narrow.png

Closing the menu reveals the shortcuts again.

toolbar-closed-narrow.png

Known and open issues

  • In the horizontal orientation, the tray for second level items is needlessly wide and contains a lot of dead space.
  • Shortcuts down scale down well with the current styling.
  • "Edit shortcuts" is redundant.
  • The sub nav items in the horizontal orientation leave a lot dead space with shallow menus. tkoleary is considering alternatives to this design at the moment.
  • The "active path" isn't marked up and styled.
  • The open state of the menu isn't preserved across page loads.
  • The button to switch between the vertical and horizontal orientations isn't implemented yet.
  • The user actions aren't presented in a dropbdown yet.

tkoleary is still processing the critiques offered by Bojhan in #139 and corbacho in #144 among other comments posted in this thread.

sun’s picture

  1. The Mac-style/Finder pattern is not valid to apply to the desktop appearance, since an essential part of the pattern is that i) it is designed for trees of unlimited depth, ii) it is designed for tree levels containing an unlimited amount of items, and iii) to make i) possible it intentionally shifts off higher levels of the tree out of the visible viewport; you only see 2-4 tree levels at one time, depending on your screen/viewport size. This makes the pattern inherently suitable for mobile/small screen devices, but not for desktop.

  2. I will say, one thing I conceptually like better about Kevin's approach than the Admin Menu approach is there are sites out there that I can't even see the ~S-Z items under Configuration because they scroll completely off the screen, and this is on tiny, tiny fonts that Admin Menu uses (that would be totally un-clickable on a mobile device), and on a desktop with a 21" monitor.

    Please stop spreading FUD, you're talking about D6, and the problem was caused by the IA of Drupal core itself (particularly, top-level "Settings" containing a massive amount of child links for each and every module that is installed). The rest about font sizes is factually irrelevant.

  3. There is an extremely trivial reason for why the dropdown menu pattern dominates the desktop world, and it becomes more than obvious when simply trying to use what you're suggesting:

    toolbar-horizontal-design-flaw.png

  4. We can remove the icons from the screenshots and this implementation. If icons could be achieved in any simple/sane way, you can bet that admin_menu would have introduced them already. admin_menu's #443300: Icons feature request dates back to 2009. There's no other issue for core than #42493: Enable custom bullets/icons for specific menu items (2005), but that one focuses on icons for custom menu links, not icons for built-in menu links.

    The fundamental problem space is that Drupal is modular, and so the administrative menu link tree is modular, too. Contributed modules typically add further top-level links to the toolbar; e.g., Commerce adds an entire new "Store" administration section. Icons, however, need to speak a common/unique visual language in order to work for users. They need to be available and work in different sizes. They have to be carefully and cautiously designed to achieve their goal.

    We once had #606490: Drupal GPL icons - a softfacade initiative and #218674: Update watchdog-*.png status icons to work on that topic, but all of those issues got stuck on the problem space that there is an infinite amount of possible use-cases to cater for. And if that wasn't enough already, the labels of the infinite possible items are so extremely generic and abstract that there is no universally understood icon that could be applied.

    You definitely do not want to run into this can of worms here.

  5. @Bojhan is completely right in that the "Menu" drawer/toggle does not make sense for the desktop appearance. Users that have access to the toolbar do need it. There's no point in hiding the menu. The only reason for why the drawer is also suggested for desktop here is that the new proposed design is twice as large as the former/current in terms of height. That's a bug introduced by the design itself.

    Maintaining and ensuring that screen-estate can be fully leveraged by the actual page content while the toolbar is inactive/unfocused is the primary challenge of designing a toolbar that works and is usable. This challenge is common for all toolbars of all kinds; you can also witness it in client-side content editor library toolbars that are usually packed with command buttons (and thus we're facing a very similar situation in #1809702: WYSIWYG: Add Aloha Editor to core).

    However, screen-estate is only one of the two edges on the spectrum. The other end is immediate access. Finding the right balance between screen-estate and immediate access ultimately is the top priority and biggest challenge of any toolbar.

    For the very same reasons, I couldn't have disagreed more with the previously proposed designs in #48 that used a vertical dropdown with horizontal fly-out sub-items — that design solely focused on the toolbar, removing tons of critically important horizontal screen-estate from the viewport and inherently from the width available for the actual page content. Plenty of screenshots showed that text contents in tables wraps way too early, and if we had an incredible breakpoint implementation, then there'd even be a chance for total page layout changes solely caused by opening the toolbar.

    I do not understand why we're trying to be smarter than every other desktop application that is using dropdown menus out there. (And even Apple/Mac agrees, you merely looked at the wrong part of the user interface. By any chance, did you see the actual toolbar of Finder at the top of your screen?)

    An essential part of usability design is to apply patterns that users are used to. There's not remotely a sign that the dropdown menu pattern is going to change for desktop applications anytime soon in the foreseeable future. So why do we try to re-invent the wheel even though we know that will result in an unexpected and ugly UX?

    Anyway — if at all, feature requests of users asked for completely hiding the toolbar in order to re-establish the full screen-estate for the page content while not using the toolbar. See http://drupal.org/project/admin_menu_dropdown for an actual implementation; I'm not able to count the amount of feature requests for admin_menu along those lines that have been won't fixed over the past years.

  6. Facebook was mentioned, referenced, and shotted a dozen of times in this issue. Facebook doesn't really get it right in terms of responsiveness on desktop, but at the very least, they take the right and appropriate actions for facebook.com (desktop: dropdown menus) and fb.com (mobile: menu drawer + vertically grouped links).

    FWIW, @fubhy and me discussed mobile/responsive support for admin_menu in Barcelona already, and the goal was and still is to implement the Finder-alike one-tree-level-at-a-time fly-out pattern combined with a menu drawer for the mobile experience, while retaining the full current dropdown menu experience for desktop.

tkoleary’s picture

@sun Dries, Angie, Alex Jesse and I had a meeting to discuss this at the end of the day today. Jesse and I had already looked at the issue you bring up around the disconnect between the first and second level items in the horizontal menu. We saw that this had problems as did the issue of the depth of the drawer adapting to the number of child items, which Jesse saw as a big implementation problem. This, combined with your concerns led us to rethink our approach to the horizontal toolbar which I have since re-worked.

Before I go into the discussion we had on how to go forward on this I want to talk to some of your comments on Angie's action items.

On #1 and #2 I think your points here are all valid and underscore the fact that there are enough reasons for stepping away from that approach, which is what we are doing

On #4 While I appreciate the difficulties here I still think this is a can of worms worth opening. Icons have tremendous way-finding value for users which is why they are so ubiquitous. But let me address your points one by one (paraphrasing):

  • "Drupal is modular and modules need to be able to add top level icons." Absolutely. This is, in fact, one of the reasons that the icons in our implementation are single color and solid shapes. If you look at contemporary open-source icon libraries like http://thenounproject.com/ you can see that when icons are solid shapes in a single color it's actually not difficult to maintain a "common/unique visual language"
  • "They need to be available and work in different sizes" If we are talking about scalability/legibility at small sizes then this is a design issue, not an implementation issue. My answer to that is that module devs need to work with a good designer. If, on the other hand, we are talking about file types and sizes then there are two implementations that address that, svg and iconfonts. Both address scalability, zooming and high resolution displays because they are vector based. Iconfonts have the added benefit of accessibility. We have used both in spark, in this implementation jesse has used base64 encoded svg files, coded right into the CSS file so AFAIK there's also a performance benefit. Documenting this and providing an "icon kit" for module devs will also help remove this as a blocker.
  • "labels of the infinite possible items" The design does not call for infinite possible items, only top level items, which even given a very large number of modules that want to add top level items, is still finite, and IMHO actually very small.
  • " items are so extremely generic and abstract that there is no universally understood icon that could be applied." This is a design and information architecture problem. If a top level category cannot be abstracted into an icon because it's contents are too disparate then an error has been made in categorization. I think that most implementations of top level icons will be quite straightforward. The commerce example for instance would be quite simple.

On # 5 which I read as the "immediacy" of the menu I agree that it should be immediately accessible and I think the revised design and implementation will address that. The persistence of the horizontal (and vertical) menu through a pageload, and the fact that both will push, not overlay the page will mean that, in any given session the user will have to click open the menu exactly once.

On #6, others may have referenced Facebook but that was not a touchpoint for me as I did this design, two big touchpoints were Wordpress and Squarespace 6, two incredibly effective examples of usability in our exact space.

Regarding the discussion, we took a step back from the problem and looked at refactoring all of the moving parts based on everything we know and I think we have arrived at kind of a breakthrough. The elements are:

  • The home link
  • The menu link
  • The menu
  • The shortcuts
  • The "add" dropdown
  • The "user" dropdown
  • The "find content" field
  • The menu orientation toggle

The Home link

Dries felt strongly that the home link should go back to where it was anchoring the top left. After exploring other arrangements of the tabs we concluded that this could work with the current design.

The menu link

After moving the home link to the left it became clear that the white tab no longer worked with the vertical menu so I changed the styling to separate the two.

The menu

The vertical menu has not changed but we decided to remove the deeper items from the horizontal version for the reasons stated above. The "has children" affordance and the Tab borders could then be removed allowing for a simpler look. This allows for contrib to provide drop-down or fly out menu modules to extend the horizontal menu for desktop devices with hover.

The shortcuts

Dries suggested the idea of integrating shortcuts in the top bar which really kicked off the whole idea of typing all of these top level items together in a more unified presentation, which led to applying the similar treatment to "add" and "user" which I had formerly treated with a more generic dropdown style.

The "add" dropdown

This the "add" dropdown and the find content field were created to pave the cowpaths of the "add content" "find content" shortcuts and actually extend and improve their functionality.

The "find content" field

Where the "find content" shortcut requires a pageload followed by a list with sort and filter but still no search! Here the user can actually search content immediately. The pattern is ubiquitous. As far as the conflict with the "Jump to" field they are two different things. Jump to is an autocomplete field for power users to dive quickly to an admin page they already know the name of, find content is a search box that loads a results page of content that contains the search term.

The "user" dropdown

Dispensing with the generic dropdown and integrating "add" and "shortcuts" into the tab pattern led me to move this to the same location for simplicity and unity. One caveat here is that if other tabs are added, user should still always be the last child.

The toolbar orientation toggle

Added a label and both states to make the affordance clearer and aligned right to separate it from the left icons above in the vertical menu.

We are certainly not yet all the way to the solution but as I sad before I think that this design comes the closest yet to providing a unified, scalable approach that provides a substantial leap forward from where we are in D7.

The invision prototype is here: http://invis.io/MW7OS23K

sun’s picture

FileSize
255.28 KB

toolbar-vertical-flaw.png

tkoleary’s picture

@sun Yes, my design is lagging, this has already been addressed in the implementation where we increased the tray width from 190px to 250px (approx, jesse is actually using REMs). The table issue is covered by responsive tables http://drupal.org/node/1796230 committed September 27.

sun’s picture

The table issue is covered by responsive tables

None of the table contents would wrap without the vertical toolbar menu. That results in a poor experience and is exactly what I meant with balancing screen-estate vs. immediate access. The suggested design completely ignores the screen-estate.

On a visualized spectrum, it would be located here:

screen-estate  <======================================|=>  immediate access
                                                      |    (toolbar dominance)
                                                      X

The question of why we're even attempting to invent a custom toolbar pattern for desktop instead of going with the common toolbar pattern wasn't answered.

Wordpress and Squarespace were mentioned as examples. These apps have a completely different IA and interface.

benjifisher’s picture

@webchick wrote,

I don't know why more aren't providing feedback, and wish that they would.

Do you mean, other than the fear of jumping in to a long discussion and saying something silly or repeating what has already been said? Well, I am new to this issue, but here are my first impressions:

  1. The current implementation (see #145) does not work well with the Overlay module. From the home page, I opened the menu and clicked "Extend" and nothing happened. I disabled Overlay and it worked fine.
  2. In a menu item like Configuration (icon), all the white space is part of the same link as "Configuration", making it hard to click on the icon. I think we should err on the side of the link that does not involve a page load.
  3. It seems inconsistent to me that clicking on "Menu" just expands the menu (no page load) but on every sub-item, clicking the word takes me to a new page. It would help a little if the styling were different (no underline when hovering on "Menu," for example. A more drastic change (consistent with my previous remark) would be to swap the two actions: click on "(icon)Content >" to expand the menu, click on a right-justified icon to go to the page.
  4. @webchick described a use case where the menu state persists between page loads. Is this the same as the known, open issue The "active path" isn't marked up and styled. from the end of #150?
  5. @Bojhan asked,
    Is it required to put "Shorcuts" in front of shortcuts? We never had to, is it not clear enough to just have the buttons?

    and @webchick replied,

    I assume this came from user testing. Dharmesh/Kevin, can you confirm? But in any case, I don't think we need to tackle it in this issue, can be discussed separately.

    My opinion, as someone who has not seen previous incarnations of this, is that the "Shorcuts" label makes it much clearer what "Edit shortcuts" does.

  6. Another inconsistency, probably out of the scope of this issue, is that the "Find content" button (or Menu > Content) goes to admin/content, where there is a link "+ Add content" at the top of the page; but the "Add content" button goes to node/add, with no direct navigation to the "Find content" page. Maybe add admin/content/add as an alias of node/add. Then "Find content" and "Add content" would both go to tabs on the "same page."
  7. How does all this work with themes? I use the Admin menu on all my sites, and despite several options for how it interacts with content, there are some themes where it interferes with absolutely positioned elements. Would it make sense to make the toolbar a block that can be positioned in a region, so that theme designers know they have to deal with it (and have the tools to do so)?

Regarding the last few comments (#153 to #155):
I agree with @sun's comment in #151 that, without a touch screen, it is painful to click in the top navigation row and have stuff open up in the left column. But IIUC this will, by default, only happen on narrow screens. Some of the line-breaking issues can be improved by choosing breakpoints properly, so that the menu overlays or "pushes" the content differently. It should also be possible to craft CSS rules that repond to whether the menu is open as well as how wide the screen is.

benjifisher’s picture

Issue summary: View changes

Added a dependencies section

effulgentsia’s picture

None of the table contents would wrap without the vertical toolbar menu. That results in a poor experience and is exactly what I meant with balancing screen-estate vs. immediate access. The suggested design completely ignores the screen-estate.

There is a very small range of screen sizes for which this is true. If we assume that Drupal admin tables are designed to look good on a 1024px viewport (landscape iPad), and if the vertical toolbar takes up less than 256px of width, then everyone on 1280px or wider viewports (pretty much every modern laptop screen and desktop monitor) would be fine with a vertical toolbar.

For people who do not want the vertical toobar (small viewport, large font sizes, personal desire to not lose 250px of horizontal screen estate regardless of viewport size), in #152's invision prototype, there's a sticky toggle for switching to the horizontal toolbar. In fact, on viewports wide enough to support the horizontal toolbar, that's the default, so someone needs to click the toggle in order to have the vertical toolbar. Why allow this option? For people with plenty wide monitors (like me) who like having a fully expanded toolbar (since in the latest designs, the horizontal one only supports the top-level links, as in HEAD).

The question of why we're even attempting to invent a custom toolbar pattern for desktop instead of going with the common toolbar pattern wasn't answered.

#152's prototype does use the existing HEAD horizontal toolbar with only top-level links for viewports large enough to fit all those links on one row. It makes some changes, like icons (more on that below), larger height (for fat thumbs), and rearranging toolbar+shortcut into a different 2-row arrangement (but I'm guessing that's not the heart of your question). Rather, I think you're asking why provide a vertical toolbar option on viewports large enough to support a horizontal one. And I think the answer is: we need this vertical toolbar for small viewports anyway; once we have it, why not let people on large viewports opt in to it?

Contributed modules typically add further top-level links to the toolbar; e.g., Commerce adds an entire new "Store" administration section. Icons, however, need to speak a common/unique visual language in order to work for users. They need to be available and work in different sizes. They have to be carefully and cautiously designed to achieve their goal.

#152 answered the size and design part of this. As far as modules that add new top-level Management items, how many of those are there? Out of 10,000 or so contrib modules, are there more than 10 that add a top-level Management section? For the very few modules that do, is adding an icon to go along with it such a big deal? As a side note, one thing I like about the icons is that it in principle would allow someone to switch to the horizontal toolbar even on a narrow device (just show the icons, not the words). I brought this up to jessebeach, who didn't like the idea of needing to code that, so if we don't provide that option in core, I might give it a shot in contrib.

Damien Tournoud’s picture

Priority: Critical » Major

From @webchick#67:

Shipping a CMS in 2013 without the ability to edit it on a mobile device without it looking like utter shite would be a death knell for Drupal. Escalating this to a critical feature request.

"Looking like utter shite" doesn't satisfy the community accepted definition of "critical":

Critical bugs either render a system unusable (not being able to create content or upgrade between versions, blocks not displaying, and the like), or expose security vulnerabilities. These bugs are to be fixed immediately.

I justed tested Drupal on iphone and Android, and I can confirm that the system is usable. Demoting to major.

Bojhan’s picture

FileSize
48.06 KB

Reviewing again, I'm happy to see there is finally a fundamental change in the direction of this design. Sad that it took so many reviews, to make it happen.

@DamZ Tresholds-- Following your argumentation usability will never be a critical bug anymore, because we measure things by hard to use - not impossible to use.

The current state:

2nd-review.png

I really liked changes around the home location, menu step, the tab like interaction for exposing links.

Toggle horizontal/vertical

  • Can we move the toggle horizontal/vertical to the user profile? The toggle currently is a cool feature, if you are constantly switching between orientation - but I think its more likely people just choose one and then go with that forever. This will have an impact on discovery, but I am not really that worried about that.
  • Can the default be, horizontal menu. It's clear to me that various people still strongly disagree with the vertical menu, for reasons beyond just the real estate - so if we put it in, at least not make it the default.
  • Choosing a default, means that we can expect more consistency across documentation, books, videos, impact on modules etc.

Two search boxes

Where the "find content" shortcut requires a pageload followed by a list with sort and filter but still no search! Here the user can actually search content immediately. The pattern is ubiquitous. As far as the conflict with the "Jump to" field they are two different things. Jump to is an autocomplete field for power users to dive quickly to an admin page they already know the name of, find content is a search box that loads a results page of content that contains the search term. - Kevin in #152

  • The rationale is not clear to me, search is search. Whether you are searching the content, or just the management tree. You are searching. On your OS, your search box allows you to go to both system configuration and actual files - we can just use a <hr> or category, to show the difference.
  • I can see a lot of practical problems with two search boxes, people will go to the search box intuitively and each time they do so - they have to think, crap which one do I need again.

Bookmarks / Add

  • The rationale as I understand it for the Bookmark vs. Add, is that Kevin wants to have easier access to actions. Having a separate "Add" tab allows us to isolate the actions from your random shortcuts. I'ts not very convincing to me, because the main reason most people use shortcuts(bookmarks) is to add those action links.
  • We might be trying to create a new pattern, for a problem that doesn't exist. Creating separate containers for quick links, most people will do just fine with one container, so far I haven't heard a request for it by any of our users.
  • The flow for actions beyond adding content, is less ideal if you start at the "add" place - a lot of the flow centers around going to the specific menu and adding something, to the term and adding another one, going to the layout and adding a block. You now lose that context step, we can introduce it but keep in mind that each "add" place then needs a good interaction for establishing that interaction - and we don't currently have that in a lot of places
  • If you want quicker access to action links, can't we just choose a few more sane shortcut defaults around actions?

Icons

  • @sun is completely right in stating, this will be troublesome. However it is only on top levels, we can expect that distributions make icons for their top levels. Maybe they will never bother, or make really ugly icons - we don't know. But as far as I am concerned its not really a super big issue, compared to all of the other decisions.
  • As far as I understand are the technical challenges solvable, lets make sure we stretch this visual style to existing icons.

Happy to see more reviews and discussion :) Hope we can get some of this hashed out before BADCamp.

attiks’s picture

Regarding "Can we move the toggle horizontal/vertical to the user profile?" and only speaking for myself: I access the same site using a desktop, laptop, tablet and smart phone, mostly depending on where I am and on the time of the day, so I rather not have it as a user setting ;-)

jessebeach’s picture

Regarding vertical/horizontal orientation. I'd interpreted the designs to indicate that the horizontal orientation is the default. On small screens, the orientation will switch to vertical. That breakpoint will be configurable.

If a user pegs the orientation to vertical for a tray (they will all -- administration menu, shortcuts, user actions -- be peggable, potentially, at least in the code), then the tray will remain vertical across all screen sizes.

I spend yesterday refactoring the patch in #150 to the new designs. That effort is about 40% complete. I hope to have a patch up today or early tomorrow along with a curated list of sub-issues. I'm trying to make this patch the framework for the updated toolbar that we can extend in smaller, targeted issues e.g. the search functionality.

eigentor’s picture

Reading into this issue after long not having done this makes me a bit sad.

The general direction of what I see in http://www.youtube.com/watch?v=bVa5TqmnktI&feature=youtu.be is so much better than anything we have now, I desperately want to see something like this.

What I see being argued about is one or two steps further than that, as the general consensus on that on mobile a vertical order of the menu makes more sense. To get this more consistent on a desktop and expand the same optics horizontally there like seen in http://drupal.org/node/1137920#comment-6645042 makes total sense.

In Core patches that concern code, this Stuff might have been committed and the rest be marked as followup issues. I know that in UX, there is a more holistic approach and you need to get it right the first time.

So how would it be possible to get a basic version that reflects the parts on which there is a general consensus in, and iterate over the other stuff later?
This is a major change of UX and I would never expect to get it right in one fell swoop.
This needs hands-on testing apart from user testing to find out what really makes sense, which you just cannot foresee.

ry5n’s picture

FileSize
8.48 KB

I’ve finally caught up with this issue enough to have some input:

1. I agree with Bojhan that the 'jump field' should be merged with the main search. It should be an autocomplete field with results separated intro groups (menu items probably first, then and content results, etc.)

2. I don't mind the horizontal/vertical toggle on the menu itself, however I find the latest iteration confusing (pictured below). It looks to me like two options, one of which is disabled (but this is the one I need to click to toggle it). I suggest reverting this element to just a single icon with no label. User testing should show if discoverability and the meaning of the icon are problems.
toolbar switcher

3. I have some worries about the drilldown interaction in the vertical menu. Even with the greater width for the menu in the new prototype, the concerns voiced by sun and others still apply to some extent:
- with enough depth, the amount of horizontal space for nth-level items may get too small, due to indenting
- as more items are disclosed, the menu starts to get taller and taller
- with several items and sub-items open, I expect that we’d see “IA Overwhelm” set in very quickly

An idea to solve no. 3 is to drop the tree-style interaction in the sidebar and switch to a left/right sliding interaction model. So it would work almost exactly the way iOS handles digging into options, where you tap an option and the content within the menu slides to the left, replaced from the right with new options. There would be a 'back one level' button at the top of these sub-menus.

The problem with this idea is how to handle items that have their own page, plus children. Right now this is achieved with the item label linking to the top-leve page, and the disclosure icon opening the tree and revealing the children. If we use the iOS pattern, it may go against user expectations to have such a split within each item. The other way this could be handled is to put the link for the top-level page at the top of the next-level menu, meaning that tapping a menu item 'people' would slide the menu left, revealing a sub-menu with e.g. 'people overview', then its children. Visual emphasis and labelling (words like 'overview') could be used to distinguish the top-level item as such.

corbacho’s picture

FileSize
653 KB
1.21 MB
219.19 KB

First
===================
This issue is:
* gigantic, really ... 10 minutes to scroll down here,
* has not good summary at all,
* it has so many acronyms, strange name of patterns and UX vocabulary,
* and "emotional" opinions ...
that:
* People is afraid to jump in and say something stupid.

Second: This is forever.
========================
This process affects every single Drupal developer and user.
Forever (Who else can afford to build *and test* a dynamic toolbar that works in every single device ?. Drupal community has a unique chance to do it)
I agree that once committed, probably it won't be a step back.
The icons being chosen for example. Once they are "in".. they will be probably "forever" or are we going to change the Drupal brand in each Drupal major release?

These final decisions should be much much more democratic.
From what I see and also Bohjan commented: it took more than 1 year to start to agree on some basic prototypes.. and suddenly in 2 months (sept-october), a lot of decisions have been made:
1) A pattern to show the navigation (Sidebar, offcanvas, dropdown?)
2) A collapse/slide/flyout sub-level pattern
2) A desktop navigation pattern
3) A kit of icons
4) a new search functionality
5) how to show the shortcuts

Some of these decisions are not about small-screen devices and I think they should be exposed more. Probably creating sub-issues? Or maybe is bad idea?

And I don't see many users (or comments) supporting all the decisions that have been taken.
Neither I see usability tests. The only one published (#140) for example was making quite clear that users don't discover easily the idea of an arrow at the end of the row means "expanding"

I think even after the redesign (circle around the triangle)... still the issue is that the icon is *at the end* of the row. It should be at the beginning. Not because I say so.. but because it's a universal pattern. Every single menu-tree collapses with a icon ([+] [-] or Mac-triangles) and those are placed at the beginning of the row

Third: No consensus
=====================================
Still I respect Kevin's decisions and I like 70% of the design, really, but as I said, I don't agree with some decisions.
In what I disagree? I think it's futile that I give my opinion, who am I compared to a UX expert?
Even @sun observations are being put down.
And still I'm missing the opinions of many smart Drupalers out there..

Fourth: The Mac bias
=======================================
How many people in this thread owns a Mac ? and carries in the pocket an iPhone?
Do you know that more than 80% of users out there experience Windows interfaces? and if they use their mobile phone to surf the web, most probably is a Nokia or Android-based ?
I think there is a strong Mac bias and that can is good and bad. Good because Mac usually does good UX decisions. Bad because make us think differently than the end-users. We should try to aim for familiar and universal patterns.

Fifth: The solution
===============================
Update I reconsider my position of creating a poll. See #164
We have implemented through this issue almost every single possible navigation pattern possible,
why don't we use it to create a poll and ask to the community?

Then we will stop fighting about "I think A", "I think B".. and it will be much easier to see where is the consensus.

Why don't we spread a poll with graphics and these questions:
* Do you want Icons in top-level menus ?
* Do you want always Horizontal, always Vertical, or automatically adapted by screen size?
* Do you want a separate search for the nav menu ?
* Do you like White or Black background ?
* Do you prefer triangles or +/- icons to expand levels. Do you want them at the beginning or end of the row ?
* Do you prefer (for Mobile) a slide-sidebar, a offcanvas sidebar, a sidebar hidden where the body slides to reveal it ?
* Do you prefer a no-depth menu, a menu-accordion, a menu-tree,
* The submenus should be expanded via indentation, via sliding with "Back" button, via sliding with Breadcrumbs?

(Also at the end of each question, a checkbox: How important would be for you to have an option to change it )

Benefits of a poll
=================================
It's easier to spread through social networks, there is no needed to be a Drupal developer, this is a generic problem in web design. Let's use the Internetz for our benefit
We can ask to spread it to real users, not only developers.
It will be easier to discuss, so people can comment in each step of the poll about "I like (A) because... ", instead of "I like the fly-out sidebar-left menu, when it hides on the sub-menu level 4, but not like in #45, but more offcanvas... "

How to do a poll ?
=====================================
I will help with the material. For example, creating gifs for the options (see attachments)
I've been playing around with the code of toolbar.js enough time to produce .gifs for all the options... it's faster to prototype in Firebug that in Invision =)

I will be in the IRC for some hours, if someone wants to chat about it

* PS. btw, a nice sidebar for me will be a mix of Google sliding-dark bar and something similar to Atrium-like drilldown with breadcrumbs.. but without indentation. yhahan had great ideas 3 years ago already. I wonder what would be his ideas nowadays, specially when there is no anymore IE7 to worry about, and we have CSS3.

webchick’s picture

Definitely agreed on the need for an issue summary. I'll try and write one of those up once Kevin posts the latest design revisions so we can try and shortcut reading some of the 100+ comments here.

However, I think your assertions of "forever" are being very over-stated here. This is just the default toolbar experience that Standard profile provides out of the box in Drupal 8. Alternative toolbar implementations can and will exist in contrib, and various distributions/sites will opt to use those instead, just as they opt to use admin_menu and admin modules today. And I don't see any reason we can't revisit Drupal's default "branding," not only in future versions of Drupal, but even before RC1 of Drupal 8.

I think this has been a key point of tension in this issue, which eigentor captured well in #162. Several of the participants in this issue are advocating for getting this toolbar 100% perfect out of the gate before commit. This has resulted in numerous adjustments to both the design and implementation throughout the course of this issue, which we are hopefully honing down on now, but I agree we are probably around 70%, and not 100% yet.

I'm not a believer at all, however, in "design by democracy," and I think trying to solve this with a poll is actually a really bad idea, and I believe would set an extremely dangerous precedent that would drive away any other designers from working on Drupal core, ever. I am a huge believer though in "design by data." That's why rather than continuing to argue and reach consensus around the design here in this issue in front of ~70 people, what we have been advocating very strongly to get something in sooner than later, then continue to iterate on it, both before and after feature freeze. And rather than opinions of mostly the elite Drupal power users dictating the design direction (cos let's face it, that's what most of our social networks consist of), we can have direct user experience of people using Drupal 8 help dictate the design direction of further revisions.

I'll also say that it's quite frustrating to be feeling like we are getting "blamed" here for doing nothing more than coming in and trying to save this poor issue, which is both absolutely critical for D8, and was also sitting since April 2011 with absolutely no viable patches before our first attempt just after DrupalCon in September 2012. And we're down to 35 days, 7 hours, 27 minutes, and 11 seconds to feature freeze.

So please, please can we stop letting the perfect be the enemy of the good here, resolve the critical blockers design-wise (which as far as I can see from Bojhan and sun's review is not much more than removing the tray and sub-nav on horizontal orientation at this point), so that we can get an actually "needs review" patch posted to this issue that we can then work through performance/JS/CSSetc. issues and get committed, then continue to refine the toolbar from now until release in dedicated sub-issues? Please? :\

corbacho’s picture

I talked with webhick and Bohjan about a Poll could really hurt more than help, since "Design by consensus" it's not the best way to bring in a good solution.

So tomorrow I will post a more "classic" post about specific concerns.

corbacho’s picture

FileSize
53.6 KB
154.89 KB

I noticed yesterday a lot of tension and emotional responses.
So to cool things down, I will say that I love how much the Acquia Spark team has being patient with this issue and has explore different patterns.
It's only them who has brought a real toolbar and not prototypes .. and since Drupal is a Do-Acracy, as webchick always says. I will be really happy to see the current toolbar to be part of Drupal 8
It will be a huge step forward from what we have now.

Specially great work of Jesse building (and re-building) with different solutions. It's inspiring and I already told her personally.

---------------------------------------------------------------

Now I will explain my concerns, but if you see that these issues are not relevant, or they can be adressed later on, I won't have any problems. Really.
I decided to explain now my concerns so later on can't be said "This was already discussed in the thread xyz.. you are late"

Generally
=======================
Even we want a "unified UI", I feel like we are serving a "fully-featured desktop admin sidebar" to the mobile users, when they have different needs/constraints. And we want in this thread/patch to say "All or nothing", take it or leave it.

I mean that it's quite big-complex (but beautifully decoupled I have to say) JS, CSS, and HTML chunk for the poor CPU that are not last-generation phones. But probably this will be addressed later, so I will stop here.

Icons
=======================

I **love** the implementation and high-performance data-uri'ed vectorized image solution. (that's a neat solution that should be spread to every image/icon Drupal core is using)
But I will like to remove the Icons and replace them with only 1 generic top-level-menu icon by now and open a different issue to talk about it, because:
* We are talking about the Drupal visual identity without discussion.
* If a contrib wants to add custom links (without icons) then it looks un-balanced
* If a contrib module wants to add an icon. The maintainer will have to waste some hours (days) learning about how to create a new icon, vectorized it, data-uri'.
* If a themer wants to make a theme to give a new look to those nav icons, like "let's make them all with unicorns!", it would have to override all the core icons for sure, but *also* the contrib-module icons? (A total new icon kit ?).
* Because we save bandwith and CPU to render icons to mobile phones. each icon is 1 Kb. Together I think I count 14Kb (without the Home icon)
* The icons are data-uri'ed in the css itself. So that extra weight is going to be always there.. unless you override the *whole* toolbar.theme.css.
* I'm not an UX expert.. but I don't like "abstract" icons, because they don't say anything!. I find them useful for operations, like "Edit", "print"...

Expanding Icon on the left
=======================

Pattern A:
whole_button.jpg
Pattern B:
icon_left.jpg

In fact, I would like to use the "Icon" space for a "expand" symbol.
Because the current solution is trying to fight against 2 strong established patterns:
** Pattern A. Normally, in mobile, a row represents only one action
In almost every single mobile solution, native app, etc the whole row represents the same action, even though there are symbols in the row, as you notice in the screenshot. There is no "if you click in this part of the row, or in this symbol.. it makes something different"
** Pattern B. Normally, the "collapse" icon is on the left.
Accordions, trees, and almost every "collapse" behavior I've seen, has the icon on the left side of the row.

So we are fighting against those 2 patterns, I can warranty that most users will find the Drupal mobile navigation awkward.

Small concerns. Not important now
=======================
* I have other small concerns.. but they are not that important at this point, and I don't want to block this issue and make webchick fall into drugs
- @sun concern about indentation. Could we find a non-indentation solution to show deepness, probably with color, shadows, only ? )
- Could we bring our own (accessibility-ready!) Drupal autocomplete.js to the search box, as I commented here? #1781422: Add search/jump/command functionality to toolbar .
- Could we separate the accordion behavior to its own jQuery plugin to be re-used by other contrib. And also will be easier if contrib wants to override accordion behavior with other solution. (Just remove the accordion.js)
- If the toolbar won't work without JavaScript, could we deliver an already JSON formatted in the bottom of the HTML page, so it reduces the size, and 2nd makes easier to cache in client, and easier to make autocomplete and other cool features.
- Could we make the administration with dark background, as it was, and it is in every popular admin tool ? (no, I don't consider this bike-shedding. There are UX reasons to make a higher contrast between the actual content from the admin area)

webchick’s picture

I think one way to address concerns about the icons might be to move the icons into something like toolbar.icons.css, so that a contrib theme / module could indeed easily override them with their own scalable SVG icons (or png icons instead, or what have you) without having to override all of toolbar.theme.css. I'd really rather not remove the icons entirely from the design, at least as the first shot out, as they're pretty crucial to communicating the ideas, particularly on mobile where we don't have a lot of room (basically all of the top-level stuff: home, menu, user, search.. would need to collapse down to small icons in a 320px view). There's simply not enough room to display text for all of those.

jessebeach’s picture

That's a great idea webchick, I'll make that happen.

I'm cranking on a patch right now and hope to have it posted before Monday...

tkoleary’s picture

Assigned: webchick » Unassigned

Hi all. Below are some (brief) answers to comments from ry5n, corbacho and eigentor. I need to be brief because toolbar is only one of several designs for D8 interfaces I am working on and all must be ready for review by BAD camp. I urge every one else to be brief as well. We have a lot to do and little time to do it.


  • (on menu position toggle)" I suggest reverting this element to just a single icon with no label"
    That was, in fact, our first design, which did not test well. This may not yet be the solution. We will continue iterating on it.

  • "with several items and sub-items open, I expect that we’d see “IA Overwhelm” set in very quickly"
    I do not think so. Expanding any child collapses the children of it's siblings at any level which provides much more clarity than any other system we have employed.

  • "how to handle items that have their own page, plus children"
    All items have their own page, even if they are category menus, as structure and configuration are now. Clicking the item will bring you to the menu page. Clicking the "has children" affordance will expand the children. The user cannot simultaneously do both so there is no conflict.

  • "There are UX reasons to make a higher contrast between the actual content from the admin area"
    Perhaps but you forget that the menu must also stand out from the users actual site. See how the most recent invision prototype illustrates this.

  • "Could we find a non-indentation solution to show deepness"
    The indentation solution is already combined with color affordances to clarify and underscore the child levels. Without the indentation the color alone does not provide sufficient contrast (because it requires several shades for several levels) to pass accessibility tests. The indentation makes it accessible (to the visually impaired, not the blind).

  • "Normally, the "collapse" icon is on the left."
    If "normally" were a sufficient reason to dismiss a design then innovation would never happen. If Jesse's prototype does not pass usability tests then we will change it.

  • "I don't like "abstract" icons, because they don't say anything!"
    The purpose of icons is not to "say" anything. The icons are (usually) accompanied by text therefore their meaning is clear. Their purpose is to provide an additional visual anchor for the scanning eye to more quickly find the item they are looking for. There should be relatively few of them and they should apply to top level items because we don't want to tax memory (an error that Rubik makes) or they will become meaningless. Over time the user will recognize them as signposts and cease to have to read the text. That is their purpose. They are extremely efficient at it and that is why they are ubiquitous in interaction design.

  • "We are talking about the Drupal visual identity without discussion."
    These are wayfinding icons, not Drupal Branding, I would have no problem with a distro developer replacing this set with a sparkly purple set with rounded corners and gradients. It is the iconography that is important and which should be consistent.

  • "The maintainer will have to waste some hours (days) learning about how to create a new icon,"
    I promise to create an easy to use icon developer kit myself if people will just stop saying this. It's kind of like me saying "well this whole module thing is a non-starter because you expect people to spend untold hours learning to write PHP"

  • "If a contrib wants to add custom links (without icons) then it looks un-balanced"
    There will be a default generic icon in the event none is provided.

  • "Even @sun observations are being put down."
    Nobody's observations are being "put down", least of all Sun's. My goal and that of everyone on the Spark team is simply to move quickly to the best possible achievable solution and then continue to test and iterate on it. Nothing is, or will be, carved in stone. Everything will be tested. Everything can be changed. Let's please not self censor in the issue queue and gut features and design patterns before they have a chance to prove themselves. There will be plenty of time to remove them later if testing shows they do not work.

  • And @eigentor
    "This is a major change of UX and I would never expect to get it right in one fell swoop. This needs hands-on testing apart from user testing to find out what really makes sense, which you just cannot foresee."
    Thank you.

The revised invision prototype is here: http://invis.io/PK83F76X. Full disclosure I am not a World of Warcraft user, I simply needed a site that was sufficiently garish to illustrate the need for restraint in an interface that can surround literally any combination of colors and shapes. :)

webchick’s picture

Assigned: Unassigned » webchick

Full disclosure I am not a World of Warcraft user

... YET!

(After feature freeze though, please. ;))

Working on the issue summary.

webchick’s picture

Assigned: Unassigned » webchick
FileSize
206.52 KB

Tum te tum.

webchick’s picture

Issue summary: View changes

Updated the summary since #1608878: Add CTools dropbutton to core has been fixed.

webchick’s picture

Assigned: webchick » Unassigned

Ok, gave that a shot. I'm sure it's not 100% accurate, and it's definitely not 100% objective, but that is my current read on the situation and will hopefully help people coming in get more oriented to what's being proposed/discussed/decided here.

webchick’s picture

webchick’s picture

Issue tags: -ui-text usability +Usabilty

Uh, what?

ry5n’s picture

@tkoleary I've read your response, and @webchick I’ve read the new issue summary (thanks, and thanks). I think it's wise to stick with the D7UX findings and show only top-level items in the horizontal menu, so I’m voting right now with "I can live with this". My remaining concerns fall squarely in the "after a patch is committed" pile.

For the actual patch, I will pitch in with CSS and markup review at the very least, and will help out with more if I can.

ry5n’s picture

Issue summary: View changes

An attempt at an updated issue summary. I'm sure this still needs work.

tkoleary’s picture

@ry5n That's awesome. Any help would be deeply appreciated. :)

tkoleary’s picture

Issue summary: View changes

Clarifying a bit under horizontal design.

botris’s picture

"I can live with this" +1

I also totally agree that a holistic discussion / approach is necessary for the main navigation instrument. But I also think we need to be pragmatic and we need to take in account that time is running out until the freeze. Therefore I believe that we could benefit on setting a
(short-term) deadline for webchick’s first point of action ‘Get to "I can live with this" on the design…’. Because that seems to be the showstopper for moving ahead.

I am happy to test the new main patch or help out with patches / reviews for new sub-issues as they arise.

tkoleary’s picture

@boris sondagh That's great! The more help we can get the better.

Bojhan’s picture

I spoke with tkoleary about #159, apparently I missed what was MVP and what was North star regarding my concerns:

1. Add, vs Shorcut - postponed this discussion item till after feature freeze.

2. Remove toggle, horizontal default - horizontal will be default, toggle will stay there for discover ability.

3. Two search boxes - postponed this feature, till after feature freeze.

effulgentsia’s picture

horizontal will be default, toggle will stay there for discover ability

May I suggest deferring the toggle to a follow up? Even if there's consensus on its design, there might be some discussion needed on implementation, and I'd hate for that to slow down this issue, when it seems like the kind of thing that can be easily done in a follow up.

jessebeach’s picture

Issue tags: -Spark, -Usabilty

I've already got the toggle implemented (locally).

I promise a patch within 24 hours! The CSS has gotten a bit tangled through the course of three design iterations. I'm pulling it apart now.

webchick’s picture

Issue tags: +Usability, +Spark

I'm assuming that un-tagging was an accident. Restoring.

Be safe out there with Hurricane Sandy, Jesse!

jessebeach’s picture

I spent the last 72 hours refactoring the patch in #70 to match the designs in #170 (prototype). I realized just now that #126 should also be incorporated into this rolling patch.

Keep in mind, development work has been in Stark up to this point. Some styling issues (like the "Edit shortcuts" link wrapping to a new line in Bartik) may be present. This is a work in progress patch. Now that we're coming to consensus on design, I've started coding with the intent to propose a patch and not just provide a prototype experience. That being said, the code is, as stated, a work in progress. Feedback is welcomed and encouraged. I would first check that the issue you're raising isn't already covered in a sub-issue or follow-on task. See the issue summary for related issues. Please open related issues and link them here as well. Please also do pick up sub-issues and start working against them if you feel so moved. I will provide guidance.

This issue (#1137920) is intended to be a framework patch for the mobile ToolBar feature. Many enhancements to this base feature have been proposed and are represented in the designs. They will be addressed in separate issues as much as possible.

If you'd rather see commits as they happen instead of following patches, here is the development branch. I delete and rebase it frequently on 8.x, so your pulls might fail if you're following closely. Just delete your local branch and repull.

I'll be posting sub-issues following the posting of this patch. Some notable changes/issues with this patch that should be mentioned now:

  • Modules can now register a top-level tab with hook_toolbar_register_tabs(). Edit module is using this hook as well as User and Shortcut module. The intent of this change was remove code in shortcut.module that page_altered its information into the page build as well as provide a common means for modules to create top-level tabs and trays.
  • The JavaScript file (toolbar.js) is still a complete work in progress. I mostly got it to the point of working and sacrificed finesse to do it fast.
  • Everything needs comments. I've not been making extensive comments because the code has been in flux. Now is the time to start filling out the docs.
  • By hook_library_altering out the toolbar.icons.css file, all icons disappear and the toolbar styling downgrades gracefully.
  • Structure and style are well broken out between toolbar.base.css and toolbar.theme.css
  • The PHP side of this patch is the bit most in need of some input. I've been focused on the front-end code and have been noodling with the PHP just to get me to the point of producing the right HTML.

And finally, some screenshots.

ToolBar at 210px wide.

toolbar-210px-wide.png

ToolBar at 210px wide with the menu open.

toolbar-210px-wide-submenu.png

ToolBar at 320px wide with the menu open.

toolbar-320px-menu-open.png

ToolBar at 650px wide with the menu open.

toolbar-650px-menu-open.png

ToolBar at 800px wide with the menu open.

toolbar-800px-menu-open.png

ToolBar at 800px wide with the shortcuts open, horizontal orientation.

toolbar-800-shortcuts.png

ToolBar at 400px wide with the shortcuts open, horizontal orientation.

toolbar-400-shortcuts.png

ToolBar at 600px wide with the shortcuts open, vertical orientation.

toolbar-600-shortcuts.png

webchick’s picture

I've updated the demo site at http://spark.webchick.net/8.x/ with the latest version of Spark , which in turn contains the latest version of this patch.

moshe weitzman’s picture

Screenshots and your writeup work really well for me. Have not looked at code yet.

Minor feature request: Add a permanent 'Add shortcut' link to the bottom of the shortcuts menu. This will add current page to the shortcut list. Extra credit if that happens via AJAX without a page reload.

tkoleary’s picture

Heres the mobile version of the invision I promised in UX hours http://invis.io/3H82UD8B

tkoleary’s picture

Heres the mobile version of the invision I promised in UX hours http://invis.io/3H82UD8B

jessebeach’s picture

gmclelland’s picture

I really like the progress that is being made and the discussions. Great job everyone.

When looking at the prototype in #188 and #185, here is question that came to mind.

Should the user menu not be the same type of vertical menu as the main menu? Should it not come in from the left side as well. In the prototype it shows one level that drops down. I'm afraid there will be to many links to fit in that area. I think it would be better if we listed them vertically.

Here is what I was thinking when you click on the User Link in the menu bar:
--My Dashboard
--My Activity
--My Account
--My Profile
--My Registrations
--My Contacts
--My Groups
--My Subscriptions
--My Messages(private messages here)
--My Favorite Items
--Log Out
etc... the list goes in when you factor in contrib modules

What do you think? This could pose a challenge to when the menubar changes to the horizontal view. All those links might not fit.

Crazy idea, why can't we just use the mobile vertical version when viewing on a desktop or mobile? Maybe on the desktop or tablets the horizontal bar menu links could slightly expand horizontally exposing the icons with their names? I'm referring to Home, Menu, Search, Shortcuts, User, etc...

-This would give us a consistent UI across all devices.
-Less javascript to use, no need to worry about switching to a different kind of horizontal navigation.
-More space to work with because it is vertical, not space limiting horizontal
-Better for training and books because your showing the same UI

Let me step back a bit... On all devices you would see a 100% width black bar that runs across the top of the browser. When a menubar link is clicked, you will see the vertical menu come in from the left just like the main mobile prototype's menu.

-Crazy ideas, feel free to shoot this down or discuss.

gmclelland’s picture

Issue summary: View changes

Minor correction: content jessebeach --> contact jessebeach

jessebeach’s picture

Issue summary: View changes

Added, #1827284, #1827296, #1827302

jessebeach’s picture

@gmclelland, real quick to your point about horizontal/vertical orientation. In the current implementation, any tray (and each top level tab can have a tray), can be toggle between horizontal or vertical orientation.

toolbar-user-orientation-toggle.png

I just opened a sub-issue to preserve the orientation of a tray if the user actively pegs it to vertical. Otherwise, it will drift between horizontal and vertical depending on page size.

#1827302: Preserve the orientation state of the toolbar for individual users across page loads

jessebeach’s picture

Issue summary: View changes

added related issues

jessebeach’s picture

Issue summary: View changes

added #1827318

jessebeach’s picture

Issue summary: View changes

added #1827330

gmclelland’s picture

Great, I see now. Basically everything I talked about is exactly how it works now if you switch the orientation toggles on each tab/tray to vertical. I incorrectly assumed that orientation toggle was a global switch.

Is there any configuration settings behind the orientation toggle switch? Ex. Force vertical, or horizontal, or allow the user to choose with defaults?

Man, I need this module now for Drupal 7. :)

jessebeach’s picture

Well, my current thinking on the orientation toggle is that it's really only stick if you toggle to vertical. It won't jump to horizontal on a wide screen. My working assumption is that a tray toggle to horizontal will still switch to vertical on a small screen to prevent it from being unusable, but I could be disabused of that opinion.

gmclelland’s picture

Oh sorry, let me clarify. I like the way everything thing currently works. I was just wondering if their was a configuration setting that could disallow a user from using the orientation toggle completely.

In the settings you could have:
Vertical Only - don't display orientation toggle
Allow the user to choose - vertical toggle preselected
Allow the user to choose - horizontal toggle preselected

gmclelland’s picture

Sorry again for the noise.

Now I understand the correct terminology your using from #1782576: Remove the toolbar drawer and move the shortcuts to the toolbar tray
Toolbar Drawer = the second level navigation that displays vertically
Toolbar Tray = the thing that slides in from the left

So in that case the comment I left in #190 http://drupal.org/node/1137920#comment-6668724
was basically saying that maybe we should get rid of the Toolbar Drawer and only use vertical Toolbar Trays. What's your thoughts on that?

Then we wouldn't have to worry about orientation toggles at all.

Bojhan’s picture

Title: Toolbar completely broken for small screen sizes » Fix toolbar on small screen sizes and redesign toolbar for desktop

Having spend the last few months on this, I am confident we can start moving towards a more final version now that design consensus has been largely reached. The process has been difficult, but we now have a vertical menu on mobile which is what we set out to do. Concerns that are not solved, have been assured could be followups post feature freeze (e.g. having a orientation toggle, depth, add vs. shortcuts, search box).

I am agreeing to move forward with the direction provided in #184.

Lets get code reviews going!

Everett Zufelt’s picture

Initial accessibility thoughts from a super quick look at the demo site:

- Toolbar is at the bottom of the DOM, incredibly difficult to discover for screen-reader users. I suspect that keyboard only users don't tab directly to this on page load. Even w/ a skip link this pattern is disorientating to me.

- I don't really understand the meaning of the different buttons (home, menu, etc). I would likely learn over time and use

- Pressing menu appears to do nothing. I have to then go and find the menu that has been exposed.

- I have no idea what vertical / horizontal does (or I wouldn't if I hadn't read all comments on this issue)

- There is a text field at the very bottom of the DOM, I assume search, but it has no label. Again this is incredibly difficult to discover

- Clicking on a menu item like 'Structure' takes me to that page. I never get a second level of items exposed to me.

MustangGB’s picture

jessebeach’s picture

@Everett Zufelt, thank you for the feedback. Let me run through your points one by one. I want to make sure we address your concerns right away.

"Toolbar is at the bottom of the DOM".

I'm looking for best-practice on this point of where in the DOM to place the menu. I'm mostly agnostic, except for the argument one might make that placing highly repetitive content, such as a menu, at the bottom of the page allows unique page content to rise to the top of the DOM. I hear you saying though, that this makes the page less usable for folks screen-reading, so the takeaway here is move the toolbar to the page_top region. I will do that.

"Pressing menu appears to do nothing. I have to then go and find the menu that has been exposed."

Do you have a recommendation of how to indicate what happened and where the user should focus attention? Should I programmatically place focus on the first anchor in the tray that opens (the tray associated with the tab)?

"I have no idea what vertical / horizontal"

So the horizontal/vertical switch does not mutate the DOM in any way. It does, however, set second level and deeper menu links to display none in the horizontal orientation. Does that mess with screen readers? If so, we'll find a better way to hide those links.

"There is a text field at the very bottom of the DOM"

Hmm, the patch in #184 doesn't have a search box. I'll look into what this is. Maybe it's a stray feature test element.

"Clicking on a menu item like 'Structure' takes me to that page. I never get a second level of items exposed to me."

I'll bring this up with Kevin. We've been discussing the behavior of the sub-menu item exposure i.e. whether the label for the item takes you to that page or exposes sub-items. What if I placed the sub-menu toggle before the label for the parent item so you'd encounter the toggle first? And then we could add a description to the toggle like "Additional menu items under Structure", for example.

jessebeach’s picture

@gmclelland, the orientation toggle provides a quick and easy means for an end-user to tailor their admin experience to fit their available screen real estate. Given that it's already in the code and working, we've already got the enhanced experience on top of the solid basic experience that you describe in #195.

You're right about the drawer. The trays are the evolution of the drawer from D7. Now, each tab can have a "drawer". Modules can register a tab and they get a tray to place their top-level control structures. The D8 version of the Edit module is already doing this.

eigentor’s picture

@webchick darn I keep losing the login data four your 8.x demo site. A hint in which issue to find them?

webchick’s picture

It's in a big-ass block at the top of all pages. :) user: sparkles, pass: sparkItUp

corbacho’s picture

I'm working on keeping my comments short :)

* Thanks webchick for fixing the summary of this post. Totally awesome =)
* "I can live with it" : Me too!
* "no icons without discussion" has been partially addressed by @webchick @jesse solution to move them to separate icons.css. I'm quite happy with that
* I've found other places where other concerns are discussed:
* The "not-clear-behavior of the expanding-icon" is being discussed here #1807432: Collapsing menu items through > are not discoverable and waiting for UX tests results.
* The "JSON data instead of a HTML toolbar" is discussed here http://drupal.org/node/1805054 and here #1814932: Caching strategy for D8 toolbar
* I made some vertical-menu demos here Link or type in your phone: 70i.es/ab where I've implemented some of my suggestions in a vertical toolbar to see how "usable" I found them. (Not so much as I thought)... It has some basic aria roles, and half-implemented search box with the Drupal.core autocomplete.js (which is already) accessibility-ready
* But anyway.. I see that there is no time to "play" around more with different solutions so I'll review tonight/tomorrow Jesse's patch and try to help in the sub-issues

jessebeach’s picture

Thank you @corbacho! Please list your sub-issues in the issue summary so we can keep track of them in one place.

Please see #1781422: Add search/jump/command functionality to toolbar for work already underway on the search bar. We'd love to have your input in that issue.

jessebeach’s picture

benjifisher’s picture

FileSize
35.59 KB

I am restoring the "needs JavaScript review" tag: added in #189, removed (accidentally, I assume) in #190. Then again in #198 and #199. I may not know what I am doing, but at least I am being open about it.

Look what happens when the toolbar gets tall enough that it has to scroll (Mac OS, Chrome browser, Bartik theme):


toolbar with scrollbar
The scroll bar uses up some horizontal space, causing the item "Regional and language" to wrap. Now, the "expand" icon, set to height: 100%;, gets bigger than all the others. I tried height: 2.3em; and that works better (not that I have tested extensively).

Another thing that bothered me as I clicked randomly: suppose, in the screen shot, I click on "Media", below the expanded "Development" sub-menu. One sub-menu collapses, another opens, and suddenly the button I just pressed (and want to hit again, since that was a mistake!) has warped away from me. Maybe I will get used to it, or maybe a slower animation will help.

I find the horizontal/vertical toggle pretty intuitive--I guess some do not. It would be really sweet if it could be styled to look like a physical toggle switch, like the one on my surge protector.

Update: While listening to the radio yesterday, I learned a new word: skeuomorphism. If serious designers sneer at my suggestion of a toggle switch, so be it.

benjifisher’s picture

Issue summary: View changes

changed the "additional features" heading to "follow-on tasks"

Shyamala’s picture

Issue tags: +Needs JavaScript review
FileSize
41.78 KB
31.84 KB

Attached Screenshot of the toolbar in Ipad.


1) The expand icons are skewed in both Landscape and Portrait versions.
Portrait view on iPad
landscape view on ipad


2) Horizontal/vertical toggle has a very small touch area, specifically in the portrait mode.

3) Not sure the reason for the drawer for "Edit" tab is dark grey background while all the rest have a neat white background.

4) It was a little confusing that there is an independent Horizontal/vertical for each Tab

Shyamala’s picture

On Sony Ericsson X10i

  1. The menu's are not visible at all, in the portrait mode.
  2. In the landscape mode the expand icons are not visible, will post screenshots shortly.
jessebeach’s picture

Issue summary: View changes

added #1829326

jessebeach’s picture

Issue summary: View changes

added #1829532

LewisNyman’s picture

"Toolbar is at the bottom of the DOM".

@jessebeach @Everett Zufelt, is it possible fix this by setting a "tabindex -1" attribute to the toolbar? Or would this conflict with the front end theme?

jessebeach’s picture

  1. Moved the toolbar from page_bottom to page_top (see #197)
  2. Addressed #1827330: Fix overlay placement which is broken in the current D8 ToolBar patch. The changes were minor, so I just rolled them into this patch.
  3. Adjusted the vertical/horizontal breakpoint to 50em (640px) to match the point at which the overlay renders

See interdiff for the full set of changes from #184.

Everett Zufelt’s picture

Do you have a recommendation of how to indicate what happened and where the user should focus attention? Should I programmatically place focus on the first anchor in the tray that opens (the tray associated with the tab)?

Not sure, I'd need to understand fully how this works, what the use-case is, and ideally see screen-reader users interact. If you move focus then users may miss the content they have jumped over. If you don't, they'll have difficulty finding it.

So the horizontal/vertical switch does not mutate the DOM in any way. It does, however, set second level and deeper menu links to display none in the horizontal orientation. Does that mess with screen readers? If so, we'll find a better way to hide those links.

I'd say that hiding content is DOM mutation :) Horizontal and vertical are visual references. what is the actual change in functionality between the two? How can I tell which is active? Can I set one to sticky (never changes)?

corbacho’s picture

FileSize
3.19 KB
37 KB
150.43 KB

I like more the JS / CSS from what I saw last week. Nice clean-up

* Now that toolbar has moved to the top, when browsing with "JavaScript disabled", you will see a full-width long menu in the top of the page. Can we hide it by default in HTML and display it from JS ?

(Most of errors shown in the console of this screenshots are about Edit module, so ignore them)
IE8
The polyfill of mediaquery for IE8 isn't working?. Always shows the menu in this state: (* I also tried it locally-manually the patch)
ie8.png

IE9
Doesn't render so nicely the SVG icons as Chrome.. but nothing we can do.
But the icon is cropped.
ie9.png

Do you think is good that the sidebar has its own scroll with overflow-y ? I think not all mobile browsers read that very well, there are glitches. Could we let the sidebar be part of the body (like #203 prototypes), so you will need to scroll down the whole page, not that specific div? Then we will gain back the space that is taken the scrollbar and it could be used more creatively. For example to show a mark of "you are in this page": (wordpress way, or google+ way:

And now a review of the patch

+++ b/core/modules/toolbar/js/toolbar.js
@@ -0,0 +1,532 @@
+      // Register trays.
+      Drupal.toolbar.trays = [];
+      $trays = $toolbar.find('.tray');

I don't see much benefit on register trays. It's only used to loop & trigger changeOrientation callback on them. Could the tray itself listen for the event instead of a centralized place ?

If not, I wonder if Drupal.behaviors() can be used (or be updated) to handle re-attaching behaviors when there is a orientation change.

Toolbar won't be the only component that needs to be aware of orientation changes.

+++ b/core/modules/toolbar/js/toolbar.js
@@ -0,0 +1,532 @@
+      var trayH = $tray.outerHeight();
...
+      for (var i = disableTabs.length - 1; i >= 0; i--) {
+        if (disableTabs[i]) {
+          disableTabs[i].toggle(false);
+        }
+      };

not needed ; after a "for". I've seen in several places.

+++ b/core/modules/toolbar/js/toolbar.js
@@ -0,0 +1,532 @@
+  this.tray;

not used

+++ b/core/modules/toolbar/js/toolbar.js
@@ -0,0 +1,532 @@
+  },

trailing commas will stop IE7 JS execution, (although I know we don't support it)

+++ b/core/modules/toolbar/js/toolbar.js
@@ -0,0 +1,532 @@
+var interactiveMenuDecorator = function () {

Besides I like the name (sounds like a profession LOL), I would like to see this code in its own jQuery plugin? So contribs can use the accordion for their own menus. And if someone wants a different "Decorator", then they could remove the .js in the backend easily.

+++ b/core/modules/toolbar/js/toolbar.js
@@ -0,0 +1,532 @@
+      [((isHidden) ? 'add' : 'remove') + 'Class']('open');

_nod already said before.. isn't this more clear with .toggleClass ?

+++ b/core/modules/toolbar/js/toolbar.js
@@ -0,0 +1,532 @@
+    var $root = $wrapper.children('.' + rootClass);

This variable is not used

+++ b/core/modules/toolbar/js/toolbar.js
@@ -0,0 +1,532 @@
+    $li
+      .each(function (index, element) {

There are 2 times .each() loops over the same items. (the other one some lines below) Could it be grouped in the same loop.

+++ b/core/modules/toolbar/js/toolbar.js
@@ -0,0 +1,532 @@
+        listUpdate.add(_.bind(initItems, context));
+        listUpdate.add(_.bind(markListLevels, context, $root));
+        listUpdate.add(_.bind(setLevelVisibility, context, $root, 1));

In these 3 functions will produce in total 4 loops over li items. Although this way looks more clear (atomic functions), all these functions are used only during the "initialization" phase.. so could be grouped a little more in a single loop/callback? (or 2)

MustangGB’s picture

Do you think is good that the sidebar has its own scroll with overflow-y ?

Eww no, that's horrible.

corbacho’s picture

@akamustang
That quote is out of context... I meant the opposite
Just to clarify:
* Now: overflow-y:auto; with "position:fixed
* Awful: (what you understood ? ) overflow-y:scroll;,
* My suggestion: position the sidebar in a way that never displays a scrollbar. So, yes, you will need to scroll the whole body page. 70i.es/ab for a example. That will simplify things and we will avoid bugs and mobile issues.

jessebeach’s picture

A bunch of us are in Berkeley sprinting on Toolbar issues from 11/5 to 11/6.

@Everett Zufelt, would you mind if we postpone discussion (or at the very least action) on your feedback until Toronto. I promise we'll sit down and go through a thorough review in person.

@corbacho, thank you for the reviews. I'm working through them now and incorporating.

jessebeach’s picture

#BADcamp mobile sprint first quarter update. I've merged changes from #1830526: Toolbar module should implement and document its own hooks. into node/1137920-responsive-toolbar. @benjifisher's updates are much much much better than the code that was there and I consider them part of the core part we'll propose here. Latest patch and interdiff provided in this comment.

@nod_ and I did a review of the current state of the javascript. I'm currently implementing the results of that conversations as well as taking @corbacho's comments into account as well.

I'll have another patch up at the end of today.

attiks’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 1137920_responsive-toolbar_216.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

Added #1830526 to the list of follow-on tasks.

JohnAlbin’s picture

I updated the issue summary to show which sub-tasks are pre- and post- feature freeze. http://drupal.org/node/1137920#summary-api-changes

jessebeach’s picture

Status: Needs work » Needs review
FileSize
93.01 KB
31.74 KB

Ok, this is second patch for the Mobile BADcamp sprint. The interdiff.txt shows the delta between #216 and #220.

In this updated patch, I address #1827284: Preserve the open state of the toolbar for individual users across page loads and #1827302: Preserve the orientation state of the toolbar for individual users across page loads.

I refactored toolbar.js after discussions with nod_. The code no longer creates object for ToolBar, Tray and Tabs. Instead, it preserves state through data attributes in the DOM and avoids premature optimization.

The interactiveMenu decoration function is pulled out and turned into a jQuery plugin.

The depedency on underscore has been removed.

Tomorrow, I plan to address the active trail styling #1827296: Mark up the currently active menu trail in the menu list, opening the menu to the active item on page load, and optimizing (read, making it work) the styling for the vertical tray on devices.

benjifisher’s picture

Do we worry about users who have JS disabled?

If so, what should happen if such a user clicks on the Menu tab? I can think of two reasonable answers:

  1. The tab is a simple link to admin. The toolbar is essentially static: whatever default behavior we choose will stick.
  2. The page reloads with the Menu tray expanded. The toolbar behaves just like the JS version except that every click requires a page load.
attiks’s picture

Status: Needs review » Needs work

The last submitted patch, 1137920_responsive-toolbar_220.patch, failed testing.

jessebeach’s picture

@benjifisher re:221, I think option 1 is the best i.e. that the "admin" link simply directs to /admin in a no-js scenario.

JohnAlbin’s picture

Status: Needs work » Needs review
Issue tags: -Usability, -mobile, -Accessibility, -Needs accessibility review, -Needs JavaScript review, -#d8ux, -d8mux, -Spark

Status: Needs review » Needs work
Issue tags: +Usability, +mobile, +Accessibility, +Needs accessibility review, +Needs JavaScript review, +#d8ux, +d8mux, +Spark

The last submitted patch, 1137920_responsive-toolbar_220.patch, failed testing.

jessebeach’s picture

This is the final patch from the BADcamp mobile sprint. The interdiff provides the changes from #220. Here are the changes in brief.

Work we still need to accomplish.

I would appreciate and wholly welcome any help with fixing tests and updating test coverage. SimpleTest is not in any way my strong suite.

This patch is moving now into code review, code cleanup and documentation.

Testing site

http://toolbar.qemistry.us/

Credentials are listed in a block on the site itself.

jessebeach’s picture

Issue summary: View changes

Update issue summary

gmclelland’s picture

@jessebeach - just quickly tested http://toolbar.qemistry.us/ on the desktop and phone Samsung Captivate SGH-I897 running Gingerbread.

The desktop worked great, but the phone showed the menus listed above the page header. It almost looked like the navbar wasn't using any JS or CSS. The rest of the page was styled.

I tried using three different browsers:
Stock Browser - showed navbar unstyled
Boat Browser - showed navbar unstyled
Firefox - showed navbar styled but the circle arrows were squished vertically.

On the desktop the menus persisted between page loads and everything looked good.

webchick’s picture

Oh my goodnesss, this is so much better with the sticky toggle!! :D I'm just going to brain-dump some stuff and happy to hear "x can/should be a follow-up" type of feedback.

Couple of nits:

toolbar-formatting.png

I'd like to fix the "Edit shortcut" wrapping in this patch if we can, since it looks pretty obviously broken. Further design refinements to make sub-nav without icons stand out more can be a follow-up, though.

Not sure if this is an actual bug, or if we can actually do anything about it if it is. But Horizontal/vertical switching seems to be broken in the Overlay. If I go to a page like
http://toolbar.qemistry.us/#overlay=admin/structure/types at a wide orientation, then shrink to a smaller orientation, the toolbar just falls off entirely and there's no way to get it back. In theory this is not that big of a problem though, since the Overlay gets disabled when the screen width is less than (some size I can't remember), though.

It would be really nice if the drawer underneath User, Shortcut, etc. could default to horizontal orientation, and only switch to vertical if it runs out of space. That probably involves magical sparkle ponies, but in seriousness, this looks pretty weird:

toolbar-vertical-sub.png

I tested this on my first-generation Droid, and the toolbar is just a huge unstyled menu (well, more accurately, it is one set of list bullets with "Home, Menu, toolbar_tester, Shortcuts" and then a full menu tree with all of the menu links fully expanded) that appears above the content. I have no idea how to take a screenshot from this phone or I would post one. :( Hopefully that description is clear.

But the end result is it causes me to have to scroll down basically 3.5 screen heights to get to the actual content of the page. On every. single. page. I'm not sure how to reconcile this with Everett's feedback to keep it at the top, but I don't know that we can ship core with it acting like this on older browsers... :\ Can we just add a sister "Skip to navigation" link for screen readers, maybe, and move the toolbar back down to the bottom?

Kinda unrelated, but would it be possible to choose a user/pass for the demo site that's shorter/easier to spell? I found it difficult to test this on mobile (in addition to not having screenshot capabilities, my phone seems to also unable to copy/paste the credentials from the box) right now because I needed to look at the pass, scroll down, type a couple of characters, scroll back up, repeat two or three times. "a/a" is a fine user/password combo. :D

benjifisher’s picture

@webchick:

Did you consider using a camera to take a screen shot? JPEG file attachements are allowed.

jessebeach’s picture

For screenshots on Android devices, hold down the 'Volume Down" rocker and the power button at the same time.

@gmclelland & @webchick, Given both of you ran into the giant-menu-of-endless-scrolling at the top of the page, I think it will be necessary to move the menus to the bottom of the page and find a way to satisfy accessibility concerns given that DOM structure. Everett and Mike Gifford will work with me in two weeks in Toronto to work out a satisfactory interaction.

@benjifisher, thank you for helping with tests. Can you work in the branch node/1834822-tests in the sandbox? This way there's no chance I'll accidentally blow away your work when rebasing the 1137920 branch. We'll merge your work into this queue when its ready.

@webchick, I can make the orientation of the non-menu trays horizontal until told otherwise. I might add another breakpoint for these "short" list trays to key off of.

Shyamala’s picture

Attached screen shots for Menu on Android and iphone.
ANDROID

"the toolbar is just a huge unstyled menu"

android
android

IPHONE

Please note the overlay page title - Administration is hidden below the top nav in iphone

iphone
iphone

nod_’s picture

Moved around some JS to make it pass JSHint and update some jQuery things to make them consistent with the rest of core js. Mainly:

  • from $('selector', $element) to $element.find('selector')
  • making named function out of var myfunction = function () {};
  • Simplified some crazy jQuery selector chaining :p
  • updated dependencies

I tried to be careful but I'm not sure if I broke something in the process, might be a good thing to update http://drupal.org/node/1777342 with some toolbar tests.

The patch is missing a listener on localstorage events to propagate the changes on all tabs when the orientation is changed or when a menu is opened.

This looks great :) and some dodgy toolbar code was removed by the patch and that makes me happy, marking #1772724: Remove most of toolbar things and put that in shortcut as dup :)
Look ma! no cookies!

Shyamala’s picture

As a best practice on mobile, contextual links (like what google mail uses in the mobile app) should be at the top. Where in the user can act based on the page context. Whereas any additional navigation should not be in the way of the content being displayed.

I second the menus at the bottom of the page approach for additional navigation. Would it be a possibility that the top nav bar should be available and a click on the icons should toggle to the menu at the bottom of the page. Not sure if this option is already discussed and the impact for a screen-reader or keyboard only user.

dodorama’s picture

Would it be possible, on mobile, to hide the drawer when following a link? It stays open and actually hides the page behind. This makes sense on desktop but it's annoying on a phone.

JohnAlbin’s picture

Status: Needs work » Needs review

Letting the bot do tests on nod_'s latest patch.

Status: Needs review » Needs work

The last submitted patch, core-toolbar-1137920-233.patch, failed testing.

mbrett5062’s picture

Just tested this on my desktop. In IE 10.0.9200 (Ships with Win 8), Firefox 16.02, Google Chrome 23.0.1271.64.

Found the following issues.

IE 10 on first time open horizontal menu the items a all skewed at different vertical heights. Switch to vertical menu and back and it is correct. This is repeatable. Just refresh with menu off and reopen horizontal menu from to menu switch.
Picture attached. (Not an issue in FF or Chrome)

First Open Horizontal

In IE and Firefox the buttons on vertical menu are squished to use a webchick term.

See attached picture.

Vertical

With some testing I find that changing some settings in CSS helps but not complete solve.

Background origin: change to border-box from content-box
Background size: change to 75% 75% from 100% 100%
Width: change to 3em from 3.5em

nod_’s picture

This might be because of my reroll, I'd let jesse say what's what and I'd be happy to fix what i broke during the reroll (and fix other issues if needed too).

jessebeach’s picture

nod_, most likely nothing to do with your reroll.

I'm working now to incorporate comments from #228 to #238 on top of the patch from nod_ in #233. I'll have something posted this afternoon (11/8, EST).

benjifisher’s picture

I have two stray data points that might or might not be helpful in diagnosing some of these bugs.

  1. I recently loaded http://toolbar.qemistry.us/ using my desktop computer (Mac OS X, Chrome browser) and got the toolbar as an unstyled list, much like the first screen shot in #232. I reloaded the page, and got the styling back. It looks to me like a CSS caching issue, since I had used the same browser on the same site with a previous incarnation of the code.
  2. When I connected my laptop (running the code locally) to a projector, the icons were squished (to use the accepted term) as in #238.
benjifisher’s picture

Now that http://toolbar.qemistry.us/ has an easier-to-type password, I tried it out on my aging iPod Touch. (I think the hardware is "second generation"; software version 4.2.1; not sure which version of Safari it has.)

The toolbar displays as a row of icons, as we want it to. In landscape orientation, it all gets bigger but I still get icons, no text. As I continue to reload, I sometimes see a flash of the unstyled list.

When I click on one of the icons, I get a page load, as if JS is disabled. I checked the settings, and JS is *enabled*. While I was poking at the settings, I noticed the "show errors" option, so I turned it on, went back to Safari, and reloaded. One error:

JavaScript Error on Line 93
http://toolbar.qemistry.us/core/misc/drupal.js?v=8.0-dev
DrupalBehaviorError: attach ; toolbar: Can't find variable: matchMedia
nod_’s picture

if the prototype site isn't up to date that's normal there were some issues with library dependencies that my patch fixed.

MustangGB’s picture

FileSize
29.66 KB

Menu Centre

jessebeach’s picture

Issues with Internet Explorer ended up consuming my afternoon yesterday. The jagged top-edge of the menu items in the tray (#238) ended up being an issue with IEs interpretation of dynamically added classes and when repaints are fired. I got it fixed eventually, after much frustration and gnashing of teeth.

In this patch

  • Fixed a JS error with JSON.parse when it's passed a jQuery expression that returns undefined (jQuery.attr). This could have been the cause of the giant unstyled menu at the top of the page that many people reported.
  • Moved the toolbar from page_top to page_bottom.
  • Cleared up some issues with the changeOrientation function of the toolbar.
  • Icons should look a little better now.

What I'm working on next

  • Adding an icon sprite for UAs that don't support base-64 encoded data.
  • Removing the open state stickiness on small devices (#235).
  • Removing per-tray orientation control and making the current orientation apply to all trays.
  • Investigating the matchMedia error reported in #242.

What I need help with

TESTS!

Interdiff from #233 is attached.

mbrett5062’s picture

Status: Needs work » Needs review

Lets test that.

benjifisher’s picture

@JohnAlbin, @mbrett5062:

You can set to NR if you are interested in particular tests, but we will not get an overall pass until we address #1834822: Reestablish test coverage of the toolbar module that was disrupted by mobile update work. (I plan to work on it early next week unless someone beats me to it.)


Suppose I am deep in the sub-menus. (So far, Menu > Configuration > Development is as deep as I can get.) Then my cat walks across my trackpadand opens Menu > Content. I shoo her off and open Menu > Configuration, but Development is not open. Why close all children of the Configuration sub-menu? This does not happen when I switch to the Shortcuts tray.

mbrett5062’s picture

@benjifisher I hear you. Just wanted to see we have not regressed from previous test with latest changes.
Would love to help with test fixes, but have no clue. Will google it now.

Status: Needs review » Needs work

The last submitted patch, 1137920_responsive-toolbar_245.patch, failed testing.

jessebeach’s picture

Great feedback everyone! Keep it coming. I promise I'm working through all the points you bring up as quickly as possible given all the current priorities I have.

mbrett5062’s picture

By the way, the test failures seem to be in no way related to this patch. Unless I am missing something entirely.
But then I am no expert on simpletest.

laura s’s picture

I have a conceptual perspective to offer. But I've missed the sprints and this issue is pretty far along. If it's too late, too different, please just tell me to shut up.

The concept of "toolbar" is I think a limiting frame, especially when it comes to mobile. I prefer to think of it as an application interface -- much more so than in desktop, which has so much real estate and lean-forward affordances. When I think of the mobile apps (whether native or HTML5 webapps) that I like, they keep things clean and do not crowd the space. Part of this is required for visual understanding. But part of this is simple ergonomics: If the links/buttons are too small, you cannot tap them accurately. Anyway, enough preamble....

If we think of the admin toolbar in mobile as being a Drupal administrative application, we can let go of some menu assumptions and design patterns, open things up and keep things simple. What I'm proposing here is going with the vertical "menu" and letting each menu level completely fill the screen (less perhaps a fixed menu at top, which is what the active designs seem to have anyway). Tap on a menu item (which perhaps has a > icon hint) and the entire block slides left to reveal the child menu. Any menu that runs too long can scroll down. Going back follows the same flow. In effect it's a :focus approach. Swipe gestures are an extra affordance, but this could work with just taps and transitions. It's a very common design pattern in mobile apps these days, but if what I'm describing is not clear, I can work up a mockup or post some examples.

From the designs shared, it seems that maybe some might be embracing that. I can't be certain without the device frame indicated in the mockup. The device is part of the design. Having blocks floating around not anchored to all 4 sides can feel a bit squishy and uncertain. Anchoring them to fill the screen can make the experience quite solid.

(By the by, this is awesome work here, especially all the patches implementing the ideas. I've been following for a while, but it's a bit intimidating to have so much to plow through. My quick scanning of just the last month of activity took about a half hour. Close reading would take 3-4 hours, I think. That's probably why fewer are sounding off.)

laura s’s picture

Hit submit too soon.

In effect it's a :focus approach.

I meant :target approach.

nod_’s picture

I agree with this, but that's improvement material, there is a lot to be done before we can get to this point (getting a way to handle touch events in core for starter). Keep those ideas in the back of your head and we'll open a follow-up issue with improvements. It needs broader discussion and as you said, we got more than enough discussion going for the current feature-set :)

Bojhan’s picture

@laura s That proposal is actually one of the first iterations shared by lewis, see http://nav.d8mux.org. It has very compelling features such as significantly reducing visual distractions and relying on very basic gesture based navigation. However we decided to go down a different route based on patterns that keep you close to the "site" e.g. facebook app.

Sadly, its probably to late to reconsider that direction. We are now already about 4 weeks deep into implementing this, and its proven to be quite a technical challenge. Given that we want to get this into core before feature freeze, we should be pushing forward with this.

webchick’s picture

#1261002: Draggable tables do not work on touch screen devices is the issue where we're looking at hammer.js to add touch support for core. That's probably a good way to direct energy to that such refactoring is possible after feature freeze.

jessebeach’s picture

I've updated the testing site with the patch in #245.

http://toolbar.qemistry.us/

benjifisher’s picture

I think that @Bojhan is right in #255: we do not have time to implement a very different design before feature freeze.

In #156, I suggested making the toolbar a block that can be added to a region and enabled or disabled. If we adopt this approach, then contrib modules could implement alternatives such as the one @laura s described in #252.

Maybe the system is already flexible enough to be overridden by contrib modules and themes. With hook_toolbar_alter(), a module can modify the HTML if needed. Most of the action is going on in javascript and CSS, which can be overridden by themes (and maybe also by modules).

gmclelland’s picture

Retested on http://toolbar.qemistry.us/ on the desktop and phone Samsung Captivate SGH-I897 running Gingerbread.

I tried using three different browsers:
Stock Browser - showed navbar menu unstyled at the bottom of the page
Boat Browser - showed navbar menu unstyled at the bottom of the page
Firefox - showed navbar styled correctly, now the circle arrows appear correctly

On the desktop everything looked good. Can you remove the underline on the menu links/buttons that are displayed only in the black navbar?

corbacho’s picture

Great work Jesse! This is getting better.
_nod patch was good, code is more clear. But I didn't like that he removed all the children().. maybe they are noisy ;) but some of them were faster than find(). I'll make a proper review next patch of Jesse.

It's funny that I had almost same thoughts than @laura first time I read this issue. But not anymore:

  • "Tap to slide whole screen to a next level" is great for browsing folders or categories (github and bitbutcket android apps work like that). and I see also in jQuery Mobile framework: nested lists. But in Drupal's navigation case, every single item is a link to its own page, including the container. So how you can address this issue.. and maintaining a unified navigation for desktop/mobile ?
  • Why not to cover the whole screen: so the user doesn't feel lost, as @Bohjan said. There is a great analysis of sidebar menu pattern . See the "Let the user know his current view"

--------------------
In #167 I said "I don't see so many examples out there with the "collapse icon on the left of the row". Well, to support @tkoleary 's vision. I saw a good example of his pattern: Android API dev documentation.
--------------------
This week has been released a jQuery plugin http://jpanelmenu.com/ (don't you like dark sidebar background? hint hint ;)
It's too bloated for my taste.. but I saw a little pearl, someone proposing a pull request for touch events. It's quite good implementation.. because anyways it's difficult to get a good solution, as explained here: Google developers (ghost clicks).
A summary: 'click' event has a 300 ms delay after 'touchstart'. Yep It's enough delay to feel it slow. But anyway, this issue can be addressed later on. When I did 70i.es/ab I did them with 'touchend' and you can tell is faster. But it didn't prevent totally the ghost click in some mobile browsers.
--------------------------------
PS. Just a reminder: Test the site manually or http://toolbar.qemistry.us/ . (IMHO) we shouldn't test on webchick's Spark demo site, since the toolbar is not isolated. Aka, the Edit module and other stuff can interfere with JavaScript execution. (as you can see in #212 screenshots)

jthorson’s picture

Did some debugging on #245 today, directly on the testbot.

The ModuleAPITest failure can be resolved by adding dependencies[] = breakpoint to the standard installation profiles info file (/core/profiles/standard/standard.info). Of course, I'm making an assumption here that the intent was for breakpoint to be included in core, and as part of standard profile.

The Upgrade test failures are due to entity_get_info('breakpoint_group') coming back empty, inside of entity_get_controller. This is causing 'class name must be string or object' PHP errors on the testbot, which in turn causes post-upgrade page to respond with an HTTP 500 instead of 200. I'm speculating that the root cause is similar to that in the ModuleAPITest, in that the breakpoint module may not be enabled following the upgrade operation ... especially since this is only affecting the StandardProfile upgrade tests.

jessebeach’s picture

I removed the open state stickiness on small devices (#235) so a toolbar, open a previous page, doesn't open on a new page and obscure the page.

attiks’s picture

#261 Any idea who's calling entity_get_info('breakpoint_group'), regarding the upgrade, toolbar is depending on breakpoint, so if upgrading it has to be enabled.

mbrett5062’s picture

Have tested latest patch.

Tested on the following A) Desktop: FF 16.0.2, IE 10.0.9200.16384, Chrome 23.0.1271.64 B) Phone: Verizon Samsung Galaxy S3 ICS

1) In FF the final breakpoint is not working. Menu bar does not collapse to text only, and page does not drop below open menu. Works in IE10 and Chrome.

2) The final breakpoint should fire earlier. I see in IE10 and Chrome, that the page disappears behind the menu, before the screen gets to the breakpoint to collapse all to text, with page below open menu.

3) Nothing we can do about this. FF and IE report client width as 433px just before page disappears behind menu. Chrome does not count the scrollbar, so reports client width as 450px at same time.

4) On my phone all looks well in both portrait and landscape. It does offer in landscape option of horizontal menu, but the text overflows under the horizontal/vertical tab.

Screen shots attached. (Sorry about blurry phone snaps. Had to take with wife's phone)

Won't inline images, as they are pretty large. And sorry for size of files.

mbrett5062’s picture

One other point. If the user zooms in, the menu starts to take over the screen. At any zoom level other then 1 we should make the menu scroll with the page, not sticky at the top.

mbrett5062’s picture

And a final note. So far I have only been reporting issues/bugs.

I feel I should also give my positive feedback.

Overall, I like were this is going. I like the look and feel. It seems very usable, and user friendly.
I can see me being very happy with using this in production, and even from my phone.
A big ++1 for everything done so far.
Thank you to all who have labored long and hard over this difficult task.

corbacho’s picture

Thx Michael++. You didn't mention but I see #264 desktop screenshots are from Windows8, cool we are covering all devices and OS.
And btw, a nice way to take Samsung S2 (or S3) screenshots is like this (method 1) and download them to desktop via airdroid (if phone and computer under same wifi)

mbrett5062’s picture

Great, thanks for the tips, they work great. And yes, Win 8 OS.

dodorama’s picture

FileSize
22.94 KB

I would still consider letting the tray occupy the whole screen. I understand the logic for not doing it, but in our case we have the arrows to expand the submenu on the right side very close to the underlying page. It happened to me more than once, while testing, to accidentally hit a link in the page rather than the icon. I see a critical usability issue, here. Even in terms of clarity, it might sometimes be hard to tell the tray apart from the page (regardless of the shadow). I wonder why we moved away from the dark grey background of D7 shortcuts tray.

tray target issue

benjifisher’s picture

I am working on #1834822: Reestablish test coverage of the toolbar module that was disrupted by mobile update work today. Let's try not to duplicate our efforts. Let's also discuss testing issues there, including follow-ups to #261 above.

jessebeach’s picture

Addressed spacing issue in #244 from @akamustang.

Before
toolbar-icons-left-padding-before.png

After
toolbar-icons-left-padding-after.png

Addressed open sub-menu issue in #247 from @benjifisher

Sub menus now remain in their open/closed position even when their parent menu is collapsed.

Addressed issues in #264 by @mbrett5062.

The final breakpoint can be triggered in FF if you turn on the browser dev tools and shrink the window. I don't think FF registers window resizes below a certain level. Just window resize:

ff-final-break-no-tools.png

With the dev tools turns on

ff-final-break-with-tools.png

To the second point, I need a little more detail about what firing earlier means. Should the breakpoint be larger or smaller in your opinion?

To the rest, thanks for the screenshots! It's very helpful to see the site on different devices.

Addressed issues in #265 by @mbrett5062.

A quick search of detecting user page zoom value reveals it's really messy to get the value and not at all reliable.

http://stackoverflow.com/questions/1713771/how-to-detect-page-zoom-level...

In principle I agree with you. If you can point me in a good development direction, we'll see if we can't improve this aspect.

Conclusion

As best I could, I addressed all comments up to this point.

benjifisher’s picture

FileSize
25.05 KB

I have a feeling you will not want to thank me for this screen shot. Horizontal scrolling, ugh! In the world of magical sparkle ponies, the toolbar would ignore the scroll bar, at least at this width.


vertical toolbar with horizontal scrolling


Mac OS X, Chrome, admin/modules.

SeanBannister’s picture

Certainly don't want to get to caught up with this but I noticed somewhere between #207 and #229 the order of the top menu items changed from:

Home, Menu, Shortcuts, User
to:
Home, Menu, User, Shortcuts

Wouldn't the original method of putting "user" on the right follow the usual convention on the web. And putting menu and shortcut next to each other because they're both methods of navigating the site.

jessebeach’s picture

Good catch SeanBannister. I noticed that too. It's been updated in patch #271.

mbrett5062’s picture

@jessebeach I found this on stackoverflow

You can get the users zoom level by comparing the innerWidth and document width. Document width is the width of the device in pixels, inner width is the pixels which are on screen when zoomed (in relation to what the document width initially was). I have tested this on android (ICS and Jellybean), and iOS (5 and 6) and it seems to work. Note, I do not have my viewport set to device width or height

ratio = document.width / window.innerWidth

if ratio > 1 then zommed else notZoomed
Then you can do this check whenever a user makes a double tap or a pinch.

I should point out, this issue was apparent with horizontal menu on my ICS phone. But default is vertical menu, so not really an issue there.
I just thought maybe that would also apply on ipads and such.

Also trying to get some way of describing the fire earlier breakpoint. Will get back to you on that.

benjifisher’s picture

@jessebeach:

A few comments on the interdiff from #271. (Excuse me while I pat myself on the back for adding weight ordering ... ouch!)


@@ -3117,6 +3117,7 @@ function user_toolbar() {
     'tray' => array(
       '#pre_render' => array('user_toolbar_pre_render'),
     ),
+    'weight' => -5,
   );

You now have Home, Menu, Shortcuts, User set to -20, -15, -10, -5, respectively. The default weight is 0, so any contrib tabs will go to the right of User. If I understand @SeanBannister (#273) then User should be set to +10 or something.


       // Close open siblings and their open children.
       var $openItems = $item.siblings().filter('.open');
-      $openItems = $openItems.add($openItems.find('.open'));
       toggleList($openItems, false);

This fixes the annoyance I pointed out in #247, thanks. Please update the comment.


- * Modules register tabs with hook_toolbar_register_tabs.
+ * Modules register tabs with hook_toolbar.

Maybe also mention hook_toolbar_alter(). I think the usual style is to include the parentheses. For example, core/includes/update.inc has

    //  @todo: figure out what to do about hook_install() and hook_enable().
mbrett5062’s picture

OK Jesse, I have retested and come up with the following.

In toolbar.base.css and toolbar.icons.css

Change media queries from

@media screen and (min-width: 16.5em)
and
@media screen and (min-width: 28.125em)

to the following

@media screen and (min-width: 28em)
and
@media screen and (min-width: 28.01em)

Not perfect, and does screw with horizontal toolbar. But it eliminates the situation between the old media queries were content disappears from screen behind toolbar.

The offset of content below toolbar on collapse will need to be adjusted slightly.

Hope this helps. Just try it out, and resize your window by dragging, I think you will see what I mean between old and new.

jessebeach’s picture

@mbrett5062, please join #drupal-contribute to talk over the details of the changes you're proposing.

mbrett5062’s picture

Ahhh just realized, you had the content hidden even after collapse of menu to text only. It is only offset from menu, and not from tray. Maybe that negates what I am talking about. I thought the intention was to push content all the way down. But your intent is that after reaching menu item they want the user is brought back to the admin page, and the tray disappears.

mbrett5062’s picture

Issue summary: View changes

added 1834822

jessebeach’s picture

Status: Needs work » Needs review
FileSize
18.85 KB
95.89 KB

Fixed

  • Scrolling tray content in #272.
  • Tab weight issues in #273 and #276.
  • Page content collapsing under the tray too late in #277.
  • At one point webchick mentioned having the orientation of all the trays change when the orientation of one of the trays is toggled. That happens now in this patch.
  • I spruced up the theme_toolbar_trays function so that it can more easily be overridden by themers. Now with a proper preprocess function.
  • The JS file is commented up.
  • Incorporated system tests fixes from #1834822: Reestablish test coverage of the toolbar module that was disrupted by mobile update work.

What I'm working on next

  • Turning theme_toolbar_tray and toolbar.tpl.php into twig templates.
  • Addressing webchick's comment in #229 about not having the Shortcut and User trays go vertical if we can help it.
  • Finishing comment cleanup in toolbar.module.
  • Adding an icon sprite for UAs that don't support data uris as arguments to the CSS url() function.
  • Continuing to test on small devices.
  • Incorporating feedback.

Other dependencies

jessebeach’s picture

Issue summary: View changes

added 1839514

Shyamala’s picture

FileSize
33.84 KB

Tested at: http://toolbar.qemistry.us

  • Scrolling tray content in #272 - Not working, still get the scroll. See attached image. This is an issue only on admin/modules page.
  • Tab weight issues in #273 - FIXED. Order now: Home, Menu, Shortcuts, User
  • At one point webchick mentioned having the orientation of all the trays change when the orientation of one of the trays is toggled. That happens now in this patch. - FIXED
jessebeach’s picture

Fixed

  • Turned theme_toolbar_tray and toolbar.tpl.php into twig templates.
  • Finished comment cleanup in toolbar.module.

What I'm working on next

  • Scrolling tray content in #272.
  • Addressing webchick's comment in #229 about not having the Shortcut and User trays go vertical if we can help it.
  • Adding an icon sprite for UAs that don't support data uris as arguments to the CSS url() function.
  • Continuing to test on small devices.
  • Incorporating feedback.

Other dependencies

  • benjifisher is working on #1839514: Establish test coverage for toolbar module., the last hard dependency for this patch.
Fabianx’s picture

+++ b/core/modules/toolbar/templates/toolbar.twigundefined
@@ -1,28 +1,40 @@
+<div id="{{ attributes.id }}" class="{{ attributes.class }}" {{ attributes }}>

Little nit-pick:

To prevent double white-space in generated markup in Twig templates use:

class="{{ attributes.class }}"{{ attributes }}>

as {{ attributes }} automatically adds a white space before its output ...

That is a limitation / feature of the Attribute class.

jessebeach’s picture

Fixed

  • Refactored .toolbar-main to .toolbar-js
  • The overlay and stick table header placement was broken again. It's fixed now.
  • RTL styling now looks good.

What I'm working on next

  • Scrolling tray content in #272.
  • Addressing webchick's comment in #229 about not having the Shortcut and User trays go vertical if we can help it.
  • Adding an icon sprite for UAs that don't support data uris as arguments to the CSS url() function.
  • Continuing to test on small devices.
  • Incorporating feedback.

Other dependencies

jessebeach’s picture

Test RTL layout on the demo site.

http://toolbar.qemistry.us/he

eigentor’s picture

FileSize
106.67 KB
38.38 KB
37.84 KB

Tested on: Firefox, Galaxy Nexus Stock Browser Android 4.2 (Jelly Bean), First generation Droid Dolphin Browser on Gingerbread

Firefox:
Toolbar Firefox
In Firefox the arrow Buttons are not completely round, they look like cut off, though I could not find any box surrounding them that is so small as to cause this. The problem is not there on mobile Devices.

On all devices: the smaller arrow Buttons should be aligned center horizontally under the bigger button. This will look cleaner.
Alignment Arrow Buttons

Galaxy Nexus:
Toolbar Galaxy Nexus

Droid / Dolphin browser / stock Browser: no Icons visible at all, also not in the black toolbar.

On both Smartphones: the Droid renders as 320px width, the Nexus as 360px width, the Elements are too small. Visible on the above screenshot, the toolbar covers hardly more than half of the screen. While I can see this is caused by absolute pixel sizes, it is even too small on the Droid.
While the icons need absolute pixel sizes, the rows and columns do not. The text could also be bigger.

Shouldn't we use percentage values for the width of the vertical toolbar and the height of the rows? It feels like the current implementation is optimized for 240px width or tablets.

For Phones with 320px and above there should be a bigger version with another breakpoint for them.

While I find the issue serious, I can perfecly see it being adressed in a followup issue. The hard problems jessebeach is wrangling are harder to solve I guess. Only thing that should be tried is if percentage values create issues. Maybe it does not even need percentage values but more breakpoints. On Desktop browsers switching to vertical (whoever might do this) this needs a max-width of course. As there will be hardly a phone (maybe the Galaxy Note) rendering more than 360px there should not be too many breakpoints needed.

Shyamala’s picture

sun’s picture

Status: Needs review » Needs work

I did not apply this patch yet, so I did not have a chance to properly review the CSS and JS changes. I will follow up with that soon.

Regardless of that, I have a range of implementation concerns:

+++ b/core/misc/debounce.js
@@ -0,0 +1,28 @@
+/**
+ * Limits the invocations of a function in a given time frame.
+ *
+ * @param {Function} callback
+ *   The function to be invoked.
+ *
+ * @param {Number} wait
+ *   The time period within which the callback function should only be
+ *   invoked once. For example if the wait period is 250ms, then the callback
+ *   will only be called at most 4 times per second.
+ */
+Drupal.debounce = function (callback, wait) {

It is not clear to me why I would want to call a function in an uncontrolled fashion too often in the first place. I'm missing a concrete example here, and also a serious clarification in JSDoc that this is NOT how things are supposed to work by default; code that needs .debounce() has a systematic/architectural problem on its own and should be fixed in a way that does not rely on .debounce().

Essentially, this JSDoc reads like a "must-have" helper function and "yay-lets-use-that", but the reality is reversed. The language should be negated.

It should be documented very clearly that the most common cause for false-aggressive-invocations are wrongly chosen events and related stuff, and that .debounce() is and should be the very last resort only.

+++ b/core/modules/shortcut/shortcut.module
@@ -713,20 +713,9 @@ function shortcut_preprocess_page(&$variables) {
-function shortcut_toolbar_pre_render($toolbar) {
+function shortcut_toolbar() {

@@ -747,13 +734,30 @@ function shortcut_toolbar_pre_render($toolbar) {
+  $links_tray = array(
+    'shortcuts' => array(
+      '#type' => 'container',
...
+      'links' => $links,
+    ),
     'configure' => $configure_link,
   );
...
+  $items['shortcuts'] = array(
+    'tab' => array(
+      'title' => t('Shortcuts'),
+      'href' => 'admin/config/user-interface/shortcut',
...
+    ),
+    'tray' => $links_tray,
...
+  );
+  return $items;

The render array of hook_toolbar() looks very arbitrary to me and does not look acceptable.

Since it is no longer a #pre_render callback, I do not understand why the returned $items are keyed by an extra 'shortcuts' level. The calling code knows that returned $build belongs to Shortcut module already, since it implements hook_toolbar(), so there is no need to use custom keys.

Furthermore, I expect to see a more solid and fine-grained separation between actual toolbar items/links (or "tabs" as denoted here) and any child elements of it.

A closer look at the returned data structure reveals that some parts of it are structured data for theme_item_list(), whereas some other parts are render arrays. That's highly confusing, and the separation should be removed.

Due to that, I think this patch should be postponed on #891112: Replace theme_item_list()'s 'data' items with render elements.

+++ b/core/modules/shortcut/shortcut.theme-rtl.css
@@ -5,22 +5,6 @@
- * Toolbar.
- */

@@ -42,3 +26,16 @@
+/**
+ * Toolbar.
+ */
+.toolbar-js .horizontal #edit-shortcuts {

1) An ID selector as last drill-down makes little sense — why isn't .shortcuts a class?

2) Why was this moved down? The Toolbar-related styles are the primary forming styles.

+++ b/core/modules/shortcut/shortcut.theme-rtl.css
@@ -42,3 +26,16 @@
+  margin-left: 0;
+  margin-right: 0.3333em;
+  padding-left: 0.3333em;
+  padding-right: 0.6667em;

Is there are any chance to use reasonable units for these? (also for LTR) I can't see what kind of extraordinary impact the additional .0333 would have. Overly detailed units like this will be very hard to override elsewhere, and the layout/design should not depend on those fragments to work in the first place.

+++ b/core/modules/toolbar/config/toolbar.config.yml
@@ -0,0 +1,3 @@
+breakpoints:
+  - 'module.toolbar.narrow'
+  - 'module.toolbar.wide'

Potentially OT, depending on whether this is toolbar-specific code or a generic breakpoint module facility:

IF we reference to other config objects within a config object, then we need to make sure that we specify the full config object names — i.e., these values should be 'toolbar.breakpoints:narrow'

However, even that wouldn't be completely kosher; the config object name and the key within should really be separated into two different sub-keys.

+++ b/core/modules/toolbar/css/interactivemenu-rtl.css
@@ -0,0 +1,12 @@
+ * @file interactivemenu-rtl.css

+++ b/core/modules/toolbar/css/interactivemenu.css
@@ -0,0 +1,69 @@
+ * @file interactivemenu.css

These files need to be namespaced with "toolbar."

Let's also remove the "interactive" part; when is a menu not interactive? Just toolbar.menu.css.

+++ b/core/modules/toolbar/css/toolbar.base.css
@@ -0,0 +1,186 @@
+.toolbar-js,
+.toolbar-js * {

I do not think these are sufficient to ensure a proper, theme-agnostic styling. We should use at least an ID selector here, ideally further enforced by additional specificity; i.e.:

html body #toolbar

I also can't see why this is a class in the first place; there can and there should be only one toolbar on a single page.

+++ b/core/modules/toolbar/css/toolbar.base.css
@@ -0,0 +1,186 @@
+.toolbar-js .bar {

A "bar" in a "toolbar" doesn't sound like a well formed class name.

The same applies to .lining and .edge.

+++ b/core/modules/toolbar/css/toolbar.base.css
@@ -0,0 +1,186 @@
+/**
+ * ToolBar icons.
+ */
+.toolbar-js .bar .tab,
+.toolbar-js .bar .active .tab,
+.toolbar-js .bar .tab:active,
+.toolbar-js .level-1 > .box > a {

+++ b/core/modules/toolbar/css/toolbar.icons.css
@@ -0,0 +1,84 @@
+  .toolbar-js .bar .tab,
+  .toolbar-js .bar .active .tab,
+  .toolbar-js .bar .tab:active,
+  .toolbar-js .level-1 > .box > a {
+    background-size: 1.75em 1.75em;
+  }

These selectors will cause false-positive matches.

We need to use proper .icon[-type]:before classes instead.

I will not accept this patch until the icons are implemented properly. We will not re-invent the wheel. There's a clear and common standard for implementing icons on the web today, we just need to implement and adopt it.

+++ b/core/modules/toolbar/css/toolbar.base.css
@@ -0,0 +1,186 @@
+/**
+ * ToolBar tray orientation toggle.
+ */
+.toolbar-js .toggle-orientation {

I think this should be removed from the initial implementation.

Controls to adjust configuration should not be permanently exposed in the user interface.

+++ b/core/modules/toolbar/css/toolbar.icons.css
@@ -0,0 +1,84 @@
+  .toolbar-js #toolbar-link-admin-content {
+    background-image: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjwhLS0gR2VuZXJhdG9yOiBBZG9iZSBJbGx1c3RyYXRvciAxNi4wLjAsIFNWRyBFeHBvcnQgUGx1Zy1JbiAuIFNWRyBWZXJzaW9uOiA2LjAwIEJ1aWxkIDApICAtLT4NCjwhRE9DVFlQRSBzdmcgUFVCTElDICItLy9XM0MvL0RURCBTVkcgMS4xLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL0dyYXBoaWNzL1NWRy8xLjEvRFREL3N2ZzExLmR0ZCI+DQo8c3ZnIHZlcnNpb249IjEuMSIgaWQ9IkxheWVyXzEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHg9IjBweCIgeT0iMHB4Ig0KCSB3aWR0aD0iMTAwcHgiIGhlaWdodD0iMTAwcHgiIHZpZXdCb3g9IjAgMCAxMDAgMTAwIiBlbmFibGUtYmFja2dyb3VuZD0ibmV3IDAgMCAxMDAgMTAwIiB4bWw6c3BhY2U9InByZXNlcnZlIj4NCjxwYXRoIGZpbGw9IiM3Nzc3NzciIGQ9Ik02NC4wNjYsMGwyNi45NjksMjcuNjMxVjEwMEg4Ljk2NVYwSDY0LjA2NnogTTIwLjgwOSw4OC4xNTZoNTguMzl2LTU2LjU4SDU3Ljk3OVYxMS44NDFIMjAuODA5Vjg4LjE1NnoNCgkgTTI4Ljg2Nyw0OS41MDRoNDEuNzc3di00LjYwNUgyOC44NjdWNDkuNTA0eiBNMjguODY3LDYyLjY2NWg0MS43Nzd2LTQuNjA0SDI4Ljg2N1Y2Mi42NjV6IE0yOC44NjcsNzUuODE4aDQxLjc3N3YtNC42MDVIMjguODY3DQoJVjc1LjgxOHoiLz4NCjwvc3ZnPg0K);
+  }

+++ b/core/modules/user/user.css
@@ -88,3 +87,14 @@ div.password-suggestions ul {
+.toolbar-js .user .tab:active,
+.toolbar-js .user.active .tab {
+  background-image: url(data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjwhLS0gR2VuZXJhdG9yOiBBZG9iZSBJbGx1c3RyYXRvciAxNi4wLjAsIFNWRyBFeHBvcnQgUGx1Zy1JbiAuIFNWRyBWZXJzaW9uOiA2LjAwIEJ1aWxkIDApICAtLT4NCjwhRE9DVFlQRSBzdmcgUFVCTElDICItLy9XM0MvL0RURCBTVkcgMS4xLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL0dyYXBoaWNzL1NWRy8xLjEvRFREL3N2ZzExLmR0ZCI+DQo8c3ZnIHZlcnNpb249IjEuMSIgaWQ9IkxheWVyXzEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIHg9IjBweCIgeT0iMHB4Ig0KCSB3aWR0aD0iMTAwcHgiIGhlaWdodD0iMTAwcHgiIHZpZXdCb3g9IjAgMCAxMDAgMTAwIiBlbmFibGUtYmFja2dyb3VuZD0ibmV3IDAgMCAxMDAgMTAwIiB4bWw6c3BhY2U9InByZXNlcnZlIj4NCjxsaW5lYXJHcmFkaWVudCBpZD0iU1ZHSURfMV8iIGdyYWRpZW50VW5pdHM9InVzZXJTcGFjZU9uVXNlIiB4MT0iNTAiIHkxPSI5Ni45MjI5IiB4Mj0iNTAiIHkyPSIxMi4xMTI2IiBncmFkaWVudFRyYW5zZm9ybT0ibWF0cml4KDEgMCAwIC0xIDAgMTAxKSI+DQoJPHN0b3AgIG9mZnNldD0iMCIgc3R5bGU9InN0b3AtY29sb3I6I0ZGRkZGRiIvPg0KCTxzdG9wICBvZmZzZXQ9IjAuOTkwMSIgc3R5bGU9InN0b3AtY29sb3I6I0U1RTVFNSIvPg0KPC9saW5lYXJHcmFkaWVudD4NCjxwYXRoIGZpbGw9InVybCgjU1ZHSURfMV8pIiBkPSJNMjguNDI0LDI3LjY1M2MwLDExLjk2Myw5LjY1MywyMS42NTMsMjEuNTc2LDIxLjY1M2MxMS45MjIsMCwyMS41NzQtOS42OSwyMS41NzQtMjEuNjUzDQoJQzcxLjU3NCwxNS42OTIsNjEuOTIyLDYsNTAsNkMzOC4wNzcsNiwyOC40MjQsMTUuNjkyLDI4LjQyNCwyNy42NTN6IE0xMDAsOTAuNjE1YzAtMjAuMzQ2LTEuMTE1LTM1LjQyNC01MC0zNS40MjQNCgljLTQ4LjgwOCwwLTUwLDE0LjMwOC01MCwzNS40MjRIMTAweiIvPg0KPC9zdmc+DQo=);
+}

I am really not comfortable with adding these hard-coded SVG images in the CSS like this. We already know that sprite images are almost impossible to properly maintain in core; plenty of contributors and improvements got entirely stuck on the question of how to update the sprite images.

This hard-coding here moves that maintenance problem to an entirely new dimension and makes it even worse than the sprite images have been.

Furthermore, this will be a pain to override and customize in themes.

Can we pretty please replace all of these with simple URLs to the respective image files?

And instead of hard-coding this here, work on a generic solution that allows us to automatically embed certain URIs in CSS files as data streams during CSS preprocessing? A simple solution should be a matter of minutes to implement.

(e.g., a simple CSS comment à la /* @data */, perhaps even on a per-file level; i.e., if that flag is found anywhere in a CSS file during preprocessing, all url()s will be converted into embedded data.)

+++ b/core/modules/toolbar/css/toolbar.theme.css
@@ -0,0 +1,224 @@
+.toolbar-js {

I do not understand why this class is suffixed with "-js" all over the place. Why does the entire styling depend on JavaScript?

If that is really the case, then this is fundamentally wrong, as it does not adhere to the essential separation of behavior vs. presentation concerns.

+++ b/core/modules/toolbar/css/toolbar.theme.css
@@ -0,0 +1,224 @@
+.toolbar-js .level-2 li {
...
+.toolbar-js .level-3 a {
...
+.toolbar-js .level-4 a {
...
+.toolbar-js .level-5 a {
...
+.toolbar-js .level-6 a {
...
+.toolbar-js .level-7 a {
...
+.toolbar-js .level-8 a {
...
+.toolbar-js .level-9 a {
...
+.toolbar-js .level-2 > ul {
...
+.toolbar-js .level-3 > ul {
...
+.toolbar-js .level-4 > ul {
...
+.toolbar-js .level-5 > ul {
...
+.toolbar-js .level-6 > ul {
...
+.toolbar-js .level-7 > ul {
...
+.toolbar-js .level-8 > ul {
...
+.toolbar-js .level-9 > ul {

The individual level classes should be removed entirely.

I also do not understand why this is changing colors of deeper levels in the first place. This will lead to contrast problems in themes. It should be removed.

+++ b/core/modules/toolbar/css/toolbar.theme.css
--- /dev/null
+++ b/core/modules/toolbar/js/interactivemenu.js

+++ b/core/modules/toolbar/js/interactivemenu.js
@@ -0,0 +1,129 @@
+  $.fn.interactiveMenu = function () {

This file needs to be properly namespaced and renamed to toolbar.menu.js.

Likewise, the jQuery plugin function name should be namespaced, too.

Contributed module + theme authors will look at files throughout core, and if they would follow this lead here, we'd end up in ultimate namespace rotten.

+++ b/core/modules/toolbar/templates/toolbar.twig
@@ -0,0 +1,40 @@
+ * Default template for admin toolbar.

I don't see what the point of this theme template is... this is very specific markup, which one cannot really override in the first place — if anyone would attempt to do that, he/she'd have to re-implement the entire JS and CSS, too, in which case you hit the point at which you shouldn't override it in the first place and simply implement your own toolbar instead.

+++ b/core/modules/toolbar/toolbar.info
@@ -3,3 +3,8 @@ description = Provides a toolbar that shows the top-level administration menu it
+dependencies[] = config

Obsolete.

+++ b/core/modules/toolbar/toolbar.module
@@ -174,98 +115,149 @@ function toolbar_preprocess_toolbar(&$variables) {
+    '#heading' => array('text' => t('Drupal toolbar'), 'level' => 'h2', 'class' => 'element-invisible'),

"Drupal" should be removed.

+++ b/core/modules/toolbar/toolbar.module
@@ -174,98 +115,149 @@ function toolbar_preprocess_toolbar(&$variables) {
+  foreach ($toolbar_groups as $category => $items) {
+    if ($tab = $items['tab']) {

This code is very inconsistent in terminology. Are the "tabs" supposed to be "categories"? And why do we expect "tabs" to be "tabs" in the first place?

+++ b/core/modules/toolbar/toolbar.module
@@ -174,98 +115,149 @@ function toolbar_preprocess_toolbar(&$variables) {
+      // Log a warning if the tab is already defined.
+      if (array_key_exists($category, $build['tabs']['#links'])) {
+        watchdog('toolbar', 'Toolbar tab %category is already defined.',
+          array('%category' => $category)
+        );
+      }

This logging should be removed. The code needs to ensure that such clashes are not possible in the first place; i.e., by properly namespacing all "tabs".

+++ b/core/modules/toolbar/toolbar.module
@@ -280,14 +272,13 @@ function toolbar_get_menu_tree() {
-    $tree = menu_build_tree('admin', array(
-      'expanded' => array($admin_link['mlid']),
-      'min_depth' => $admin_link['depth'] + 1,
-      'max_depth' => $admin_link['depth'] + 1,
-    ));
+    $tree = menu_tree_all_data('admin');
...
+  // Return the sub-menus of the admin menu root.
+  foreach ($tree as $key => $menu) {
+    return (!empty($tree[$key]['below'])) ? $tree[$key]['below'] : array();
+  }

1) This needs to load the proper menu tree of/below the /admin path.

2) What happened to the partial menu tree loading?

I might be able to help to get this code in shape, but I can't make promises.

jessebeach’s picture

sun, thank you for the extensive review. I'm working through your comments now. I'll have an updated patch soon. Let's look through it once I've got your initial thoughts addressed.

jessebeach’s picture

Issue summary: View changes

Added link to #1839514, see comment #280.

jessebeach’s picture

Status: Needs work » Needs review
FileSize
104.81 KB
95.79 KB
32.97 KB
28.23 KB

Issues addressed in this patch

  • Updated the JSDoc on debounce.js to provide more caution and guidance.
  • Removed .toolbar-js scoping class and replaced sparsely with .js. The intent of scoping to .js is to prevent position of the toolbar at the top of the page when JS isn't available.
  • Properly namespaced the interactivemenu plugin to toolbarMenu.
  • Refactored the icon handling in the CSS to the use the :before method recommended by sun. Refactored the RTL styling due to these changes.
  • Removed embedded data URIs for background images.
  • Removed dependencies[] = config from toolbar.info
  • Changed $category to $group in e.g. foreach ($toolbar_groups as $category => $items) { in toolbar.module#template_preprocess_toolbar.
  • Removed the call to watchdog in toolbar.module#template_preprocess_toolbar.

Issues I could use guidance on

In regards to toolbar_get_menu_tree, I could use any insights you might have here.

+++ b/core/modules/toolbar/toolbar.module
@@ -280,14 +272,13 @@ function toolbar_get_menu_tree() {
-    $tree = menu_build_tree('admin', array(
-      'expanded' => array($admin_link['mlid']),
-      'min_depth' => $admin_link['depth'] + 1,
-      'max_depth' => $admin_link['depth'] + 1,
-    ));
+    $tree = menu_tree_all_data('admin');
...
+  // Return the sub-menus of the admin menu root.
+  foreach ($tree as $key => $menu) {
+    return (!empty($tree[$key]['below'])) ? $tree[$key]['below'] : array();
+  }

1) This needs to load the proper menu tree of/below the /admin path.

2) What happened to the partial menu tree loading?

sun, I'm not sure that we want partial menu tree loading, but the full menu. I know you've done work already to include blocks for menus rather than calling up the menu from the DB like Toolbar has done and continues to do. What do you think of that approach here?

hook_toolbar, as sun noted, could use some refactoring. What we're trying to do is provide a means for a developer to return N links that get render to the toolbar tabs and N trays, each one associated with a tab. Tabs may exist without a tray but a tray cannot be controlled with a tab. So, because a module can return N tabs/trays, each trab/tray needs to be located under a renderable array key, that array key being the ID that gets surfaced in the HTML as the identifying term to attach behaviors to and associate the tab with the appropriate tray. I'm definitely open to suggestions on formatting the hook internals and the HTML here. I'll also see tomorrow how the HTML structures holds up under the scrutiny of an accessibility review tomorrow at the Toronto Accessibility Camp.

It was my impression that the Twig team wants to move many if not all theme functions (within reason) to twig template files. I'm just following that pattern here. Whether or not one will ever override it, it simply follows the emerging practice as I understand it.

+++ b/core/modules/toolbar/config/toolbar.config.yml
@@ -0,0 +1,3 @@
+breakpoints:
+  - 'module.toolbar.narrow'
+  - 'module.toolbar.wide'

I'm not up to speed on the latest configuration syntax. I consulted with heyrocker on the config file formatting you bring up in #288. If you know how this code should be formatted just let me know and I'll change it. I've heard rumors of single vs. multi-dot issues and it's not clear to me how to proceed here. I don't think we're trying to do anything fancy with config here. I just need a few key/value pairs, no nesting or complex data structures.

The toggle configuration is not meant to be something you change once and never touch again. I find that I'm constantly changing from horizontal to vertical depending on my task and screen size. It's meant to be a quick, cheap and ephemeral setting that one can access quickly.

Regarding the per-level coloring in the menu, here's a screenshot of nine-levels of menu with the coloring:

9-levels-with-coloring.png

And a screenshot without. I'll bring up with Kevin with contrast issue, although I know he ran the colors through contrast testing and they came out fine. I'm agnostic on the issue.

9-levels-without-coloring.png

What we're working on next

Possible follow-ups from these changes

  • If sun has time, he could implement the data URI converter for CSS images he mentions in #288.
  • If this does not come to pass by feature freeze, I will add a follow-on task to sprite the images in the toolbar so we don't have numerous single images loading on each admin page load.
danillonunes’s picture

FileSize
2.53 KB
2.56 KB

Can we switch the position of the toggles? The fact that the "put the thing on the left" link is in the right is bugging my brain...

bad.png
Bad

good.png
Good

jessebeach’s picture

@danillonunes as soon as you mentioned this, I realized I'd been struggling with this as well! Excellent point. I've switched the positioning locally. It'll be in the next patch.

jessebeach’s picture

Issue summary: View changes

Revert my previous edit (which the system credits to jessebeach). I did not notice that #1839514 was already on the list of post-code-freeze tasks.

jessebeach’s picture

This patch incorporates feedback from the Drupalcamp Toronto Accessibility sprint.

Issues addressed in this patch

  • #toolbar is now a <nav> element instead of each tray being <nav> element. The trays are now divs.
  • No accessibility related, but #291 from danillonunes is in this patch.
  • The toolbar is moved from page_bottom to page_top so that a logical tabbing is maintained.
  • The tabs now have aria-pressed applied only if it has a tray associated with it.
  • The tabs now have aria-owns applied that denotes the associated tray.
  • The tabs now have role="button" applied only if the tab has a tray associated with it.
  • Each tray now has a heading. The heading is created automatically unless the module that implements hook_toolbar provides one.
  • The trays now have aria-owned-by applied and it denotes the controlling tab.
  • The expand/collapse buttons on the nested menu widget (toolbar.menu.js) now have the button content "[Expand | Collapse] {item-label}" e.g. "Expand Structure".
  • The expand/collapse buttons now are located after the menu item instead of before it in the DOM.
  • The .edge element is removed from the template in favor of .lining:before.

Issues that still need to be addressed

We have two in particular, neither are blockers according to Everett, but both will be major. I will log them as issues once I get back to Boston (leaving for a flight in 10 minutes).

  • We need a Drupal.setMessage API for front end that posts messages to an element with the "live" role to announce when trays are opened or closed among other changes to the UI.
  • The text on the orientation toggle to explain the horizontal vs. vertical orientation makes no sense outside of a sighted experience. The text on this configuration toggle needs to explain the orientation in terms of simplex/complex experience, since a horizontal bar will most likely hold fewer actions than the vertical bar. I'll explain more in the issue I file.

Great sprint everyone! We made great progress.

Bojhan’s picture

This is an awesome update, really happy we got major accessibility issues resolved. Is there any ETA on what this needs to move forward towards RTBC, e.g. when its iteration that can be done post commit.

MustangGB’s picture

#291 & #292: Regarding the toggle buttons, if there are only two states (horizontal and vertical) why do we need two separate buttons. A single button that actually toggles would be much more intuitive. At least I've been struggling to remember which one to click.

jessebeach’s picture

@akamustang, great feedback. We're making that change now. Will be included in a near-term patch.

@Bojhan, I want to put in a couple unit tests. That's my priority today. Once those are in a patch, I'd like to start talking about committing this patch. We'll have a known set of follow ups and we're committed on the Spark team to addressing them.

jessebeach’s picture

I mentioned in #293 a generic client-side messaging system. Rather than wait for something to be implemented under the Drupal object, I put a simple implementation in the Toolbar module to prove out the concept. @Everett Zufelt, can you give it a spin and let me know if the behavior and messaging needs any tweaking? If you don't have a speaking UA, you can install ChromeVox and quickly get a sense of navigating the Toolbar through an aural interface.

https://chrome.google.com/webstore/detail/chromevox/kgejglhpjiefppelpmlj...

There was also a small bug in the maintenance of the orientation state that I fixed.

Looking ahead, I'm writing a couple unit tests today and addressing the styling of the orientation links.

We're marching towards commit everyone!!. Sure, there are several improvement we'd like to make, but on the whole, I think we've all come together and designed/built a phenomenal improvement to Drupal here. Let's get it in and the continue to make it better.

webchick’s picture

Priority: Major » Critical

We're over thresholds for major bugs, so I'm moving this back to critical, because honestly. We can not ship Drupal 8 without this being fixed.

mbrett5062’s picture

FileSize
81.12 KB
80.34 KB
90.38 KB

This looks better and better. Love the work you are doing.

Some very minor nitpicks, that can probably be handled as follow ups.

The breakpoint were the text goes from the toolbar, leaving only icons. Either should come earlier or the text needs to be smaller.
Currently the text and icon wrap before text disappears. Just a very narrow window of change. But disconcerting none the less.

text size

On Firefox 16.0.2 the icons for down arrows still look ugly. The edges being cut off.

Ugly FF

I find that simply removing background-size: 100% auto; fixes in FF and has no effect on Chrome and IE10. In fact IE10 ignores that and all other background CSS is blanked out anyway, probably overridden by UA styles.

Pretty FF

benjifisher’s picture

Why doesn't CSS give us an option "font-size=make-it-fit"?

We may have to worry about how "Home," "Menu", and "Shortcuts" will be translated. As for user names, note this excerpt from the User module:

function template_preprocess_username(&$variables) {
  // ...

  // Set the name to a formatted name that is safe for printing and
  // that won't break tables by being too long. Keep an unshortened,
  // unsanitized version, in case other preprocess functions want to implement
  // their own shortening logic or add markup. If they do so, they must ensure
  // that $variables['name'] is safe for printing.
  $name = $variables['name_raw'] = user_format_name($account);
  if (drupal_strlen($name) > 20) {
    $name = drupal_substr($name, 0, 15) . '...';
  }
  $variables['name'] = check_plain($name);
jessebeach’s picture

Welcome to the 300s!

Issues addressed in this patch

  • Added a unit test to exercise hook_toolbar
  • Addressed the breakpoing placement that drops the bar tabs to icons in #299 by mbrett5062. I moved the breakpoint from 28.125em to 36em.
  • Updated toolbar.api.php
  • Turned the orientation toggle into a single icon and added a11y messaging for the orientation change. Mentioned by akamustang in #295.

Issues that still need to be addressed

  • Some styles are busted in IE8 due to them being buried in @media queries. This hadn't been broken, so I just need to do another round of verification and fix regressions.
  • @effulgentsia is actively working on integrating the patch from #1814932: Caching strategy for D8 toolbar. That should be rolled into this issue tonight.

Status: Needs review » Needs work

The last submitted patch, 1137920_responsive-toolbar_301.patch, failed testing.

jessebeach’s picture

Status: Needs work » Needs review
FileSize
12.1 KB
113.28 KB

This patch starts the march to RTBC. We've satisfied the pre code freeze tasks (see the issue summary). Any other tasks, if not a blocker, will be added to the post code freeze list.

Issue addressed in this patch

Remaining tasks

Curate the post feature freeze task list. Individual device rendering irregularities will be dealt with on an issue basis from this point forward.

Testing

I will have updated http://toolbar.qemist.us within moments of posting this comment.

Please clear your browser cache before testing in earnest. We've had people get older versions of toolbar.js and that's no fun.

Final note

I know this is a mammoth issue and getting involved now may seem daunting. Rest assured I understand this. Even still, your input will be valuable. If you miss some point that was already made 150 comments back, I will not blow up; I'l simply point out if a comment has been addressed or if we decided to postpone the issue. Please feel empowered to jump in and start testing. This is going to be your toolbar and it should work in a way that makes administering a Drupal site feel effortless and fun.

If you find issues, let them be known here in a comment. Critical/blocking issues will be addressed immediately. Major/normal/minor issues will be noted in followup issues. Please checking the followup issues in the summary above to determine if your findings/observations have already been noted. Adding another comment to an already observed issue is encouraged since it adds weight or additional detail.

Status: Needs review » Needs work

The last submitted patch, 1137920_responsive-toolbar_303.patch, failed testing.

jessebeach’s picture

Status: Needs work » Needs review
FileSize
113.31 KB

Rebased #303 on 465d86e2ec17725ba01c508f51d850357273104b.

Shyamala’s picture

The test site URL is having a typo in comment #303. Please use: http://toolbar.qemistry.us/

geerlingguy’s picture

I've been following this issue since about #100, and I have to say the patch has improved tremendously since that time. I didn't give a thorough code review, but I tested on iPad, iPhone and Chrome at least (don't have time to do IE or other browsers right now), and this version of the patch is working exceptionally well.

I have to say, this navigation scheme is actually best-in-class compared to most other solutions I've used/seen. Kudos to jessebeach for rerolling and refining constantly, and kudos to everyone else giving extremely detailed and helpful reviews. There are always going to be a few small issues with such a major overhaul, but this menu/toolbar system will probably be one of the most convenient and helpful new features in Drupal 8, though it won't get as much praise as some of the other huge architecture changes :)

This is one of those issues where I think the number of comments has actually made the end product (hopefully committed soon) polished and awesome, without (hopefully) wearing down the developers behind the patch.

I would RTBC, but I think someone should make sure everything's working great in IE, and finish giving a good review to the JS (I avoided looking at that much).

Shyamala’s picture

Did some testing on iphone. The UI islovely and the toggle between the vertical & horizontal mode is lovely. Attached images of pages where there are minor alignment issues of ipad.

Shyamala’s picture

Tested on IE8. Issues recorded:

  1. Toggled to horizontal mode and could not Toggle back to the vertical mode
  2. On clicking any menu the horizontal bar was not sticky, disappeared. Not sure this is how it is intended to behave on IE8
  3. In the vertical mode the Menu was a drop down and not a sticky vertical bar: not sure if this is expected behaviour on IE8
Shyamala’s picture

FileSize
100.31 KB

Attaching image for lost toggle in horizontal mode in IE 8

Shyamala’s picture

Attaching image for lost toggle in horizontal mode in IE 8

Lost toggle to vertical mode

jessebeach’s picture

Shyamala, did you get the toolbar tray into a vertical orientation by toggling to vertical in IE9 or IE10, then switching to IE8?

The default orientation is horizontal. The vertical orientation occurs in two ways: directly toggling to it, or smushing the screen to a narrow width when the CSS in the @media queries for small screens kicks in. IE8 doesn't recognize these media queries, so it won't toggle to vertical orientation through CSS. Given that, I made the assumption that one shouldn't be able to toggle to vertical in IE8 either. I put the toggle to get to horizontal as a kind of steam valve for the case that I'm guessing you ran into -- testing in IE9/10 and switching back to IE8 with the developer tools. Someone using IE8 should never know that the toggle is even available.

This line of thinking might be off. I will say that getting the side tray to look even halfway decent in IE8 took a lot of time. Getting it to be visually equivalent to the IE9/10 vertical orientation styling would probably require browser-targeted CSS, which we won't do in Drupal 8.

I hope that wasn't a too-long winded explanation!

David_Rothstein’s picture

Hoping to do a more complete (and balanced) review at some point, but I noticed a couple big things:

  1. The removal of the prominent "Add content" link is troubling. (See http://vimeo.com/6995667#t=530 for what happened in previous versions of Drupal where the link was hard to find, and in that case it was at least still in plain sight on every page.) I don't think it's a huge exaggeration to say that adding this link at the top of every page in a prominent place in the toolbar was the biggest usability improvement in Drupal 7, and I'm not at all convinced that beginning users will ever find it underneath something called "Shortcuts" if we hide it there in Drupal 8 (though they may eventually find it other places). Also, this means we're adding one extra click for a very common task.

    Many of the mockups in this issue showed "Add" as a separate dropdown menu on the top level, but that's not implemented currently. I think something along those lines could probably solve this, though I'm not clear how it works given that "Add content" is itself a landing page.

  2. As far as I could tell, this patch still doesn't work with the overlay at all, because when the toolbar is open in the vertical orientation, opening the overlay completely covers up the toolbar drawer so you can't click on anything in it again until the overlay is closed.

Impressive work in general, though! (I disagree with this being classified as a critical bug, by the way, but will save that for some point when we're actually over 15 critical bugs and it matters :)

Shyamala’s picture

Hi Jesse,

I used an IE8 only machine. Not sure how I got the vertical drop down, not able to replicate it, in any case.
I will have this tested in a couple of more machines on IE8 during the course of the day to confirm the same.

dasjo’s picture

i have just tested http://toolbar.qemistry.us/

on chrome on mac it works just fine.
on chrome / android the toolbar buttons appear but they are just buttons that don't seem to add the javascript-driven toolbar dropdowns but just link to the administration sub-pages.

edit: it works on the standard browser of the same android device (nexus s, cm10), but doesn't on the chrome app.

Shyamala’s picture

FileSize
29.27 KB

Replicated issue with IE8 on a new machine, where this site was not previously accessed.
Attached image. Replicated issue by clearing cache.

mbrett5062’s picture

@jessebeach, could I make a suggestion that I would hope gets this through the final gate.

This issue is now over 300 and is too long. I think, from having followed this for a long time, that it is now agreed by more then 80% of the people following along that the design and implementation is as quoted from issue summary "I can live with this".
And in fact AFAIAC it is way better then that. Excellent, excellent work.

So my suggestion is that we close out this issue and open a new one with a link back here.
The new issue summary will state what you have achieved, and that there is only one critical blocker that should be chased down vigorously.
Then call for 1 week of PHP/JS/CSS code review, plus documentation review, to get this over the final hurdle and get RTBC. No more detailed cross platform/browser reviews until after feature freeze. This will leave 3 days for anything else to pop up before final commit.

Not trying to derail or shift focus, just trying to bring under the microscope the final reviews required to achieve the stated goals of the current issue summary.

gmclelland’s picture

@jessebeach

How about removing the underlines on the top level links in the black bar? To me it is confusing because I tend to think if the link is underlined then it will direct me to that page instead of just opening the drawer.

Dries’s picture

Great job, Jesse and everyone! This is looking great.

I would like to commit this tomorrow at noon EST. #313.2 is a critical regression, so I'd like that fixed by then if possible. If not, I'll decide tomorrow whether to commit it anyway and allow it to be a critical follow up. #313.1 can be a major follow up. Please update the issue summary with all other follow ups that need to be tracked.

It's also great to see all of the feedback on specific devices/browsers. Looks like all the big issues there have been fixed, but let's make sure to capture what remains in follow-ups as well.

I understand there are some DX concerns around some of the components of this patch, such as hook_toolbar(). I'm comfortable addressing those after feature freeze, as long as it's early on.

webchick’s picture

Status: Needs review » Reviewed & tested by the community

YAY!!!! :D

In light of #319, marking RTBC to give people a chance to chime in here before commit.

Bojhan’s picture

@David_Rothstein You are right that we are regressing around "create content", I am not sure if its a really an issue though - people found it in loads of places other than the shortcut bar. We haven't really user tested the horizontal toolbar, so we have little data on it :( - hopefully that will come.

I am sad that we are introducing two UI models for the desktop, it creates friction between the horizontal vs. vertical advocates and will result in loads of discussion in the end. It is the result of us not making a decision, what is best and leaving it up to the user. However for now, I am in the "I can live with this" camp as horizontal is the default and we really need to get this fundamental mobile support in.

effulgentsia’s picture

According to #293, this has been accessibility reviewed, so removing that tag. Thank you to all the Toronto sprinters!

jessebeach’s picture

Shyamala, thanks for sticking with the IE8 testing re: vertical vs. horizontal. I figured out what was causing the toolbar to display vertically by default in IE8 and have corrected locally. It should now be impossible to get the toolbar in a vertical orientation on devices that don't understand media queries.

I'm looking at #313.2. Here are my thoughts.

On a narrow screen with the toolbar in a vertical orientation, if we compress the overlay to fit in the space left over by the toolbar, we could end up squeezing the overlay into a 400px wide space. Currently, the toolbar doesn't play well in a 400px wide space.

I wrote a patch (needs a reroll) that makes the overlay display reasonably well in a narrow space. It's listed in this issue as a followup:

#1829326: Convert Overlay to leverage core breakpoints and media queries to determine its presence and styling

I hid the toolbar behind the overlay when it's vertical and the overlay is open in order to provide maximum width of the overlay. It's not a regression so much as it's a bad compromise for a tricky situation.

I'll put together an alternative patch that squishes the overlay into the remainder space with the toolbar is fully unfurled and we can decide if we like it.

aspilicious’s picture

With this patch and with the restyled action button in core "seven" looks very strange as an admin theme. We desperatly need to tweak the seven styling a bit after feature freeze. I also remember an issue with some realy nice 7 mockups/designs that would fit with this toolbar. (@Bojhan got a link?)

I have a small problem with the short time span between rtbc and possible commit on this patch. Certainly when there are other patches that are rtbc for a couple of days that need to get in before feature freeze and that are blocking other patches that also need to get in soon.

Bojhan’s picture

@aspilicious You mean the ones in #1510532: [META] Implement the new create content page design? Yhea we will need to do some visual design clean up in code freeze, as we let different styles into core.

jessebeach’s picture

Issues addressed in this updated

  • Addressed the IE8 issue that Shyamala brought up in #309.
  • Toned down the colors of the menu items past the second level according to Kevin's designs.
  • Fixed a z-indexing issue with the contextual links gears.
  • Fixed the active icons of the bar tabs. The active background images weren't showing.
  • Made toolbar.js a touch more efficient by changing the orientation only once per page load instead of a possible two times if the tray is overridden to a vertical orientation.
  • Updated active menu item trail styling. This still needs more work. I will log and issue, link it here and describe what needs to be done.

Toolbar and Overlay in #313.2

I tried several approaches to dealing with the toolbar and overlay interaction and came up with nothing I felt was better than that stop-gap measure in the current patch. To solve this layout problem between the two modules, we'll need to open up Toolbar and Overlay a bit. I'd rather not do that in a patch that's already quite full and reviewed. This issue will also need to be addressed. #787940: Generic approach for position:fixed elements like Toolbar, tableHeader

I will attach a followup in the issue summary.

sun’s picture

Thanks @jessebeach for working so hard on this.

I didn't review the latest patch/code (because an issue ends for me as soon as there is a pager), but @jessebeach stated that some of the issues have been addressed.

I still have a range of issues with this; some of them can be considered pretty major, and some seem to question fundamental design aspects, but if you are open and down with potentially doing major changes and refactoring in follow-up issues, then I'm also down with that and happy to move forward here.

- The toolbar is too large and consumes too much vertical height on desktop (in horizontal orientation; with and without opened tray).

- I do not understand why the vertical orientation gets the benefit of sub-menu-trees but the horizontal orientation does not. This means I still have to install and use admin_menu for no good reason.

- I find it very confusing that clicking some of the tabs immediately issues a request to another page, whereas some other tabs do not and only open a tray.

- The structure and API of hook_toolbar() is not very optimal and cannot really be re-used by other modules (such as admin or admin_menu).

- I do not understand why the top-level tabs can only be links and not something else; e.g., more sophisticated widgets; this artificially limits possibilities.

- I need to study @eff's code for the client-side HTTP caching of sub-menu-trees and see what the differences to admin_menu's implementation are; it is probably noteworthy that there is a range of users for which the caching critically breaks their sites, which seems to depend on yet unknown server/platform/client/environment details (all they see are many scrambled characters on the screen).

- Most of (or even the entire?) toolbar's functionality depends on JavaScript, whereas large parts of it should be able to work without JS and pure CSS only.

- The presentation of the menu in vertical orientation looks very strange to me, especially the expanded sub-menus. Using that interface feels "unnatural" to me (it's hard to express this in written words). I've the impression that the interface/interaction elements are not oriented in a natural way and the interface makes me think before clicking anywhere. I think the interface, interaction, look, and feel of the vertical orientation needs to be redesigned.

- We need to make sure that it is easy and possible to override the (entire) appearance/styling of the toolbar.

What I'm essentially after is that people should either no longer have to download and install admin_menu for D8, or alternatively, that admin_menu can at least re-use the backend APIs of Toolbar and does not have to re-invent the wheel.

I'm open to try to help with these, if you're open to perform major changes in follow-up issues.

Again, thanks for your hard work on this, @jessebeach! :)

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review

I'm gonna say 16 KB of new changes makes this "needs review" still :) No need to rush this.

Also, I'm a little concerned that with #313 we're going to have two critical followups (or maybe one major and one critical, guess it depends on your point of view) without even a clear idea for how to fix them.

So in short:

  1. Can we agree that we're going to have to add something like an "Add" link at the top of the toolbar (and pull "Add content" out of shortcuts)? There are actually two possibilities: (1) Just a simple "Add content" link directly, (2) An "Add" menu, with "Content" as the only child. The second is more flexible for other modules which want to add other entities there, but is going to look weird when only "Content" is in it. This needs some discussion.
  2. For the overlay, can we agree that we're going to have to do whatever it takes to squish it horizontally? I can't think of any other way.
webchick’s picture

No... For Overlay, I think I'd just force horizontal orientation. We already hide the Overlay on smaller screen sizes, where we also force vertical orientation. To me this is not really that big of a deal.

This patch has been in progress for 3 months. The issue is now > 300 comments. I don't think we're going to make significant progress in further improving this before it's in core, and 100s of people (rather than 10s of people) can touch it, feel it, play with it, and also help develop improvements around it.

EDIT: oh, and adding a Content menu as per the northstars can be one of them. :)

Dries’s picture

Status: Needs review » Fixed

- David: We'll work on a solution for how to deal with overlays. I think @webchick is right that we may want to disable the overlay for horizontal orientation.

- David: It doesn't look like there is agreement on the missing 'Add content' link being a critical regression. With this new toolbar, it is very easy to add. Per @webhick, it is actually part of the north star design.

Committed to 8.x. OH MY! Now let's follow up on the outstanding issues.

Thanks jessebeach, lewisnyman, tkoleary, bojhan, webchick, benjifishe, nod_, sjbassett, kathryn531, effulgentsia, Everett Zufelt!

David_Rothstein’s picture

Status: Fixed » Reviewed & tested by the community

No... For Overlay, I think I'd just force horizontal orientation. We already hide the Overlay on smaller screen sizes, where we also force vertical orientation.

That works for me, but I wonder what the people who really wanted a consistent mobile/desktop experience would think about that, since it more or less makes it impossible? (Technically, the patch does allow horizontal orientation on smaller screens, but strongly "discourages" it.)

What ever happened to @catch's comment about performance testing (#87)? Did that become obsolete? We should probably leave that for him to answer.

jessebeach’s picture

Status: Reviewed & tested by the community » Fixed

I'm working on a project page to pull the followups from the issue summary here. They're be organized a little more sanely and you won't have to load 300 comments to read the list on your phone :)

#1846970: [meta] Responsive Toolbar follow-ups

Amazing work, everyone! We have more to do and lots of followups, but the first step is taken.

David_Rothstein’s picture

Apparently reading over the interdiff and marking this RTBC was not the best use of my time. Moving back to "fixed".

catch’s picture

Status: Fixed » Active

Please open follow-ups for the following and link from here before this goes back to fixed:

- whatever the two issues were that Dries mentioned.

- performance testing. While we have effulgentsia's jsonp caching in that's not the only issue and there's no sign of that being addressed prior to commit :(

Also needs a change notice.

jessebeach’s picture

Status: Active » Fixed

@sun, great feedback in #327, I'm rolling the items into followups now.

Most importantly, I agree the DX experience is very cursory at the moment. Any and all improvements are welcome. I have no opposition to iterating on the basic framework we have now.

Thank you for your perspective and honest critique in this issue. It really helped make it a better first commit than we would have otherwise had.

catch’s picture

Status: Fixed » Active
catch’s picture

Issue summary: View changes

Updated issue summary. added 787940

jessebeach’s picture

Issue summary: View changes

added 1846970

webchick’s picture

Status: Closed (fixed) » Fixed

Moving back to just "normal" fixed to alert people that this is so. :)

corbacho’s picture

=D Happy to see this great work committed
Congratulations, specially @jesse

catch’s picture

rvilar’s picture

I opened #1848552: Toolbar icons disappear with translated menu for a little big problem with languages

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

terrill’s picture

Another accessibility issue that doesn't seem to be have been addressed concerns zoom. If a user zooms in using their browser's built-in zoom functionality the toolbar eventually switches from horizontal to vertical, and (either at that point or after zooming a bit further) the toolbar obstructs the page content. There's no horizontal scroll bar for accessing the hidden main content. The toolbar does have a vertical scroll bar so users can scroll down and access the "Horizontal orientation" button, but many users wouldn't guess to do that, and those that do might not understand the button's purpose.

To replicate simply zoom in a few times using your browser's zoom feature. In most browsers you do that with either Ctrl + or Command +.

Some possible solutions:

  • Don't automatically switch from horizontal to vertical orientation - do that only if the user requests it
  • Move the orientation button to the top of the toolbar so users don't have to scroll down to see it.
  • Add a title attribute to the orientation button so users can tell what it does when they hover over it. I recommend a verb phrase such as "Switch to horizontal [vertical] menu" or "Move menu to top [left side]"
effulgentsia’s picture

@terrill: thanks for the info in #343. Can you please open a new issue for it and then add another comment here linking to it?

effulgentsia’s picture

Issue tags: +Usability, +mobile, +d8mux, +Spark

I don't know why tags were removed in #344. Restoring them.

effulgentsia’s picture

Issue summary: View changes

added 1847116

doakym’s picture

I install Drupal 8 since few days ago, and first that i see was the menu administrative the core and... I don't like, for four razon:
1.- Two levels in the head (why? is unnecessary).
2.- Height that have this both menus is excessive.
3.- Many clics for realize a task, (really?!!) for create a content type (four clicks), where's cron (five clics) or clear caches(five clics)?.
4.- Icons its good for final user (user anonymous or authenticated), but not for the user one.
The admin_menu module in drupal 7 works good, why wasn't considerate for the core?
I understand that want the same experience in various devices, but the User One will use the mobile device only when haven't the desktop, for the specified task or resolve a urgency, but no for build a site.

I see that exist two final users:
Builder the site in drupal (user one) and the visitor the site (user Authenticated or Anonymous).
The visitor or editor the site should have the task more used for him, availables in the top menu, create content, view all content, etc. But the user one have other task more used, as create a content type, add a view, move blocks, execute cron or clear caches.

Who's is the final user in administrative menu?

Dom.’s picture

'aria-owned-by' was added in this patch on toolbar, while it seems not authorized as per http://www.w3.org/TR/html-aria/.
Please see #2471809: Toolbar module does not follow W3C