Live data from Hacker News

Show HN: Mimicking the Bloomberg menu widget without JavaScript

dosyago-coder-0.github.io

101–110 of 144 posts

Re: Show HN: Mimicking the Bloomberg menu widget without JavaScript

#101
post #73

Earlier quoted context omitted.

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; ②…

Nice try but it works fine in all browsers for me.

It's getting truncated for me in Chrome.

Re: Show HN: Mimicking the Bloomberg menu widget without JavaScript

#103
post #2

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. Source…

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…

You could just create an invisible :hover::before on the tag that renders an invisible triangle that overlaps the neighbors. Since it's still part of the 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.

Re: Show HN: Mimicking the Bloomberg menu widget without JavaScript

#105
post #103

Earlier quoted context omitted.

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…

You could just create an invisible :hover::before on the tag that renders an invisible triangle that overlaps the neighbors. Since it's still part of the 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'r…

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.

Re: Show HN: Mimicking the Bloomberg menu widget without JavaScript

#106
post #90

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.

Re: Show HN: Mimicking the Bloomberg menu widget without JavaScript

#108

Earlier quoted context omitted.

No. Mac OS had it.

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.

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 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.

Re: Show HN: Mimicking the Bloomberg menu widget without JavaScript

#109
post #100
post #90

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.

Lamenting the current absurdity is fair. 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.

Re: Show HN: Mimicking the Bloomberg menu widget without JavaScript

#110
post #90

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 (…

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.

Post reply on HN