Found a bug with Chrome 67.0.3396.87 on Mac OS 10.11.6: When you hover over a menu item (e.g. "Markets"), the sub-menu updates based on the sub-items for the "Markets" item. However, when moving the cursor right (towards the sub-menu), the sub-menu state reverts back to the last activated menu item. Only clicking a menu item makes the respective sub-menu "stick". This is not the case for the actual bloomberg menu.
Don't know whether this is a limitation of the html+css approach?
Or to keep it JS free there might be a way to structure the HTML similar to: <Nav1><ChildNav1.../></Nav1>. Hover a :hover pseudo on <Nav1> will also fire when hovering over <ChildNav1 />.
Even the triangular cursor path thing could probably be done with just CSS, a short-lived extra element in the childnav that starts transforming away on hover, making the next nav item accessible if the intent turns out not to be to move to the submenu.
The tricky thing is getting the triangle’s node to be the position of the cursor; you need it to start at the left of the menu item, then animate rightwards only while the cursor is hovering over it, stopping when it’s not—so that it will naturally come to rest. This is possible to express with animations (animation-play-state is key), except for the fact that :hover calculations are not done constantly in most browsers, but only when the user does something to trigger it, such as moving the cursor. And so basically the whole scheme falls apart: it will work just barely OK, but if you move your mouse just a bit too slowly, it’ll effectively stop working.
It’s still an interesting thought. If you’re interested and my explanation isn’t clear enough, I’ll put a simple proof-of-concept-and-why-it’s-sadly-not-really-enough together.
(OK, since then I’ve come up with an insane approach that relies upon this behaviour, and it might just work, though I’m concerned about how reliable it’ll be across browsers. If it does work, it will definitely be blog-post worthy.)
It's 2018 and we still have to jump through hoops to get browsers to do things perfected on desktops by the mid 1990's. (Without bugs and browser incompatibilities.)
The Web royally screwed UI development and standards to Hell's basement, and nobody seems to want to fix it because the current mess is job security for low-level DOM diddlers.
I doubt many 90s desktop apps were designed around the expectation that the Turing Complete programming logic behind them could be explicitly disabled by the user.
And exactly what 90s desktop app had a menu that looked quite like that? Platform's then supported cascading popup menus with titles and icons rendered in native GUI chrome, ala the Windows 95 Start Menu. Any more flexibility required a lot of "low-level (whatever) diddling".
"Browser" incompatibilities are not much of a thing when you are developing for a platform provided by just a single vendor. But go ahead and try to port a Win95 app to OS7, you'll soon be longing to deal with the minor incompatibilities between different browsers (and yes, it's 2018, you don't need jQuery shims to reliably add two numbers together anymore).
CSS has long supported cascading popup menus without the need for any Javascript and browsers have long supported that CSS in a standards compliant way. Yes, if you really want some Win95 style menus you'll have an easier time in Visual Basic, but for most everything else it will be nearly impossible.
The webstack is not ideal by any means, but to suggest that it is somehow worse than win32 programming or easier to create responsive good looking apps in classic VB requires some mighty fine rose-colored-glasses.
I'm not proposing we go back to desktop apps as done in Windows et al. I'm proposing an open-source network-friendly GUI standard be created, or at least experimented with to test the power and limits of.
I suggest it be coordinate-vector based, and any layout and "flow" decisions be done on the server. Yes, if you resize your screen it would be slower than client-side re-flowing, but would simplify the client-side greatly, making it mostly a dumb vector plotter. Fat clients led to fat problems. Shift more to the server so you are using and testing with one render engine instead of the 50+ that browser brand/version combos result in. 1 < 50.
I wouldn't say the web UI got screwed. It's just that it grew out of a markup language whose main focus was adding semantics and hyperlinks to documents. Then commercial interests (among others) focused on adding more and more functionality to make them look pretty while maintaining some back portability and voila we ended up with the kludge that's todays web pages.
Same thing. Something that was meant for doing X was shoehorned to do Y, and the shoehorning has been ugly and kludgy. Let's try to throw it away and start fresh, or at least give it competition.
At first the products were buggy, but got better with each release. Even now our Oracle Forms programmers get stuff done about 7x faster than the Dot-Netters, and with about 1/7 the code. It's embarrassing: RSI* City. The OF apps are ugly, but they "gitter done". (Oracle bleeped up the Oracle Forms installation process, but that's another story.)
But it's the heavy iron of inertia and entrenched systems that makes it hard to fix -- there's no union of "low-level DOM diddlers" holding us all back.
It's not a "planned conspiracy", but rather experienced DOM/CSS/JS technicians have no incentive to "fix" it because the arcane nature of it keeps them in demand, busy, and well-paid. A horse farmer is unlikely to invent a car or try to perfect one.
I just don't buy that narrative. It's not my experience, and it doesn't really make sense. Most frontend devs would love a more sane ecosystem and tools. It's not like it would put them out of business... it would just make their work more pleasant.
Also, rank and file "dom diddlers" wouldn't be the ones "fixing" this problem anyway. There's a ton of economic incentive to fix it, but the problem of entrenchment is powerful when essentially the entire web is run on this mess. That's why it hasn't happened yet.
I mean, it's arcane all around. Ever tried developing for Android or iOS? Webdevs have the extra burden of "having" to support an infinite variety of form factors, aspect-ratios, input types etc. That kind of flexibility does not come for free.
It's not like these arcane technicians don't already try to "fix" things, with the plethora of JS/HTML frameworks-of-the-day to solve all use-cases (must...resist...urge to post xkcd link....)
Really, webdevs are not malevolently guarding their jobs by jealously protecting their dark web secrets like some private government contractor. They are just doing what they have to do in a highly complex field where laypeople still think a 16 year old on a weekend energy drink bender should be able to push out a finished Facebook clone for $50 on upwork.com
The borderline between those who can do something about it and those who are just "worker bees" who are or feel "stuck" with it is probably rather blurry.
Why can't a bunch of talented and experienced UI developers get together with university researchers to propose and test candidate HTTP-friendly GUI standards? (Let's limit the scope to "productivity" applications so we don't try to redo the entire Web.)
Asking others about it, UI "specialists" don't seem to care for what feels like job security reasons. That's just the vibe I get. It may be wrong, but I report it as I read it.
Those who DO care are often non-UI specialists who have to make a UI as part of the project but don't want to micromanage UI details that should be commonplace and road-tested by now being they are 30-year-old GUI idioms.
Re: a highly complex field where laypeople still think a 16 year old on a weekend energy drink bender should be able to push out a finished Facebook clone for $50...
Well there are probably some prodigies who just about could, partly because they don't have to scale up to gajillion customers just yet and don't have to support backward data/content compatibility.
I really, really do not get this obsession with Javascriptless interactivity.
I mean, seriously. Its 2018. JS engines are REALLY fast. And by the way, lets not be deluded into thinking that the Chrome is a lightweight nothing without JS execution. There are already GPU-aided reflow/repaint operations, your whole UI context lives on a different thread, tons of services are pulled back for audio/video capabilities, not to mention addons, HTML engine, etc.
So just learn proper JS, do not overdo it, and write efficient scripts. Its doable.
Just because a JS engine is really fast doesn't mean you should do everything in JS, esp if CSS is the right tool for the job (not to say that this particular demo is a good example of using the right tool for the job).
Sure, right tool for the right job, etc.
Animations are almost always better when they can be hinted to the GPU (will-change), can be transitioned with translate2d changes, and do not cause reflow by being used on absolute/fixed positioned elements. For example.
My point is that not using JS will not make browsing experience into something "pure". It will remain an incredibly compplex stuff in itself, which JS is only a part of. And when it comes to firing off XHR's, setting some data or providing interactivity (with real states, etc), then JS is a good tool for the job.
The point of the comment, is that if you can do the same thing without JavaScript or with, the implementation that doesn't use JavaScript is not categorically preferable.
That's pretty cool I was just about to make a write up of how to make a css dropdown mega menu, which is sort of semi-related in principle. I didn't find any good examples on codepen so I ended up writing my own.
I made a crude mockup here in PUG / SASS to cover just the essential "hello world" concept.
[link redacted]
A revised version
[link redacted]
and then an actual template for an ecommerce site I'm building
[link redacted]
I try to avoid JS if CSS can do the same job, because then I have the oppurtunity to change it much easier later.
the above examples uses no css frameworks or javascript libraries
I, on the other hand, would like to point out the lack of accessibility of this approach, it's unusable with a keyboard. Let's not forget about assistive technologies.
On many sites, such menus are meant as shortcuts to content that is otherwise reach-able by other means, such as typical web-site category links. However, automated accessibility grading systems won't necessarily "understand" this fact and score it poorly.
EDIT: ok, I see what they are trying to do, using # URLs whereas the "real" url would be an actual link that directs you to another page so the back button would work fine. But why make them weird fake links? Why not just make them actual links? It would make sense and wouldn't make the menu jump around randomly.
I looked at the source, looks neat except one thing: shouldn't there be double quotes around all href targets?
The ones that have a single quote (e.g. <a href=#/what'sinsidealltheiphones.html>What's Inside All the iPhones</a>) get marked in red in firefox's view source due to this
I don't mean to be overcritical of someone learning to code—this is much more a criticism of people upvoting links without clicking them—why is this on the HN frontpage? It doesn't work. At all.
Try clicking on the "Markets > Read: Economics" link.
I am sorry if this is kind of out of topic. I remember weeks ago I've visited their website with new design. Seems like now bloomberg went back to the old design of their website. Any clue?
Should be possible, but I don't get what's to like so much in unnecessary animations sucking your battery and making the whole experience awful on underpowered hardware.
I have Intel GPU with hidpi screen - Stripe's menu drops frames and spins up the fans.
Sadly `auto` values can't be animated. It can only be done with a bunch of hard-coded sizes and positions. Remove an item anywhere and you'll have to manually adjust.
One recommendation (if it hasn't already been mentioned)... easy dismissal of the drop-down. Once I have opened the menu, if I choose not to click on any of the navigation, I cannot simply click outside the <nav> element to dismiss it and return to my content. I'm forced to either engage with the Menu button again, or make a navigation selection.
Tested on Chrome Version 67.0.3396.87 and Firefox 60.0.2
I think the bloomberg marquee is one of the most CPU heavy things ever on a big news site. I let them know years ago, they acknowledged it and never fixed it.
There's actually a very good reason to implement a delay in switching submenus.
Recent versions of Apple's human interface guidelines don't make any mention of it, because those decisions are baked into the toolkit and not under control of application designers, but the earlier editions of Apple's guidelines went into some detail about why and how pop-up submenus were delayed.
1995 edition of Macintosh Human Interface Guidelines:
>pp. 79: Hierarchical menus are menus that include a menu item from which a
submenu descends. You can offer additional menu item choices without
taking up more space in the menu bar by including a submenu in a main
menu. When the user drags the pointer through a menu and rests it on a
hierarchical menu item, a submenu appears after a brief delay. To indicate
that a submenu exists, use a triangle facing right, as shown in Figure 4-36.
The original 1987 version of the Apple Human Interface Guidelines can be checked out from the Internet Archive, and should be required reading for serious user interface designers, the same way that serious art students should contemplate the Mona Lisa, and serious music students should listen to Mozart. Even though it's quite dated, it's a piece of classic historic literature that explicitly explains the important details of the design and the rationale behind the it, in a way that modern UI guidelines just gloss over because so much is taken for granted and not under the control of the intended audience (macOS app designers using off-the-shelf menus -vs- people rolling their own menus in HTML, who do need to know about those issues):
>pp. 87: The delay values enable submenus to function smoothly, without jarring distractions to the user. The submenu delay is the length of time before a submenu appears as the user drags the pointer through a hierarical menu item. It prevents flashing caused by rapid appearance-disappearance of submenus. The drag delay allows the user to drag diagonally from the submenu title into the submenu, briefly crossing parent of the main menu, without the submenu disappearing (which would ordinarily happen when the pointer was dragged into another menu item). This is illustrated in Figure 3-42.
>I run into this problem all the time on the Web. Web site designers forget to incorporate a menu show delay, resulting in frustration when trying to navigate around them. For example, let's look at the navigation bar on the home page of The Discovery Channel. Hover over TV Shows, and the menu appears. Suppose you want to go to Koppel on Discovery, but instead of moving the mouse straight downward, the way you hold your arm on the desk moves the mouse in an arc that happens to swing to the right before it arcs downward. You touch TV Schedules and your navigation is screwed up. You have to start over and make sure to move the mouse exactly straight down.
You can even solve the problem with CSS and without JavaScript, by using ":hover":
>This is a fairly old UX concept that I haven't heard talked about in a while, but is still relevant in the case of multi-level dropdown menus. A fine-grained pointer like a mouse sometimes has to travel through pretty narrow corridors to accurately get where it needs to in a dropdown menu. It's easy to screw up (have the mouse pointer leave the path) and be penalized by having it close up on you. Perhaps we can make that less frustrating.
Context: I like the Bloomberg site and their drop-down menu is cool. Purely as a challenge, I set out to mimick the styles and behaviour of that menu without using JavaScript and trying to keep the HTML/CSS as minimal as possible. Their menu widget does not work if you switch of JS (but this was not a motivation for me to make this).
Tested on IE 11, Edge 12, latest Chrome stable and Firefox dev on Windows 10.
Maybe this post should be a Medium post titled "How I mimicked the Bloomberg menu widget without JavaScript." I might write one if many people want that.
Great job mimicking the menu with just pure CSS! You even got the fade/slide down effect mostly there.
From a UX perspective there's a reason they used Javascript. For example, if you hover over "Politics" and want to click on "2018 Women Candidates" naturally you move your mouse at an angle. Which causes you to lose the menu when it mouses over "Technology". This is solved by tracking the mouse movement and holding the current menu open if the movement is at a specific angle
You could just create an invisible :hover::before on the <a> tag that renders an invisible triangle that overlaps the neighbors. Since it's still part of the <a> tag, as long as you're hovering over it, you won't activate other menu entries. You could even animate the triangle's size (or existence), shrinking it over time to mimic Amazon or Mac OS behavior. Set z-indices correctly so the right-hand panel is on top, and you're off to the races.
You'd want to use clip-path which isn't supported that well yet, but it does let you define non-rectangular hover regions. But there is still a problems with this approach.
It's subtle, but if you look at the Bloomberg implementation, if you move the pointer to the left at any point, it abandons the behaviour and highlights the menu item below the pointer -- even if the pointer is still inside the conceptual triangle region.
So I think you can get pretty close to a CSS-only solution in modern browsers, but the the small touches that make it feel great would still probably require writing some JavaScript.
The comments are actually great -- even Tog weighs in! It also mentions Frank Lehey, who rewrote the Menu Manager for Mac SE and Mac II.
Jake Smith • 5 years ago
This was first implemented by Apple's HID team back in the 80s, specifically Bruce Tognazzini, I believe.
Bruce "Tog" Tognazzini Jake Smith • 5 years ago
Yes, I did invent it back in 1986 and it is firmly in the public domain. From what I remember, it was Jim Batson who worked out the math and coded it for the Mac OS. The OS X team later failed to copy the algorithm, so I am happy to see that amazon has resurrected it.
Josh Davenport Jake Smith • 5 years ago
I think it was yes. It looks like it was originally implemented by NeXT and then removed by Apple when they bought NeXT. Tog himself talks about what happened here: https://www.asktog.com/columns/022DesignedToGiveFitts.html in the answer to question 6 - "When I specified the Mac hierarchical menu algorthm in the mid-'80s, I called for a buffer zone shaped like a <, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu...........Sadly, the NeXT folks, when coming to Apple, copied Windows, rather than the Mac"
markr_7 • 5 years ago
Can't comment on the HID team, Bruce, or possibly the many times it was even implemented at Apple, but as a young developer at Apple in the 80s, I remember stopping by Frank Leahy's office as he was tweaking his code to get menus to "work right." I've often recalled the experience because of the time he was spending to get it right, and how the behavior wasn't simple once you started really trying to meet a users expectations. If I remember right it wasn't just the direction, but also time and therefore velocity. For example, you wouldn't want to stick with the wrong menu if the user wasn't really moving with purpose in the direction of the sub-menu.
> This is solved by tracking the mouse movement and holding the current menu open if the movement is at a specific angle
Was it Amazon that first used this trick on their giant dropdown menus? I remember reading an article about their implementation but do not recall if they were the first or merely the most visible.
Here's an article that reverse engineers Amazon's implementation; http://bjk5.com/post/44698559168/breaking-down-amazons-mega-... - not the first implementation by a long shot, as pointed out elsewhere in this thread, but perhaps the first implementation for the web.
This seems like something that would be obvious to a seasoned interactive programmer(video games, animated UX, etc) or somebody in that mindset. I would be extremely surprised if some form of this technique doesn't have prior art going way back.
Correct. I first used a Mac with System 6 somewhere around 1991-1992. I remember using other GUIs (maybe windows 3.1 or X) and being frustrated by the menus, then realizing that the Mac had this diagonal most movement detection and that's what made their menus so much easier to use. Apple figured this out 30 years ago.
Hopefully the author of this article (dosy) can use the css :hover delay technique to make his menus even better than Bloomberg's, without requiring any JavaScript!
Subtle but important details like that easily get lost and forgotten, because it seemed important enough to write down in 1987, but now it's built into macOS and nobody can change it.
It's hard for most people to notice, because the whole point is to invisibly work behind-the-scenes to make selecting from submenus easier without distracting you!
So Apple doesn't mention it any more in their "modern" UI guidelines, since they don't expect macOS application developers to reimplement menus from scratch. But that's what web developers do all the time, so it's important to document and preserve details like this!
I highly recommend reading the original 1987 Apple Human Interface Guidelines to any serious user interface designer! It's quite dated, but so is the Mona Lisa!
Bruce Tognazzini invented the technique, and wrote about it in his "A Quiz Designed to Give You Fitts" on Ask Tog:
Question 6
What is the bottleneck in hierarchical menus and what techniques could make that bottleneck less of a problem?
The bottleneck is the passage between the first-level menu and the second-level menu. Users first slide the mouse pointer down to the category menu item. Then, they must carefully slide the mouse directly across (horizontally) in order to move the pointer into the secondary menu.
The engineer who originally designed hierarchicals apparently had his forearm mounted on a track so that he could move it perfectly in a horizontal direction without any vertical component. Most of us, however, have our forarms mounted on a pivot we like to call our elbow. That means that moving our hand describes an arc, rather than a straight line. Demanding that pivoted people move a mouse pointer along in a straight line horizontally is just wrong. We are naturally going to slip downward even as we try to slide sideways. When we are not allowed to slip downward, the menu we're after is going to slam shut just before we get there.
The Windows folks tried to overcome the pivot problem with a hack: If they see the user move down into range of the next item on the primary menu, they don't instantly close the second-level menu. Instead, they leave it open for around a half second, so, if users are really quick, they can be inaccurate but still get into the second-level menu before it slams shut. Unfortunately, people's reactions to heightened chance of error is to slow down, rather than speed up, a well-established phenomenon. Therefore, few users will ever figure out that moving faster could solve their problem. Microsoft's solution is exactly wrong.
When I specified the Mac hierarchical menu algorthm in the mid-'80s, I called for a buffer zone shaped like a <, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu. As long as the user's pointer was moving a few pixels over for every one down, on average, the menu stayed open, no matter how slow they moved. (Cancelling was still really easy; just deliberately move up or down.) Apple hierarchicals were still less efficient than single level menus, because of the added target, but at least they were less challenging than the average video game.
Sadly, the NeXT folks, when coming to Apple, copied Windows, rather than the Mac, in designing the hierarchical menu interface for OSX. Today's Mac hierarchicals are just as difficult to use as those of Windows.
Fitts' law is not just about target size and distance; it's also about the number of targets. The more targets, all else being equal, the longer the task will take. Hierarchicals automatically add one extra target. Making it difficult to enter a second-level menu adds an additional target, the second-level menu itself.
With my hierarchicals on the pre-OSX Macs, in most cases, the user did not even have to think about targetting the second-level menu. The menu opened, and the user simply aimed for the desired item. The only time the user had to consider the second-level menu separately was when there were so many items in the menu that the one the user was after was way up or way down the list, out of range of the allowable pivot for entry. Even then, users would typically arc along a more radical curve to reach their items in a single motion, rather than breaking things down into the jerky Etch-A-Sketch types of moves users typically make with today's hierarchicals.
When designing a user's required motions, reduce the number of motions needed along with both distance and required precision for each motion, then consider how your proposed scheme maps onto a human's ability to make those motions.
Any specific reason why you haven't used the old "Son of Suckerfish" approach? [0]
It would have solved the "stay open on hover" problem and made for much cleaner, more semantically meaningful and accessible html IMHO.
Still, really glad to see people trying and succeeding in doing simple web stuff without the need for unnecessary javascript. Good job!
Hopefully "semantically meaningful" is pretty self-explanatory, it just means using HTML elements in an organized and structured way (like not using a span when you should use a paragraph). "Accessible" means usable by screen readers and potentially other accessibility tools for people with low vision or other disabilities.
As an example: Consider using a <div class=“paragraph”> vs using <p>. The <p> tag is semantic and meaningful, whereas the <div> means nothing. A screen reader (or other markup interpreters) can’t tell what a <div> means
The menu is functionally completely broken. Because panel visibility is determined purely by :hover or :focus, as soon as you try to click on an item in the panel, that focus is lost and the panel disappears, taking your attempted click with it.
There are only three approaches that you can reasonably use here (they can be combined, too):
① Labels, which allow some rather nifty structure-breaking tricks on :hover;
② Change the .bmenu > a things from links (because you can’t nest links), and put the panel contents inside that node, then use :hover;
When you hover over an item in the main list, then move your mouse to the right, does the sub-menu stay the same or revert to the sub-menu for the first entry? (EDIT: Looks like that bug has been fixed. Earlier this morning, it would revert to the first sub-menu, now it works as expected)
Obviously you can develop things however you want, but IMO, not using a descriptive message in your commits (like repeatedly naming them "ok") is a pretty bad habit.
Firstly, job well done. Secondly, what is the motivation of going pure CSS aside from the challenge of it?
I once prefered Pure CSS stuff until I learned Javascript myself. Now I've come to loathe that approach on complex menus and widgets.
Mainly I dislike using them because I have to refactor them to use Javascript so they can be stateful (reacting to an active category or something indicated by the url or querystrings, etc.
It seems to me, many web developers today don't even realize, that creating features without js and enriching the experience from that baseline, not only enhances performance and accessibility, but in the end is often not more work and might even lead to cleaner, leaner code. I guess in the end it just comes down to which tools one learned first and based on that which approach one takes to solve the problem at hand.
I can only encourage everyone that thinks js is the catch-all solution to dive a bit deeper into html&css and try out alternate solutions. It's worth it for the knowledge gain in itself but offers many other benefits.
Why complex? Sure, this example is somewhat complex, but it does not need to be. Structure the menu in nested ul's, add simple hover css and don't use "display: none;" but rather "position: absolute; left: -999em;" and you get simple css and a good html structure that a screen reader for example can read easily and which also is clear to read if you turn css off entirely.
Of course, small hover menus offer their own accessibility challenges, but they don't depend on the way they are implemented but rather the choice of UX. And no reason why you could not improve this simple css menu with some js to make it more user friendly (like turning hover into clicks etc.)
For one, many people prefer to browse websites with javascript turned off. Aside from performance benefits, you turn off user tracking, flashy ads, autoplay videos, annoying popovers, etc.
I would expect that the percentage of people who browse without javascript on is incredibly small. The absolute number might be largish, and I guess in that context is could be considered "many."
> Mainly I dislike using them because I have to refactor them to use Javascript so they can be stateful
You shouldn't need to refactor anything done in HTML or CSS to add JS-driven statefulness. This is what's great about using JS: it's power allows it to wrap/augment existing functionality quite flexibly.
Any chance of making it click-based? For example, once I open it, I'd rather click on Markets than hover to change the right side.
Also, and I realize this was just for fun, making it responsive would be a nice touch. For example, force the right col under col 1 and col 2 below a certain width. That's easy and I think more people are likely to find the example more useful.
Awful usability. I expect that when hovering over a section and moving my cursor to the right I would stay within that section, but it always just reverts to home or whatever other section I've clicked.
If hovering over a section doesn't enable access to that section, then don't show the expanded version. Wait for a click event to show it at all.
There's a good article about Amazon implementing this feature for their mega menu. Blew me away when I first read it, it's very obvious and simple in hindsight.
Yes, there are some great tips. I still think this style menu is just bad, though. Although certain tweaks can improve the UX, it's still an frustratingly unusable interface for people with certain motor disabilities and even just older users whose mouse/trackpad skills are not great.
At this point, the department menu is an alternative to search. It doesn't need to be universally accessible or forgiving to poor motor control, because in terms of footprint it is tiny. I have used it before and it was just fine for me, and if some proportion of their customers have a similar experience, then it seems well worthwhile.
I completely disagree with this sentiment. Everything in a UI that you can do with a mouse should be tolerant of disabilities that people who use a mouse might be going throug (tremors etc). A user shouldn't have to try to do something and become frustrated in order to discover that it is "not for people with poor motor skills". We should do better. What you describe as "well worthwhile" still strikes me as woefully incomplete and annoying. Every user could potentially have poor motor skills at some point due to temporary causes.
It's not the end of the world of course. I just wouldn't think of "I have used it before and it was just fine for me" as a good reason to not strive for a more universal approach to interface design.
> Everything in a UI that you can do with a mouse should be tolerant of disabilities that people who use a mouse might be going throug (tremors etc).
Why? Should we give up on first person shooter games? Set minimum mouse target sizes for RTS games? The point of the department menu is to convert dexterity into information rapidly. If you lack dexterity, that's no strike on your character, but it somewhat defeats the purpose of a dexterity-limited input. There is an alternative to the department menu in the left side of the search bar, which has a simple list.
That technique was used long before Amazon used it. Actually, the first comment on that article confirms this: Bruce Tognazzini came up with it for Apple in 1986.
That's not the actual Bloomberg[0] menu. This copy does not seem to implement that feature, which is one of the most important features to have I think.
The original implementation at bloomberg.com is really well-executed, even solving the famous problem that when you accidentally hover another menu item while moving the cursor to the right, you might activate the adjacent menu item. [1]
It took VLC ages to get rid of this issue, but it is solved as of VLC 3.0.3 (relevant Qt bug: [2]).
No, he's correct. If you click on "Menu", move down to "Markets", and then move right, it stays on the "Markets" submenu on Bloomberg but reverts to "Home" on OP's reimplementation.
In the Bloomberg JS menu the right hand menu changes when you move up and down, but not when you move 'up and right' or 'down and right' over the left hand menu. You can move to the option you want in the left menu and then move your mouse right to get the option you want without being very accurate. In the CSS version you have to move exactly out of the left hand menu option you want to get to the correct right hand menu.
This is a great example of why it sometimes takes a lot of effort to make a good front end UI. Bloomberg's version is considerably friendlier to users.
I agree, so I went on and fixed it! I explained what I thought was the issue, which turned out to be a very minor visual bug, and the actual issue and fix in a Medium post:
Thanks! BTW, the :active trick is very, very neat. It took me a bit to understand that it was so you can actually click on the links. I normally use checkboxes for that, but I might find some use for the :active hack.
Bloomberg and Amazon do there right thing when moving from menu to submenu. I have to thread carefully here so that I don't jump to another one, which is bad. I believe Amazon computes it based on velocity and direction of the cursor.
Found a bug with Chrome 67.0.3396.87 on Mac OS 10.11.6: When you hover over a menu item (e.g. "Markets"), the sub-menu updates based on the sub-items for the "Markets" item. However, when moving the cursor right (towards the sub-menu), the sub-menu state reverts back to the last activated menu item. Only clicking a menu item makes the respective sub-menu "stick". This is not the case for the actual bloomberg menu.
Don't know whether this is a limitation of the html+css approach?