D7UX toolbar: Usability in narrow viewports

(Add tags.)

Ah yes, and now needs review...

• Improved patch so menu items do not break between lines in IE7, which caused strange display behaviours.
• Extended the height of the .png file even further, to allow truly extreme scenarios to still display correctly.
• Corrected (I hope) path to module so the patch will apply correctly.

not supported in IE6

Oh, how I look forward to the day when none of us have to care about this any more!

Limiting to a minimum width is a good idea. This could ensure that provided the toolbar only has the menu items that ship with core, it will not wrap. The wrapping behaviour should still be incorporated to cater for the edge cases where additional items have been added to the menu. I'll be interested to review your patch, boxfresh_1979.

boxfresh-1979's patch in #8 does not incorporate improvements made in #4. New patch to be uploaded shortly.

Attached patch combines the functionality in #8 with boxfresh_1979's suggestion that a min-width be set. In line with Dries' suggestion that we not have wrapping lines unless really necessary, this patch aims to set the min width wide enough that the standard D7 menus plus the longest possible username will not wrap. Thus, while the toolbar is able to wrap to a second line, this will only happen if both additional menu items have been added to the toolbar menu and if the viewport is also too narrow to display them all.

The currently committed version of the toolbar does not pass the username through theme_username, and thus the username could theoretically be any length. To be confident of preventing wrapping, it is necessary to know the maximum length of the username. Implementing the limit from theme_username, this patch limits the length of the username displayed to 20 characters. As "m" is the widest letter in most Roman fonts, the widest possible username would therefore be a string of 20 "m"s.

The patch was tested with that username as the admin user (mmmmmmmmmmmmmmmmmmmm) in Safari, Firefox and Opera for Mac, and IE8, IE7, IE6, Firefox and Chrome for Windows XP. Browsers render fonts differently and it transpired that Firefox for Windows was the browser that required the widest viewport to display all menus and this username without wrapping. This required a min-width of 1000px for the toolbar.

The current patch therefore provides one solution. The main limitation to this patch is that it will force the toolbar to be 1000px wide even for people who have much shorter usernames. This actually gives a pleasant amount of separation between the left and right parts of the toolbar, but plausibly might be confusing to some users. An alternative approach would be to set a min-width for just the left-hand links from the UL. However, this does not appear to be possible solely in CSS and I believe would require a re-write of some of the html being produced. If the consensus is that would be desirable, I'll look at it.

Note: In IE6 the above patch does not provide a min-width; rather, menu items wrap as the viewport gets narrower. There is also a minor 1px displacement of the "tab" for showing and hiding the shortcuts bar in IE6, though that may have been present in the originally committed toolbar—to be confirmed.

Hah. I was going to post "check again", but I thought *I* better do so first—and Gábor is right! I'd been fooled by the horizontal scroll bars being created by the viewport also being too narrow for the content, but they don't actually provide full access to the toolbar—so it *does* need work. :)

OK. Well one not fabulous solution would be to also set the 1000px min-width on the body tag instead of the toolbar. This will then correctly provide a horizontal scroll bar that enables the person with a narrow viewport to see the entire toolbar. The disadvantage of this is that it forces the page to be 1000px wide even if there is a fluid-width theme that could be displayed nicely in less space. Thus, this is hardly the ultimate solution.

HOWEVER, given the toolbar has already been committed, I'd submit that this is still a better solution that the currently massively broken toolbar when used with narrow viewports. We should still pursue a better solution, but this would seem to me to be slightly less broken that the current version.

That said, my guess is that this wouldn't be accepted even as an interim solution—so I won't bother to roll a patch unless I hear to the contrary. Presumably someone will need to come up with something fancy to solve this problem in the next four weeks because D7 couldn't possibly ship with the toolbar the way it is at the moment.

I take it this counts as "bug fixing" then, since code freeze is reputedly four weeks six days away?

Am thinking something along the lines of this looks potentially useful: http://valums.com/scroll-menu-jquery/

@tic2000: It would 100% fix the problems with the toolbar; the question is how undesirable the effects on the main site theme would be (forcing it to also have a min-width of 1000px)—the answer to which is probably "quite undesirable".

I am thinking the final result could be something akin to this:
http://www.joomla-outsource-india.com/horizontal-scrolling-menu.html

I'd be interested though if people think it'd be better to have control arrows at each end and use those to control scrolling (example of sorts here, albeit quite a different use: http://www.windhamfinearts.com/), rather than the interactive scrub-over effect seen in the tutorial above.

The other decision that needs to be made is about how it degrades when in a narrow viewport without js. The current behaviour in core is totally unacceptable (ie. unusable overlap of items and truncation outside the viewport without the possibility of scrolling). The two obvious alternatives are that with a narrow viewport without js the toolbar wraps or that the page becomes fixed-width (at about 1000px) but this would require the entire page to become fixed width, not just the toolbar.

Would be helpful to have input into these key decisions before coding another patch.

One other approach, as an example:
http://woorktuts.110mb.com/art_of_reuse_code/index4.html

This appears to have been fixed in another patch.