Heh. Big ole hamburger button on their blog.
Ooof. Egg on our face. :-P
The blog post was about our native iOS app, though at the moment it's not clear from the title. And the use case is definitely different: the business impact we saw was due to customers who rely on the app daily; can't say the same for our blog. ;)
Ha, I couldn't help but point that out. Also, you may want to consider reordering your sidebar and content area in your markup. This will avoid having all that "junk" in your sidebar appear above the actual content.
Let me guess the next article: why we removed the huge header
Look how big it is:
This would be an amazing follow up post actually :)
Looks great! The analytics look promising.
Hopefully, the increased engagement (time in app, etc.) is not from people trying to figure out the new UI. I imagine not since the traffic jumped to a new level instead of spiking for the first few days.
Yes - we were wary of declaring success too soon, since a new UI often prompts early exploration before settling into a new pattern. We did see that the increase in sessions, session time, and daily active users was sustained over time.
One of the tidbits I found particularly interesting was that our DAUs on weekends more than doubled - not what I'd expected for an app whose customers primarily use us during business hours to collaborate and check on their tasks. It seems to indicate they're finding the new design an easier way to get their latest status, even when their colleagues aren't around, so that's a somewhat unexpected win for the user experience. :)
It's interesting how the hamburger menu has grown due to trend almost more than need.
Initially, it seemed to me that all apps had 4 or 5 buttons on a tab bar at the bottom of the screen. Then apps started adding complexity, the hamburger almost gave people a license to do so. Now we're seeing apps refining their options in favour of user needs and ditching the hamburger.
The way the industry is growing and exploring all the possibilities in tandem is fascinating. The speed of change is incredible where we see constant improvement from all sides.
I agree. Well said!
The hamburger menu is a crutch for apps that were built without a true mobile content strategy in place.
The one other thing to consider is that the 'Responsive Design' movement meant that desktop content had to also work in mobile view which is kind of like fitting a square peg into a round hole. I believe this is also part of the reason why complexity creeped into some apps. (LinkedIn is a good example.)
The smart thing to do is get some user research and usability testing done and devise the content strategy around that, accommodating context.
I'm guessing there was a lot of TL;DR skimming because from reading and looking at the first couple images in the article it was pretty clear to me, anyway, they were referring to killing off the hamburger in the ios app in favor of a menu bar at the bottom.
Interesting take on it...but I still see the good ol' hamburger button? Anyone else?
Yes - the hamburger menu is still on the blog, but "banished" from the native iOS app. Unfortunately that's not clear from the title so it does look a little contradictory. ;)
There's some nice research about this right here: http://exisweb.net/menu-eats-hamburger
I'm a little late to this post, but I don't think this article is really a fair comparison. This appears to be a restructuring of the app as well. I don't think your previous iteration was a great use of the hamburger. You used it as a quick jump to favorite projects more than anything. Other than that, your hamburger wasn't really necessary. Which I think is why the bottom tabbed nav actually is a great idea for you.
You essentially moved your hamburger down to a list button and then moved all the other buttons were nested previously to the tab bar too. I think that the hamburger can serve a purpose, but your app definitely should have been a bottom tabbed approach from the start.
Just a heads up, but your commenting system on redbooth.com is broken.
I had replied to the article on the website itself, but was served a 405 error upon submission. You may wanna get the dev team looking at that.
I'll summarize what I had written.
• "Hamburger" is used in the title, but the article fails to mention it. Clickbait?
• As some users have already mentioned, this UI pattern is only effective on iOS devices. Android/Windows users will not be familiar with the bottom-toolbar approach.
• Websites are a different beast altogether, and the hamburger is slowly becoming a relevant pattern
Thanks for letting us know about the broken comments! I'll have a dev take a look.
To your points:
"Hamburger menu" is indeed mentioned in the article. I took the time to briefly define it and showed screenshots of the old (with hamburger) and new (with native tabs) designs. Not sure what you felt was missing?
Agreed that the placement of the menu is iOS specific, and I may have been too quick to suggest there will be NO hamburger in Android. UX team has the challenge to translate it for the platform so I don't expect an identical UI.
Totally: our lessons learned applied to a mobile app where feature discovery was key to repeated use. For an informational website, eCommerce, etc., clearing navigation out of the way of your key funnel may be worth the loss of clicks to hidden nav items.
Great write up!
I know this is an iOS app, but how do you think you might address it if creating it for Android where a bottom bar is discouraged? Would you try to see how the new floating button pattern holds up?
Did you try the sidebar with just your core features as the biggest text or give them different hierarchy?
Something like http://cdn.pttrns.com/pttrns/2586/original/IMG_4676.PNG
Would love to see how they apply this to Android. I had a really hard time designing a tab bar on android because of the OS nav bar. Any miss taps would result in exiting the app.
Tab bars on Android live at the top, under the action bar, for this reason. Did you start there, or start with a totally custom element?
Tab bars on top are contextual in Android. They are sort of sub-pages of one bigger page. You can't put app-wide navigation on top. To answer your question, that was one of the ideas I experimented with. Ran into a lot of problems.
Android users expect to swipe left to right anywhere on the screen to switch between those tabs. This would break a lot of our horizontal scroll functionality (Inline images, etc).
You also run into the problem of having actual contextual tabs on some pages and not having anywhere to put them. Tabs on tabs on tabs haha
Another issue was the action bar. Different pages in our app had to display different sets of buttons and actions, contextual tabs wouldn't allow for that.