Why and how to avoid hamburger menus
lmjabreu.com
lmjabreu.com
Second, this is not so much a reflection of fly-out/slide-out navigations as it is a reflection of the fact that on mobile you just have less screen real estate period. Nowhere in that article is there a real reckoning with that fact.
I've yet to be convinced that fly-out/slide-out/hamburger navigations are worse than the alternative when you have lots of items to display. Either way you're not going to be displaying something, and whatever is not immediately visible will receive reduced engagement. If your home page/screen is full of navigation items, something else will be hidden instead.
Not to mention the article provides solution for cases that have many navigation items - something that is very common.
As far as the article mentioning user engagement stats, it probably matters a lot what the point of the app is. If you're trying to get a social app off the ground and your users literally will not spend 15 seconds learning to use it - you have to put everything in their face. If you're making a vertical market app or something where the users need it to do actual work - they might appreciate a quick, single-click access to a large menu vs clicking through multiple levels of tabs.
People these days seem incredibly quick to publish articles without considering how limited their perspective might be and thus the responsible way to present the information.
A nav bar, let alone a sliding nav bar, is tabs or an obese hamburger. We have been around this before. Tabbed desktop apps and tabbed web interfaces a la Amazon of the 90's. You know what this UI need? MORE TABS!
The great unbundling will continue as small screens and human eyes can only deal with so much info per inch.
I don't want to artificially engage with your A/B-optimized application. I want it to get the one or very few small things done that I need done. I don't want time sinks. I don't want to aimlessly dig through ambiguous icons looking for digital delight that you decided was unworthy of special treatment. If you are playing games with tricking humans into using your app, I question the value you are creating with your app.
There's a thing in my hand and it should be about the size of half a banana. If I want to see another half a banana, I'll put this one down and pick the other one up. I have one hand, two eyes, and a hankering for bananas! Show me pretty bananas!
I'm not speaking to the specifics of this submission, but the "it's on the front page therefore it has merit" argument is not reasonable. Topics that are particularly contentious (and feelings about UI is one of them, particularly when people are motivated by disagreements with co-workers about UI direction) tend to make the front-page with ease.
Tomorrow - Why "hamburger" menus are the bestest. Also, TDD is the best, and so is NoSQL.
I didn't say that. Why the quotes?
EDIT: I would love to see what an accurate paraphrasing is, then. I've re-read your post and what I stated is dead on with what you claimed, which is a common misunderstanding of the importance or common-agreement of a front-page appearance.
Also, your rule of thumb knocking the use of absolutes sounds like an absolute.....
My app has more than 4 views and one of the views needs to have as much of the screen available to it as possible, because a big chunk of the screen will be taken up by the keyboard. One menu button is better than trying to fit everything into 4 or 5 screens and having 5 buttons constantly taking up space at the bottom of the screen.
And I don't think that's "rare". It might be "rare" if your conception of apps is Facebook and SnapChat, but there there is a huge gap in the market for apps of real value that enable users to do real work in ways they can't do with a larger computer. Apps focused on helping users do work rather than selling ads to users will probably always grow in features over time. You can't get all of that to fit in 4 or 5 screens.
A Google Image Search for "Web Hamburger Menu" also brings up images of the type of menu the author is describing[1].
1) https://www.google.com/search?q=hamburger+menu&safe=off&espv...
I haven't heard the phrase "hamburger menu" before, but the image is often referred to as a hamburger icon.
Interesting method.
We're still in infancy on small and touch screen devices and we don't have a ton of reliable data as things are still changing too fast.
It's something to keep in mind but does anything have any alternatives when you have more than 5 items?
We'll settle over something good enough for most cases, but it'll not be the sandwich alone, and I'm quite sure we'll stop using it at desktops on due time. Also, we'll probably need to rethink some APIs for getting a real option.
This way my two most important pages get heavy traffic without removing the ability to access the other pages which get used less often.
Hamburger icons are great for large numbers of pages no one uses particularly often, but are necessary for the app to work (Settings, Profile, etc.) and as a fail safe to always be able to navigate to where you want. The way to access you main pages should be baked into them (links, buttons, action bars) on the page itself.
The hamburger is just a cop-out so you don't have to think very hard about your app design.
if you have a shit-ton of navigation items, get rid of some, because having fourteen is _not_ increasing engagement.
Sometimes, in the real world, clients want things a certain way and you are paid to make them that way. I would like less navigation options, but a big app has multiple things. That's just a fact of life sometimes - regardless of information architecture theory.
Unrelated, but did anyone else think the title was related to food? That's the first thing that popped into my mind when I read "hamburger menu"
It's not even a question of business metrics at that level. It's simply a question of thinking about how you want people to interact with your website, and a lot of designers (using the term as generically as possible--anybody who is planning a site, be they a graphic designer or developer) don't even get that far.
If I need to have specific functionality available but it's not something I use 90% of the time, then I gain nothing by making it more visible and efficient. If anything, interfaces may become more cluttered.
On that note, I would like to share a bit of information about the best burger I've ever had. I made an account just for this. If you are ever in the NYC area and you enjoy hamburgers, go to the Minetta Tavern in Manhattan. You will not be disappointed. I consider myself at least an intermediate burger-eater and Minetta carries the single best burger I have ever had. It is called the Black Label Burger. To me, it is a 9/10 where the next best burger I have had is a 7/10 and my average rating is a 4/10. Personally, I find cheeseburgers to be the best, but the standard Black Label Burger at Minetta has none. It is a testament to its greatness that I didn't add anything to the burger and it still is my favorite.
Look up the Black Label Burger. I can't get to the article while at work.
I am not a fan of having to scroll to a menu it can be disorientating. Like on a web page: you read and move down the page, you want to glance the menu, you have to go back to the top (home button) and then try and find your place in the text again. Overlays, popup menus, would be better there also. In my mind a website should be able to register actions with the browser, and that would get tied in with the device/app navigation.
Why? Because the solution offered is if you really must have more than 5 navigation items, use a hamburger. Oh I forgot, the "scrollable" navbar is a second "solution". AWFUL. This article is as bad as I thought.
"Make common user tasks as friction-less as possible."
Now, when a common user behavior is to use the main menu to switch between many different places in the app, then yes, hiding that menu from the user introduces an additional step. That creates additional friction. A permanent menu would be a good idea in that case.
But, if the most common use case involves a user mostly navigating from a main page (like a timeline or feed), then hiding the menu becomes less of a big deal. They will "organically" navigate through content from the timeline. Therefore allowing more space for the main element (the timeline) makes sense and increases the quality of the user experience.
As a plus, removing items from the screen helps make the action that you'd prefer the user to perform more obvious. That increase conversions in a context when you want the user to do certain things.
Lets focus on good UI/X design, which is often case dependent. No need to evangelize one particular approach and condemn another as being worthless (especially when you have weak reference studies).
I'd be curious to hear from someone at Facebook if they're around today since I've heard they're pretty data-driven.
Most of the apple apps put the buttons at the bottom and include a "more" if necessary.
My sense is the hamburger became more prevalent when it was used by default in Bootstrap, et al.
You can always trigger or "force" interaction on the user but you can't force content on a user after you lose screen space.
I'm sick of reading late criticisms about standard stuff that made its way into Android guidelines. There was the Dashboard, then there was Navigation Drawer, now Google+ completely changed a few things altogether.
If you want to make all features so visible, then why not use Dashboards ? In one screen, you list all critical features and in subsequent screens you have all the space for content. [Ignoring the fact that Dashboards make the app look old]
Or heck, we had real Menus before that, magically, heroically placed in lower part of the screen! Not an ActionBar on top of the screen where you strain your thumb in mega screens.
But no... definitely no. Everybody has to advertise something else.
https://en.wikipedia.org/wiki/Pie_menu
"Hold the flick and hold the presses, spatial borders won't upset us, all we ask is that you let us swipe it your way."
I'm developing 3D Augmented Reality pie menus for Pantomime, that you pop up by touching the edge of the screen (which is easy when you're holding the phone), which pop up in the center of the screen where you can see them, you control them by tilting, they stay in the same position in 3D "augmented reality" space, and they provide nifty continuous animated feedback!
That way the actionable area is the entire space around you -- a LOT larger than the screen!
With normal cursor driven pie menus on a big desktop screen, the further you move the mouse, the more angular precision and leverage control you gain over the selection. Pantomime 3D AR pie menus let you tilt to point out a lot further than the edge of a tiny phone screen!
By the way: we're looking for investors, and we just won first place in the Digital Media / Mobile category of the Launch Silicon Valley Startup Competition!
http://www.newswest9.com/story/25616093/pantomime-corporatio...
David Levitt tells the story at 1:45: http://veetle.com/index.php/search/video/kctv8?play=94493d4b...
Please contact us if you're interested in learning more about Pantomime, or know other people who would be!
It didn't help that the screen animations were too fast and lacked context. They also lacked user motions. Aren't there some standard ways of displaying tap and swipe events on a mobile screencast?
I'm talking about http://lmjabreu.com/post/2014-05-14-how-and-why-not-to-use-h...