Live data from Hacker News

Show HN: Mimicking the Bloomberg menu widget without JavaScript

dosyago-coder-0.github.io

111–120 of 144 posts

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

#111
post #98

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…

http://bjk5.com/post/44698559168/breaking-down-amazons-mega-...

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

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

#112
I love what you've done here!

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

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

#113
post #65

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.

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

#114
post #109
post #100

Earlier quoted context omitted.

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.

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.

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

#115
post #109
post #100

Earlier quoted context omitted.

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.

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

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

#116
post #103

Earlier quoted context omitted.

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…

You can also use a very acute 3D perspective transform to create almost any quadrilateral shape, so the support can be a bunch better.

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

#117
post #109

Earlier quoted context omitted.

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

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.

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

#118

Earlier quoted context omitted.

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…

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

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

#120

Earlier quoted context omitted.

zero people block JS: false only one person blocks JS: false therefore many block JS

"Many" is not synonymous with "multiple". 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.

Haven't you studied cardinality? You don't have One to Multiple relationships, you have One to Many /s
Post reply on HN