This year's iPhone design trend: Side navigation
inspiration.appflo.ws
inspiration.appflo.ws
Hopefully, Apple hasn't already patented this gesture.
Interestingly, the button that HAS died is the search button. Any device I've seen with a physical home button has opted for a long press to be the app switch, and then to leave the menu button in.
Personally, I like the menu button. It feels very natural on my SGSIII (and also did on my SGSI and Galaxy Tab). It feels weird to hunt for the soft menu button (either top or bottom) on my Nexus 7.
The only phone I can think of that doesn't have that is the Nexus.
Still getting used to it, but my initial impression is that it's a pretty slick interface.
That being said, it kind of reminds me of Windows Phone's swipe to the side. Windows Phone does give clues that there's more to the page by cutting off part of the edge. This is the default design language for Windows Phone.
On the iPhone, it almost looks like there's a built-in or popular library these developers are using to enable this. Any word on how this is accomplished?
In both cases, you simply have a front view and a rear view. All you need to do is adjust the frame (positioning) of one of the views and animate that transition. Animating view transitions is really easy in iOS. So the pseudo code for this basically becomes:
Menu.position.x = Menu.position.x + (.7*screensize);
Animate();
So, we tested the two navigation forms with users in our usability lab. We had 15 users come in and work on multiple devices with various mobile prototypes. We saw a clear case that users preferred a drop down menu located at top right. Users were mostly negative about the location of the left corner slide menu trigger as well as the triple line iconography that typically represents the slide menu button.
If you have a lot of different sections that does not require or option to drill down, then the 'Back' button isn't a major issue.
Hyper extending - how often does the button situated at the top left gets used? Less usage will be fine, more usage may require a more optimal location.
How many items are there in the menu? Are you using icons or just words? Side menu are great for future expansions/features and with an app like FB, where user can have alot of app attached to their acct, it's easier to navigate compared to a drop down/icons based nav.
Any chance to share the app that you guys tested for or is it still being developed?
The frequency of use is a variable between apps and users. Hopefully it's been taken into consider during UX / design.
This is what initiated our discussion. We simply didn't like the bottom menu bar that had 3 to 4 options and an elipses. The elipses takes you to another screen that lists the remaining options. It was a developing crutch for too many nav options. Our nav has 7 items this release and 8 to 9 next release. It is text only and the reason is because we limited each item to a 42px+ tap zones. We had issues with iconography as well as keeping it simple.
The opportunity for expansion is a positive feature of slide menus, no argument. In fact, that was the strongest argument for it initially and probably the single most reason if we convert to a slide at a later time. However, the counter argument is that if our navigation gets so wide as to scroll off screen then maybe we can reconsider the structure and revise. Opportunities abound.
I wish I could. It's in build phase slated for late Q4 release. Great counterpoints, btw.
It's nice to see some convergence in mobile UIs.
"The pronominal possessives hers, its, theirs, yours, and oneself have no apostrophe." - http://www.bartleby.com/141/strunk.html
Kudos to a person who stands on principle.
Why have a 40pt-high bar on screen all the time, when you usually have more than 4 sections anyway? And tab bars don't work on iPad at all, anyway.
Android's action bar is a bit better than iOS tab bars though, and I feel like Android tablets can actually get away with that quite well, without resorting to side nav. But if you're going to be consistent, you might as well use side nav across iOS and Android for all device types. It's worked really well for me so far.
I think it's an interesting trend, definitely a good use of space. Slightly bored of just seeing black ones pop out so it's nice seeing people use it to fit in with the app theme or leverage additional content in there.
Isn't this how iOS navigation has worked since its inception?!
The side navigation they're talking about is a "global" view that sits below your normal stack, that you can get to at any time. So instead of backing out to the top of the stack and selecting "read messages", now you can just gesture-swipe to the side and access the "main menu" directly from anywhere.
We're a fadish, looking for the next thing, get bored of things quickly bunch of primates, aren't we?
We've come so far in terms of UX and usability that we forget that the icing on top of the cake is all about what's in vogue.
Apple skuemorphism (granddad) vs. Windows <srikeout>Metro</strikeout> is apparently the new black vs. white.
The icon for side scrolling (three stacked lines) is dire. It's a shitty, unintuitive adopted practice because Facebook and a few other players did it.
meh.
> The icon for side scrolling (three stacked lines) is dire.
> It's a shitty, unintuitive adopted practice because Facebook and a
> few other players did it.
Hope that helps!
Unfortunately, the back button was placed there because it is just out of reach for most users to prevent accidental taps. Now that you bring it up, since some of these sliders are actually used quite often it doesn't quite make sense to have these menus exclusively triggered by a button in the top left.
I guess it could have also been due to the resemblance to a menu and most "file" commands were traditionally in the top left.
So, yes, we're asking the user to move a bit more, but I wouldn't call it impossible. Making a completely one-handed UI would mean breaking a lot of conventions.
Your comment does reflect the design struggles of Android, with it's varying screen sizes. What is a one-handed reach for most people on one phone may not be a one-handed reach for most people on another phone.
Deleted comment