This year's iPhone design trend: Side navigation(inspiration.appflo.ws)
inspiration.appflo.ws
This year's iPhone design trend: Side navigation
http://inspiration.appflo.ws/orozpotk/this-years-iphone-design-trend-side-navigation
24 comments
I first noticed this on Android. Dolphin Browser has done this for years now. Swipe to the left side (by swiping right) to get to bookmarks, etc. Swipe to the right side to get to add ons.
In android 4.0 browser (don't know about earlier versions) there a mode to "save space" where the menu only comes out with a swipe from the border.
Hopefully, Apple hasn't already patented this gesture.
Hopefully, Apple hasn't already patented this gesture.
In fact, I think it's an Android trend that has migrated to iOS. It works better on Android, IMO, with its hardware menu button.
The hardware menu button is dead starting with Android 3.0 released 1.5 years ago.
Google said it was no longer "required" but even through 4.1 SDK it is still supported.
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.
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.
Latest version of Dolphin (on iOS, anyway) remixes this a bit. Swiping left still goes to bookmarks. But now swiping right goes to tabs. There's a button bar on the bottom, and a navbar on the top. Both of these automatically disappear when you scroll down, and automatically reappear when you scroll up.
Still getting used to it, but my initial impression is that it's a pretty slick interface.
Still getting used to it, but my initial impression is that it's a pretty slick interface.
I wrote a UIViewController container subclass to do this behavior: https://github.com/edgecase/ECSlidingViewController
it is really good. thank you so much
Not having an iPhone: how do you access this side navigation? I don't immediately see any clues in the app. Is it the buttons near the top (three horizontal lines)?
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?
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?
It's actually really simple. There's actually two different modes, but they're accomplished the same way. One is that menu is off screen and slides in to overlap the normal view. The second is the the view is in the background, and the normal view slides off to reveal the menu.
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();
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();
Yeah, I was wondering more if this was baked-in, or if there was a framework handling it, or if someone just saw another developer doing it and everyone decided it looked nice and implemented it on their own. They all look incredibly similar.
Come on, there's a little more to it than that... nested view controllers and all.
Yeah, it's the three lines button. I find it kinda jarring not having any visual indication from the button that it's going to be sliding. Would be interesting to experiment with making it look more like a tab you can use to pull the content to the side with or something like that.
We were faced with the choice to design the navigation form with our current project. We narrowed it down to the slide menu and the drop down menu formats. I had hesitation with the slide menu as it offers some additional features, however it has some big issues. It typically sits in the upper left corner. Look at any mobile study (Luke W, perhaps) and you'll see the reach zones with users' hands. The right hand hold of the device causes the user to hyperextend their thumb to reach. Additionally, the top left location is sometimes reserved for a Back button in a linear flowing app.
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.
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.
It all depends on the usage and context of the app. Each method has their cases where it's optimal.
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?
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?
You're absolutely correct. It's always best to consider all the characteristics of the app design. So, I'd like to hear your alternatives to a Back button in your experience. Even the example linked below, Sidetap http://http://sidetap.it/, it toggles between the menu button and the Back button. An anti-pattern that I wouldn't really recommend.
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.
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.
Reminds me of the panoramic navigation concept behind Metro (yes, yes, I'll eventually call it Modern, I guess).
Seems this is a general mobile trend, not just iPhone: http://www.androiduipatterns.com/2012/06/emerging-ui-pattern...
It's nice to see some convergence in mobile UIs.
It's nice to see some convergence in mobile UIs.
The improper usage of "it's" as possessive made it impossible for me to read this:
"The pronominal possessives hers, its, theirs, yours, and oneself have no apostrophe." - http://www.bartleby.com/141/strunk.html
"The pronominal possessives hers, its, theirs, yours, and oneself have no apostrophe." - http://www.bartleby.com/141/strunk.html
> The improper usage of "it's" as possessive made it impossible for me to read this ...
Kudos to a person who stands on principle.
Kudos to a person who stands on principle.
This is a great trend. I just implemented it in two apps (iOS and Android). The only time I tolerate tab bars anymore is if it's a reader-type app that hides the nav and tab bars when you start reading.
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.
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.
The Facebook app has been doing this for so long, and is used by so many, that other apps are following the pattern. I would not be surprised to see this formalized as a controller/view class in the sdk at some point.
The only app where, to me, this type of navigation has been a hinderance is on Remember The Milk (RTM). The older interface was much easier to use - swipe/tap/type and you were done. Now I have to swipe/tap/swipe/tap/type to accomplish the same things. Probably just a UI/UX issue but it was clearly one of those, "Hey - Facebook is using this new strategy so we want to do it too!" things rather than a features-first type of overhaul.
Out of curiosity which came first, side nav in Path or side nav in Facebook? I've been trying to figure it out for a while, or am I off base and someone else did it first and they just took it and ran?
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.
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.
And I think it's great. It solves a lot of problems with navigation on mobile by giving you a near-screenfull (or more) to work with.
Unlike any of the other apps we featured with side navigation, Google Plus slides the entire previous page out of view when the user goes to the side menu. Will this be the next trend for side navigation?
Isn't this how iOS navigation has worked since its inception?!
Isn't this how iOS navigation has worked since its inception?!
No, you're thinking about the navigation controller, which is basically a deep stack of views that you can travel between.
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.
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.
A lot of people are mentioning this was brought over from Android, but it reminds me the most of WebOS (Enyo, really). I've had my TouchPad longer than my Android tab, so I can't say whether this was common on Android first.
This type of broad trend analysis is really useful and should be done more often. It's these types of interactions that become "intuitive".
...and then passé.
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.
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.
I won't comment on all of this (rather pointless) rant, but just last points:
> 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.
Thanks much! We're planning a series of trend analysis for the Fall, across both iPhone and iPad. We'll be posting on twitter, @appflows
Does anyone have a link explaining how to adding swipe or click to a side navigation bar to a webapp rather than these native examples?
Actually, when we were designing the AppFlo.ws interface, we considered doing this to show/hide the caption area on the right. This JQuery plugin is pretty slick and there are demos on the page: http://srobbin.com/jquery-plugins/pageslide/
Hope that helps!
Hope that helps!
This was definitely and Android design trend that has come across to the iOS dev space.
Hate the button on the left side. Usage on a 4,7" phone is not possible with one hand.
this is actually a great point. Presumably, the top left corner was used because that is the placement for the "back" or "previous" button.
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.
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.
Android's tab UI (in the ActionBar) already has this problem. And iOS has always used the upper-left for the navigation bar's "back" button anyway. The menu button is just a different sort of back button when you're at the top of a particular hierarchy.
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.
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.
These look like mostly iOS apps, targeted to a smaller screen. So it's not quite such a struggle for iPhone users.
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.
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.
Thank god tab bars are dead.
May be wrong, but didn't Twitter for iPad pioneer this?
Twitter used this to bring links and images in from the stream but as far as I know the menu was never accessed this way. It does look extremely similar and probably had something do with the way path implemented the feature
[deleted]
[deleted](2)
@freehunter, yep, you access it by hitting the button near the top. You may want to check out sidetap, a mobile framework that allows you to build side nav: You may want to look at http://sidetap.it/