Show HN: Mimicking the Bloomberg menu widget without JavaScript
dosyago-coder-0.github.io
dosyago-coder-0.github.io
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 />.
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.)
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.
* Sometimes called "carpal tunnel syndrome"
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.
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.
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
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.
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 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 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.
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.
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
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.
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
Only the ones that need it. Like for example when there is a single quote in the link like you mentioned.
Try clicking on the "Markets > Read: Economics" link.
Looks like one of the commenters here—franciscop—fixed that particular issue just after my comment.
Make a pure CSS version of that and you're king :)
I have Intel GPU with hidpi screen - Stripe's menu drops frames and spins up the fans.
Sure, height:auto can't be animated - but max-height:800px, for example, can be used to similar effect.
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
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:
http://interface.free.fr/Archives/Apple_HIGuidelines.pdf
>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):
Apple Human Interface Guidelines (1987): https://archive.org/details/applehumaninterf00appl
>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.
pp. 87: Hierarchical Menus: https://i.imgur.com/RrEDo3m.png
pp. 88: Figure 3-42: Dragging diagonally to a submenu item: https://i.imgur.com/a0gNWHh.png
Others have written about this issue in the context of the web:
Why is there a menu show delay, anyway? https://blogs.msdn.microsoft.com/oldnewthing/20080619-00/?p=...
>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":
Dropdown Menus with More Forgiving Mouse Movement Paths: https://css-tricks.com/dropdown-menus-with-more-forgiving-mo...
>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.
Tested on IE 11, Edge 12, latest Chrome stable and Firefox dev on Windows 10.
Source: https://github.com/dosyago-coder-0/mimic-bloomberg-menu-no-j...
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.
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.
Again, good job though if it's just for the lulz.
only one person blocks JS: false
therefore many block JS
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."
Still, the vast majority use javascript.
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.
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.)
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.
Still, really glad to see people trying and succeeding in doing simple web stuff without the need for unnecessary javascript. Good job!
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;
③ Use radio buttons and :checked.
Works fine for me on Firefox Nightly.
(Author: commit messages are a nice thing and worth putting at least some effort into.)
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
I'd like to read your write up if you do it :)
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.
I just posted a comment about this with a link to the 1987 Apple Human Interface Guidelines and page snapshots explaining the design.
https://news.ycombinator.com/item?id=17404345
pp. 87: Hierarchical Menus: https://i.imgur.com/RrEDo3m.png
pp. 88: Figure 3-42: Dragging diagonally to a submenu item: https://i.imgur.com/a0gNWHh.png
I also linked to an article showing how to solve the problem with CSS and without JavaScript!
https://css-tricks.com/dropdown-menus-with-more-forgiving-mo...
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!
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.
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.
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.
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.
Otherwise, sweet! Good stuff. Thanks for sharing.
If I was a bit more skilled I'd try and help you out on mobile compatibility.
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.
http://bjk5.com/post/44698559168/breaking-down-amazons-mega-...
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.
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.
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.
It took VLC ages to get rid of this issue, but it is solved as of VLC 3.0.3 (relevant Qt bug: [2]).
https://medium.com/@fpresencia/fixing-bloomberg-menu-mimic-6...
Edit: PR merged; removed own link