I'm on the team that built this. We also built the redesign that launched last year. In fact, this was part of that. The article pretty much nails our implementation.
Point of fact: Our team is recruiting. If you dig UX projects like this, shoot our manager Chad an email: chaddes at amazon dot com
I loathe online store sites that auto-focus the search box. Worst are the ones that do it on every single page, including item detail pages. I use the space bar to scroll webpages down, especially on my laptop, which has a very small screen so that I almost always have to scroll down to get past header crap and get to the meat of the page. And no mouse, just a mediocre touchpad.
I can maybe accept auto-focusing search on the homepage, but there is no excuse for an item detail page. Even if I got here through a search engine, I probably want to see if this item is the item I wanted before I go searching the rest of your store, and that's going to require scrolling.
Definitely make the search box the first input in the tab-order though. Then if I do want to go straight to search, I can tap tab and then start typing. Otherwise, I usually want to scroll first and nothing is more frustrating than nothing happening when you hit space, only to realize that some tiny obscure search input buried in the corner of the page header that you didn't even realize was there is filled with spaces.
/less ranty
The best of both worlds would be to only auto-focus the search input if the user starts typing letters, and ignore space/arrow keys. We do this on Grooveshark actually.
I like the sites which takes you to the main input field of the page after pressing a single tab. That way, the page still has the focus when the page is loaded and you can easily get to the search box or login id by just pressing a tab.
You can always disable auto-focus on the client side if you don't like it. I have 'focuscontent' set in Vimperator which will "Focus the content after a page has loaded. [...] When on, it blurs any textbox which often is automatically focused on page load." I'm sure there are similar extensions for your browser of choice.
>You can always disable auto-focus on the client side if you don't like it.
Spoken like a true hacker.
Too often a site discussed on HN is criticized for a design decision that is easily changeable on the client. Anything that is slightly inconvenient for one specific workflow is a "misfeature", ignoring entirely that many people like it that way. A site designer cannot please everyone.
Most non-hackers do not even notice this stuff. Go find a normal person and ask them to list the sites they visit and whether or not they auto-focus the search box. They do not notice. We are the weird ones.
If it annoys you, change it. You have the power. Most of the time what you want can be accomplished with a simple extension, no coding required.
If not, you can write your own extension, or write a script for an extension, or "use" browsers like uzbl and luakit, or write your own browser. Then you can put your solution on the web, so other people can benefit.
I can't disagree more. Most people don't even know they can use space bar to scroll down, but it ain't no reason to break this behavior. I have seen sites breaking double clicks in edit fields or even using click to edit on texts, like trello, it is plain wrong.
Please DO NOT listen to this guy. This auto-focus to the search box misfeature absolutely ruins any page viewing navigation.
For people who use up/down arrow or pgup/pgdown keys to scroll down the page (which is pretty much all laptop users), this focus stealing misfeature would frustrate them to no end.
More importantly it completely breaks the page for a page-reading program, meaning the site becomes significantly less accessible to disabled users. In fact the guide to accessible website design (don't remember where to find it now) specifically says NOT to autofocus to some "random" or arbitrary place on the page.
Sorry. It's just a lot of websites have gone that route and it's really annoying. I didn't want Amazon to cave in to the seeming demand from users and wanted to present another view.
Judging from the up-votes it seems this resonates with a lot of people.
Not to mention any sort of single-key navigation. What is important though is that TAB should work and focus the important fields in the correct order.
I disagree completely. The fact that Amazon does not auto-focus to the search box annoys me greatly, since 99% of the time I find the items I'm looking for via search. Compared to Google, Youtube, etc. Amazon feels clunky.
Then why don't you just search via Google? "site:amazon.com bank of bob" or even most of the time you can just add the word amazon to your search query "amazon bank of bob" and I get exactly what I'm searching for.
To me you haven't made any case at all why others should have to suffer so you can have auto-focus on Amazon when your needs are already met elsewhere.
My favorite thing about DDG is that at this point there are so many bang syntaxes defined that if I don't know the syntax for something, I can often just guess and half the time I get it right!
"a foo" to search on amazon, "g foo" google, "i foo" imdb, "m foo" google maps, "w foo" wikipedia, "u foo" urbandictionary, etc... I have more but they are not public sites.
Chrome automatically recognizes searches on sites, so that you can just type "ama[TAB]" in de URL bar, and it will give you a site-specific search straight in the URL bar (provided that "ama" auto-completes to "amazon.com" for you, naturally). This works for basically every site you've ever visited that has search functionality. It's pretty decent.
I think it makes sense on Google where that's all you're going to do (more than just a common use case, it's almost the ONLY use case, probably like five 9s).
I don't think it makes sense on Amazon. A typical amazon user may browse around and explore outside of search. Maybe most of the time they will search, but there are no doubt other use cases like using the fancy nav. It's even possible that they want to encourage user's the browse around a bit instead of finding what they want and leaving right away.
Plausibly it tests out that people who expect the arrow keys / space to scroll the page get more annoyed by having to click out of a search box than people who want to search right away get annoyed by having to click into a search box.
You wouldn't want to capture the space key because you'll need that in search queries but the arrow keys sound like an idea for those interested in accommodating both cases.
Good point but I think it's now coming to a point where confusion might come into play. It's a balance between inconveniencing someone with auto focus and confusing someone else.
If I had to guess it would be that it doesn't test as well. Similarly to a physical store wanting you to browse, I can imagine Amazon wants you to look at the suggested items. If you wanted to search you will still search, but you might also get distracted and purchase something you were interested in.
That's what I came up with too. But on thinking deeper, it doesn't seem to hold true.
The kind of user who likes to browse will probably browse using a mouse, not a keyboard like us nerds. So the position of the cursor doesn't matter to them.
I hardly ever go to Amazon and not directly search for something (except maybe during Black Friday deals when I just click on the banner). I'd bet Amazon loses money by making me do an extra mouse click into the search box every time.
Unless there's a sizeable proportion of users who go to the homepage and scroll using the keyboard, I don't get it.
I'd love to see the data, but knowing Amazon they have both extensively tested it and will not release the findings. Anecdotally I have never not purchased something because I had to set the cursor focus and I have purchased something I saw on the home page.
Also, if you're a nerd, just search right in the browser. If I want to search Amazon I never actually go Amazon first I just type "a", hit tab and then my search terms. Chrome is smart enough to do the rest and I get right to the SERP on Amazon.
I would have never thought so, but Amazon's own data has shown that seemingly trivial things like increasing page load times by 100 ms reduces sales by a non-negligible %.
We're all arguing over data we don't have, but if they have that kind of information I think they have also considered search box focus. Seeing that they don't have it, one can draw the conclusion that for their site it was not profitable.
One of my favorite features of Chrome is that if you start to type "amazon.com" in the URL bar, and then hit Tab when it autocompletes, it switches the URL bar to an amazon.com search bar. I don't think I've typed anything in the actual search field of amazon.com in years.
This also works with the space bar, as well as the tab key. I find pressing the space key to be a bit more fluid when I already know what I intend on typing next.
I think any forcible redirection of focus makes your page inaccessible to users with screen readers. Just setting explicit tabindex on tags really screws things up; its best for accessibility to let the natural tab order rule. Many sites actually make the first tabbable element a "skip link" that jumps past the page's header and left nav content and jumps to the first <h1>.
So this topic made me curious, were does the first tab in the tab chain on Amazon go? I loaded the page in firefox, hit tab, and saw the first tab was http://amazon.com/access
Ok, this is an interesting design choice. That access link goes to a page with minimal styling, probably optimized for screen readers.
Now I'm really curious, and I pop open NVDA to give the page a listen. After the page title was read, the access link was read, which was very helpful: "A different version of this web site containing similar content optimized for screen readers and mobile devices may be found at the web address: www.amazon.com/access". It would have been best if Amazon did the work to make their default site screen reader accessible, but this is a nice alternative to having no accessibility at all.
Amazon needs to do some html/css/script minification on their homepage! Oh, nevermind, they gzipped it. :)
I don't want this as much as making / jump to the search box. I wish everything did this (I think only gmail and vim do). Although, that might interfere with Firefox (at one point it had an option to open the find dropdown when you type /).
I sit next to the team that built this, and work with them nearly every day. They are every bit as awesome as the dropdown would suggest, and you should definitely email Chad about working with them if you are interested in projects like this.
If they say "no", they're speaking for Amazon, and saying "we give you a right to infringe our patent". If they say "yes", they're speaking for Amazon, and making the firm look douchey.
If you know the engineer can't answer it, it's silly at best to ask it. At worst, it's malicious. See http://rationalwiki.org/wiki/JAQing_off (If you don't know that, then there's no problem and a quick explanation why it's not worth asking should end the thread. It's not something I'd take someone to task for.)
Huh? What on earth are you talking about? Nothing you wrote makes sense. Someone asked a question on the merits of a patent, the likelihood of it being upheld if challenged, if it is at all patented, etc.
What you are referring to is anti-intellectualism, to ask questions for the effect of the question itself. Hiding behind the hypothetical, and not for the desire to know the answer. The root question here wanted to know an answer, not play any game.
"Silly at best to ask it"? Again, what on earth are you talking about? If people have an insight to give, they will give it.
"Not something i"d take someone to task for"? Do usually tell people the things you don't feel like doing?
Am I the only one that gets tripped up each time I go to Amazon by mousing over the button and immediately clicking on it, thinking that's how to get the dropdown to appear, only to have the click take me to 'my account', then requiring me to go back up to the menu and wait for it to drop down instead of clicking? :)
No, that used to happen to me almost all the time. My habits only just recently adapted to it.
It's funny how ubiquitous unfeatures are that when we're treated to nice features we unintentionally sabotage them. We have to unlearn the former habits.
I've always found the 2-stage menu a major annoyance. Navigation always takes way too many steps: 1) hover "Department" if the window isn't wide enough; 2) hover category; 3) decipher the crazy sub-menu that appears to the right; 4) move mouse over and click the same category.
I've always disliked doing this many steps. Please make the Department menu into links such that I can avoid the sub-menus.
Yes. It drives me batshit crazy, and I avoid using these menus, and it decreases my propensity to use sites that depend on them. To me a menu should be simple. If I click on something I expect to go somewhere, not have my screen taken over.
Short takeaway - we are all different, us users, and what someone thinks is awesome design, someone else finds unusable. So providing multiple options is a must.
Brilliant. I have to admit I was wondering how that was done. It's always fast when I go to use it. Nice work, it's the little things like that that really matter
It's probably a great testament to its good design that I failed to notice how well it works when browsing Amazon. Everyone notices awful dropdown menus (and I really don't like Bootstrap's), but good ones like this often pass un-noticed because they work so well.
Exactly what I was thinking. I never noticed that Amazon's dropdown both displayed the submenu instantly and prevented it from mistakenly disappearing.
Speed is also involved. For example, if you hover on Sports & Outdoors and quickly move your mouse towards the Exercice & Fitness sub-item, it'll work. But taking the same path at a slower speed will hide the submenu.
This has always irked me about Windows's implementation of the auto-complete box.
If I start typing, in the address bar for one example, and my mouse happens to be resting over where the auto-complete will soon appear (as is likely because I just had to move the cursor to the address bar to select it) when I hit "enter" it will go to whatever my mouse cursor was over rather than what I typed.
The auto-complete box should detect mouse MOVEMENT not mouse position. The fact that my mouse was there before the auto-complete box even rendered should be a massive red flag that I am NOT selecting something in the list.
This happens with Win7's start search. Considering that many power users use start search without the mouse (i.e. hit windows key, start typing the name of something, hit enter) it's a really bad implementation.
The Mac equivalent (cmd+space to trigger spotlight, start typing, hit return) behaves as it should. If you move your mouse it'll highlight what is under it, otherwise the highlight stays on the top result as you type.
I use the keyboard shortcut "L" to label my mails. But because my mouse is usually somewhere around the location of the labels submenu before it even renders, I'll often apply the wrong label: the one at the mouse's position rather than the first one in the list. On a side note, starting to type actually hides the mouse cursor, so it took me some time to figure out why the 4th label was applied and not the 1st one.
I think, it depends on Windows version and auto-complete behavior setting. FWIW, Windows 7 doesn't do this with default setting. I do, however, recall observing this kind of behavior on XP.
It definitely still happens in Visual Studio on Windows 7, not sure about other places. Resharper might change this behaviour, not sure as I don't currently use it.
Nothing beats accidentally creating a new class instead of adding an existing one as a reference just because your cursor was in the wrong place, then spending time on wondering why nothing happens.
just tested it on Win7 and it appears they fixed this. pressing windows key and typing reveals a list with the first item selected every time.. unless the mouse moves
There is an important point to be made about the quote from the end of this article.
"Thanks go to Ben Alpert for helping me understand the linear algebra / cross-product magic ...I ended up going w/ a cruder slope-based approach, mostly b/c I’ve lost all intuitive understanding of linear algebra"
Let that be a wake up call to all of the programmers who continue to claim that you can "get away" with out knowing much math. In this case, the author admits that he used an inferior solution at first because it was based on the math he was comfortable with.
There are so many reasons that math is important in programming, but this article added another item to my list, namely: the level of math that you are comfortable with heavily informs and influences the various options available to you in forming a plan of attack against all types of problems, even those as simple as a drop down menu on a website.
I took away the exact opposite - this is yet another example of not needing to know the right math. In the end, he can study up a bit and/or seek out a friend who does know, but be got the hack done without it.
This is how it works with my wife and I sometimes. I write a lot of code, and she either fixes or writes or advises me on the bit I need to work much better.
I admit we can't run the world or write good code without math, but some of us have strengths in other areas.
First of all, "getting away" with something by relying on someone else to know what you don't know but need to use is hardly a virtue. If someone wants to work like that, to each his own. The problem I have is people telling the next generation that since you can "get away" without math, that it isn't important to take it very seriously as a programmer.
Second of all, like you said, you can get the "hack" done without math. I would say the less hacks you have to use in your programs the better, and the best practice is to code at a high enough level of generality that you don't need any hacks at all. Without math, so much time is spent (or wasted) tinkering around, and you don't often end up with the optimal solution. Whereas a strong math background lets you skip all that tinkering, because you are able to properly plan a solution before you even write a single line of code.
I think for programmers the constant state of learning (code techniques, browser quirks, new tools, new libraries, new algorithms) takes the edge off of learning "a bit of linear algebra" for one little part of your program. Would it help to really know linear algebra in and out? Sure, but that list of things worth learning is near infinite and the times you'll need linear algebra like this is quite small.
Web developer especially need to get their sea legs and be comfortable working on unstable ground all the time - it's inherent in the kludge we call web standards. So if you take a list of all the things a web developer needs to know to be effective, let's just agree "high math" isn't going to be near the top of that list.
There's something to be said about time investment. You're suggesting that tinkering takes time. If I want to keep current on all the math I learned in school, I'd have to invest a significant amount of time in addition to the time I already invest in keeping up-to-date with languages/frameworks/platforms/algorithms/datastructures/databases/etc.
How often would I use this level of math? I know I use the others on an almost daily basis. Coming up with something I need linear algebra for, though? Few and very far between. Maybe you use linear algebra often, but most of us don't have a need for it.
And if you disagree, then I think you should actually know abstract algebra, number theory, topology, etc., so that when the next problem comes along, you can 'quickly come up with an optimal solution'.
Sorry if this comes off as snarky, but I'm not sure of a better way to explain it. To me your comment sounds like:
"I have been walking through mazes my whole life with my eyes closed, and I make progress by feeling the walls with my hands. In order to get through each maze I need to remember lots of facts about how the walls in the different mazes feel when I touch them. If I opened my eyes now, it would take too much time, and be too painful to adjust to the light. I never tried to open my eyes, and even though a lot of people keep telling me it's a lot easier to get through mazes with your eyes open, I think they are wrong. Besides, the few and far between times I get stuck, I can always ask one of the people who can see where I should go next. And if you think I need to keep my eyes open, then the next thing you are going to tell me is I should use my sense of hearing and smell too."
Is that really the best you can do? That analogy has absolutely nothing to do with baak's point.
If you must reword and put his entire argument into a bad analogy, try this one:
"I've been walking through mazes all my life. This one time, I had to recognize a particular brand of poison flower, but I didn't know my flowers very well because flowers are rare in the maze."
And the answer?
"I asked my friend who was also in the maze: 'Is this flower poisonous?' He said yes. I said okay. We skipped the flower and moved on."
Pretty much this. Except you should also add that while he dedicated time to learning poisonous flowers that are encountered almost never, I spent that time getting in shape to move through the maze quicker, a skill/attribute used way more often.
Probably majority of most software engineering is "getting away" with it as defined in this context. Which is trying to accomplish a goal with imperfect knowledge about the methodology.
If the majority of someone's engineering involves concepts and tasks that one is 100% knowledgeable about, I'd argue that that person has reached a stale state and shoudl probably seek out other challenges.
Specifically, I'm NOT saying that math is not important.
I'm saying that there's nothing at all wrong with getting by with imperfect knowledge in a domain if the process of "getting by" means expanding your knowledge in that domain.
Everyone learns on the job. I don't see the difference between brushing up on linear algebra from school, and learning that new framework or language or software suite.
It's not a virtue to not know matrix algebra, but it's not particularly un-virtuous either. I have great respect for mathy engineers, but I also know the world needs its Jobs's and its Wozniak's, and it needs them to work together.
Absolutely not. Yes, you might be able to hack something with outside help but knowing math it is the mind set that would allow you to build something like this in the first place. You can imagine solutions to problems because you might visualize how they can be solved.
When you don't know what you don't know, you end up wasting countless hours trying to rediscover the solution to an already-solved problem. I know I have.
If your point is that it can be useful, then yeah, point made. If your point is that it is so useful that all programmers need it desperately, sorry, a single place where a more complex understanding of math might (we'll never know) have yielded a better product does not go anywhere near being a point to be made.
I loved all sorts of math while in school, have forgotten almost all of it, and have had to use almost none of what I learned in such a direct way as this. I definitely wouldn't argue that it's not important, but you are overstating it based on an outlier.
I find my math background to be extremely valuable in programming, but this is only sometimes because I use any actual math. Most of the advantage comes from being able to reason about abstractions more effectively. Similar to what you'd expect from a good CS background, which I'm sure most programmers would agree is useful.
While I agree that it's good to exhort one another to learn as much math as possible, I feel compelled to offer myself as a counterexample in the "getting away with it" argument.
My formal math education ended with calculus in high school (and college) and then probability in college. Never even took linear algebra, something I've always intended to remedy. I did rock Phil 160A, but that's not really apropos.
Anyway, on to the counterexample:
My first company was math-heavy, doing some pretty sweet web-scale analytics (in 1998!) pushing those matrices into SVD and then some crazy orthogonal rotation routines to make the results more human-readable. I was the only engineer for the first year plus, and the lead engineer for the lifetime of the company (1996-2002). One of the founders was a stats genius, old school, and he designed all of the analytics routines although I ended up implementing them. There is no way I could have ever approached his level, regardless of how much undergrad (or grad-level) math I had undertaken. If that company had been founded by a bunch of CS grads thinking "oh, sweet, I know some big data algos" I don't think we could have pulled it off. He had decades of psychographic analysis under his belt, informing all of our choices, and heading off any number of dead ends. But, even with my limited math, working with him, I was certainly able to implement the relevant bits in a performant manner.
My second company - which I founded - involves, essentially, zero math. (big surprise) Sure I know my CS algorithms and data structures and making educated choices like "should I use a bloom filter here?", but in the end our company deals almost exclusively in business processes that don't happen to need much math. And we're quite successful, with a great 10-years-and-going-strong history as a SaaS vendor.
Point being, there are tons of business problems that don't actually require big math to solve them. What they do require is a deep understanding of the problem space. If you're working on solving a real-world problem, and you've got some spare time, I'd argue that you are better off understanding every last frigging detail of that problem than you are doing some catch-up work in linear algebra. Sure, it may turn out that the solution you need requires sophisticated math - and, to your point, you may not even know that solution space exists if you ain't got the math - but that's secondary to the deep understanding in the first place.
Software is a big, complicated place full of layers upon layers of really complicated stuff. Some layers are full of math, especially when it comes to examples like the OP's. Other layers, however, are not - they are instead full of rules and processes that are based on RFC compliance and real-world knowledge ("oh, Exchange actually does it that way").
I, personally, think the OP took the right path in implementing a solution he understands rather than one which he'll never be able to debug down the road.
For the 0.1% case where he actually would have needed math, he got away with it and just asked a friend. Nothing wrong in focusing on the 90% of the 90/10 and asking for help if you're in that 10% part.
"I don't know for sure why the Microsoft solution is so clunky. It could be they just didn't do a good job of copying the Mac. More likely, they never tested and iterated. When Eric and I finished our first prototype, it was at least as clunky as Microsoft's solution. We, however, put ours through another four or five rounds of testing and design before we elected to ship it."
Not of the same magnitude then. Mediocrity is the nemesis of good, with the sole mission of undermining it at every turn. The drive for perfection, on the other hand, might sometimes be a foe, but overall facilitates good. It's clear which is a more damaging influence.
Personally, I'll agree with Salvador Dali when he said, "Have no fear of perfection - you'll never reach it."
Gentlemen, we are going to relentlessly chase perfection, knowing full well we will not catch it, because nothing is perfect. But we are going to relentlessly chase it, because in the process we will catch excellence. I am not remotely interested in just being good.
—Vince Lombardi
Wow, I can't believe I saw both aspects of that behaviour (changing quickly and selecting an element diagonally) and I never noticed that something should be wrong. This exactly the definition of good UX.
Cocoa seems to be using the triangle technique + a delay, FWIW: a submenu will close instantly when navigating vertically or to the opposite direction, but there is a lot of leeway when navigating in the triangle towards the submenu (eyeballing it, seems to take more than half a second for the submenu to close). And interestingly, you can also "overshoot" the submenu, it will delay its closing quite a bit when moving around/outside of it.
Per TFA:
"... when you try to move your mouse from the main menu to the submenu, the submenu will disappear out from under you like some sort of sick, unwinnable game of whack-a-mole."
Thanks for the list. We were quite literally discussing this at work only yesterday, because the IntelliJ interface doesn't do anything. They use the Java Swing toolkit, which doesn't have any special treatement of sub-menu's.
I was still dissapointed, not because Swing doesn't support it (I can't stand the default Swing Look and Feel), but because everything about their custom Look and Feel is awesome compared to default Swing, so I was hoping that they had added this feature too.
I'm hoping that the open source community edition includes the source for their Look and Feel, but I'll have to wait until I've finished checking out the 1GB of source from github and then start trawling through it.
GTK+ uses the triangle technique along with a delay of 225 ms. When the pointer is inside the triangle, the delay is 1500 ms.
Firefox subscribes to the misguided "fake the look and feel of the default toolkit" idea, so on Linux it has a 225 ms delay, but without the triangle. Unfortunately 225 ms is way too short when there is no triangle.
If I drag my cursor from item2 to item2.2 through item3 qucikly, there's clearly a delay, as I see item2.2 get highlighted, but then the submenu disappears, and it selects item3. However, if I overshoot and drag the cursor out of the menu altogether, it leaves item2.2 selected.
But then I think it does something with the angle it is moving at to make that sometimes not work.
The behaviour is complex and unpredictable, which is different than nothing.
It's funny to see this level of attention to detail. I've always found Amazon to be one of the worst designed websites outside of the checkout process, and not from a prettiness point of view. I'm convinced their success is purely due to a smooth checkout process, superior customer service (easy refunds, Amazon Locker, etc.) and price.
Amazon never makes we want to buy anything. I only buy if I go there knowing what I want. Browsing (as in shop browsing) is broken, the suggestions are inane (you've just bought a white 3m network cable, why not buy a blue 5m one?) and the search tools are lacklustre (can't sort by price until you choose one of three plausible departments your product falls into).
I have a Kindle and often go to their website looking for a book to buy. This experience sucks. If I go to Waterstones on the high street, they have both a relatively good depth of inventory but also attractively laid out tables of books grouped by subject. I invariably find 2 or 3 books that I like the look of. Unfortunately for Waterstones, physical books are not what I want (I live in London. Space is not plentiful).
Amazon the store front sucks. Amazon the check-out is awesome.
If the right side box is very short, this algorithm gets a bit fussy. Not a problem for Amazon since their right side box is fixed height, but often a problem for menus where there is only one item in the sub-menu (usually because the sub-menu is programatically filled in.) You have to thread the needle moving your pointer to the right, because if you leave the line, it collapses the selection and selects the next item.
Even OS X has this issue, so if someone gets a good solution, they can beat Apple at their own game.
Agreed on the small submenu issue. I think this instant behavior makes the most sense when it's always the case that submenu.height() == menu.height().
Single-item submenus and super-long submenus are to be avoided at all costs. They are not user friendly. The former has no reason for being -- put the contents in the parent menu as a sub-section. The latter is generally found in auto-generated lists, like lists of fonts or countries.
Usually a menu is a bad UI device for selecting from very long lists. Combo boxes are one alternative. Breaking contents up into chunks and adding another level to menu hierarchy is another possible solution. MS-style hiding rare choices is a third option.
Single-item submenus inevitably occur at some point if the submenu is filled out programatically (as smackfu pointed out). A list of recently open files is a good example. While it's possible to move the single item into the parent menu, that would make the menu confusingly inconsistent.
I think part of making this solution intuitive is to make the submenu box a a fixed height that's equal to the first menu. It's what the author changed his menu to look like as well. Amazon got around having too much empty a space by adding pictures, and too many submenu options by adding a second column. If your submenu is so long that even 2 or 3 columns isnt' enough, it would have been too long for a single column anyway.
Set up the submenu system so in the event of a single line, it presents an invisible target, which is three lines high, with the submenu in the middle.
It's not magic, it's just math. The cross product [1] between the vector of the mouse movement and the vector of the mouse's location to the menu's top left corner tells you the relative orientation of the two vectors. Compare that to cross product in regards to the menu's bottom left corner and you can easily figure out that the mouse must be moving towards the menu. This is much easier than figuring out the bounding triangle that the person drew in this article and then figuring out if the mouse is inside of it.
Are you sure about that? The dot product gives a measure of the orientation between two vectors, the cross product gives perpendicularity and is vector valued (kind of, the distinction matters more for physics than graphics). It also only makes sense in 3 and 7 dimensions without generalizing the concept of vector.
Balls, you are correct, dot product is the correct operation, not cross product. Been a while since graphics ops were on my table.
EDIT: Well, cross product would work, too, if you extended the 2D vectors into 3D vectors, coplanar in the screen. The orientation of the cross product into or out of the screen would also tell you the relative orientation of the two vectors. So then, you'd be looking for the two cross products with differing signs on the Z component to tell you if it's "in the triangle".
After some playing around, dot product won't do it. You can get close with dot product, but it really only gives you the general direction. Cross product (and really, only calculating the Z component of the cross product of coplanar 3D vectors) will get it exactly right every time.
So basically, for a moving between two mouse points (Ix, Iy) and (Ax, Ay), and a top left menu corner (Bx, By) and bottom left (Cx, Cy), then:
DAx = Ax - Ix
DAy = Ay - Iy
DBx = Bx - Ix
DBy = By - Iy
DCx = Cx - Ix
DCy = Cy - Iy
Z1 = DBx * DAy - DAx * DBy
Z2 = DCx * DAy - DAx * DCy
Then, you know you're headed towards that menu if Z1 < 0 and Z2 > 0.
Could be simplified a little if you assume the X component of the top left corner of the menu will be the same as the X component of the bottom left corner, but the math was clearer to keep them separate.
And if you have any convex polygon as an ordered, circular list of points proceeding clockwise, then you can easily loop around the points checking your cross product values making sure they are all greater than 0 to determine if the point is in the polygon. You'll have to tessalate concave polygons into a list of convex polygons, but that's eaaaaaasy ;)
Right and excellent explanation. I was more disagreeing with your definition than saying it could not be done with "cross products" (although it's still bad terminology, biased to people that already know the concepts). That's why I couldn't say you were wrong. Intuitively, a measure of how parallel two vectors of arbitrary dimensions are, is a better default when talking about orientation of vectors.
You need cross product if you want to know sign. Dot product won't tell you which side of the line you're on, and that sounded like a big part of the algorithm.
No, the dot product won't work in this case. Take the two edges of the triangle as vectors. You want the mouse vector to fall in between. The dot product can't tell you which side of the two edge vectors your mouse vector falls on, but the cross product can if you look at the component of the cross product that points in/out of the screen.
Actually, you can make the dot product give you that answer, but you would need use the dot product of the mouse vector and two vectors normal to the edge vectors, which is really just a roundabout way of using the cross product.
Off topic, but the Reddit post about Neox Screen using the ShareX source code and asking for donations is quite disheartening. Not that anything illegal occurred, just the level of deceitfulness.
This is in fact equivalent to what's in jQuery.menu-aim.js, eg upperSlope < prevUpperSlope => upperSlope - prevUpperSlope < 0, then inline slope() and multiply through by the denominators.
I'd prefer the code above though, as there's no icky division by zero.
This is some really good UI code. You're storing the state in a very clear way and do the geometry calculations in one place, making it easy to understand what's going on. Nice!
Maybe I'm just cynical, but this seems like the kind of thing they would have patented (not that it deserves a patent, just that they would have applied for one).
I just tried it in Chrome. View > hover over Encoding. Move mouse down over Developer and onto the Encoding submenu. There's a definite delay, although it's much shorter than Amazon's. Move the mouse over Developer in the other direction (down and to the left), and there's no delay.
I never appreciated this, yet it affects me many times a day. Really thoughtful UX design.
Maybe, but I'm not aware of Amazon being a patent troll in its recent history. I'm aware of the fight they had early on with one-click checkout, but since then?
Thanks for this and I'm looking forward to trying it out!
I've long been annoyed by delayed menu dropdowns, but also having to maintain fine mouse control to get the dropdown to behave how I want it to behave. I don't know why the delay bothers me as much as it does, but I think I'd rather take the finicky preciseness of dropdowns over delayed dropdowns. Amazon's solution is really the elegant winner. There are still some tradeoffs, but I think their solution makes the most sense for delivering expected results to users.
Awesome UX. I believe this implementation is called a v-buffer, though I can't find any references right now but I am fairly certain I read about it a decade back.
Apple used this technique for their menus early on while Microsoft took the alternate route of using a delay which was quite annoying. A lot of power users removed the delay via registry settings and it was surprising why Microsoft didn't adopt the v-buffer--might be patents related?
The problem with the delay is not only the delay itself but for wider menus the delay needs to be even longer. Then to account for novice users, you add in a little bit extra just for good measure.
One way to mitigate long delays is to make the parent menu taller so the user has a bigger margin of error while they move the mouse horizontally to the right.
However before hi-res displays became common, vertical real estate was far more limited. On the earlier windows machines where you often ended up having two columns of menus, this was even more annoying because trying to get to the second column of menus required moving your mouse right, through the first-column's submenus. In later version of Windows, Microsoft did away with two column menus and introduced a single column with scroll up/down to solve this issue,but introduced further delay when trying to get to menu items below the visible screen.
"See the delay? You need that, because otherwise when you try to move your mouse from the main menu to the submenu, the submenu will disappear out from under you like some sort of sick, unwinnable game of whack-a-mole."
How will a delay before displaying the submenu prevent that? If it would be a delay before it disappears I would understand but in the example it doesn't seem to have that.
If your submenu is extending from a link in the middle of the parent list, you don't want the current submenu to disappear if your mouse tracks across the corner of the link above or below the intended.
Consider this:
The link A | A sublink of B
Some Link B --> | Another sublink of B
A link C | And again a sublink of B
| Jez, B has a lot of sublinks
If the user mouses over "Some Link B" and the submenu expands, without a delay (or other mechanism such as the triangle effect described in the article) the submenu could disappear when the user tries to move from "Some Link B" to "Jez, B has a lot of sublinks" if it happened to cross the plane into "A link C" or out of the navigation list entirely.
Thank you for the write-up on this! Like you, that has been a pet-peeve of mine as well.
I wonder if we can get a comment from Amazon or Nycto, on why the search box is not auto-focused though. This seems like such a natural thing to do, and saves your users a mouse move and click every time they come to the site.
I suspect that being forced to move your mouse to the search box pushes your eyes to scan the page as you do so, which increases the likelihood you'll find something interesting between your cursor and the search box.
This is really fantastic behavior, but content - the actual list items they show - is much more important for user experience. Why should "Amazon Cloud Drive" be a "Department"?
In the wild, I suspect I would quickly glance at the top level items and decide that this menu isn't useful for me. If I were searching for something specific (presumably the main use case) I'd jump over to the search bar. If I were just browsing, I'd jump to one of the 100000 other random things to look at on the homepage.
Somewhat related: I wonder if they thought about varying the top level list items by user.
I don't get why is detecting the mouse direction necessary in the case of the Amazon dropdown; I can see the utility in the Bootstrap example that the article highlights, but if the dropdown menu and its submenus both fit in a perfect square, wouldn't it be enough to detect whether the cursor is inside of either the menu or the submenu to properly show/hide the dropdown and its submenus? What are the drawbacks of this method compared to detecting the mouse direction like the article suggests?
The issue is that when you are hovering over a menu item, and you are aiming to hit a submenu item that is not directly to the right of the menu item. For example, if you are hovering over a menu item and wish to select a a submenu item that is to the right and down the screen, you will take a down-right path UX wise. Normally this would trigger the menu items below (before you make it to the submenu) and thus change the submenu items.
Pretty sure that's possible without tracking the direction of the mouse, by simply not hiding/showing the submenu but changing its contents when the mouse hovers over a different menu element.
I seem to recall this same technique being used in the pre-OS X era of the Mac OS. Not sure exactly how far back, but I'd say at least into System 8 if not System 7.
You're right, mac has been using this technique for a while. Actually trying it out right now, it still does this, but you need to move it fast. If you move it fast enough within the triangle it'll stay, while if you move it at the same speed straight down, the menu goes away immediately.
Is the triangle thing straight from amazon code? Because I think it would make more sense to track mouse movement and keep the submenu shown until the mouse is moving towards the submenu. Not in any specific triangle. If the mouse moves below, above or away form the submenu, the submenu changes.
Small, almost trivial things like that are what distinguishes good from awesome! And great post! As alot of people already mentioned, you don't actually see difference, you just see that it's way better but you can't put your finger on it. Thats what great design is there for!
Amazon is often considered a lumbering giant, so it's great to see this type of innovation from them. We all know they spend lots of time on UX, but I had no idea they had teams thinking outside the box like this.
I don't remember when Microsoft started doing the triangular beam (to allow moving the mouse right slightly inaccurately) in Windows, but it was really annoying until they did. I think they had it in Windows 98.
I'm on the team that built this. We also built the redesign that launched last year. In fact, this was part of that. The article pretty much nails our implementation.
Point of fact: Our team is recruiting. If you dig UX projects like this, shoot our manager Chad an email: chaddes at amazon dot com