Live data from Hacker News

This year's iPhone design trend: Side navigation

inspiration.appflo.ws

51–59 of 59 posts

Re: This year's iPhone design trend: Side navigation

#51
post #23

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 Metro is apparently the new black vs. white. The icon for side scrolling (three stacked lines) is dire. It's a shitty, unintuitive…

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. 
What would you offers as an alternative? This solution is used to reveal menu. Menu is a list of items. Three lines represent a list of items.

  > It's a shitty, unintuitive adopted practice because Facebook and a
  > few other players did it.
What exactly makes it shitty? How is it not intuitive? Even if you don't know what a button with three lines does it does not take a lot of intuition to try and tap said button. Once you tap it you see what it does. Then you see the same in the other apps.

Re: This year's iPhone design trend: Side navigation

#52
post #41

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…

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…

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.

Re: This year's iPhone design trend: Side navigation

#55
post #43
post #22

Earlier quoted context omitted.

The hardware menu button is dead starting with Android 3.0 released 1.5 years ago.

What about all the phones that have launched with 4.0 and hardware menu buttons?

What about them? Relying on the menu button is a very, very, very bad idea because there are devices that it doesn't exist on.

Re: This year's iPhone design trend: Side navigation

#56
post #48
post #22

Earlier quoted context omitted.

The hardware menu button is dead starting with Android 3.0 released 1.5 years ago.

Except my GS3 has one, and released on 4.0 with 4.1 due out very soon. The only phone I can think of that doesn't have that is the Nexus.

HTC's new phones, every single tablet released after Honeycomb.

Re: This year's iPhone design trend: Side navigation

#57
post #22

Earlier quoted context omitted.

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.

Re: This year's iPhone design trend: Side navigation

#58

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…

facebook was 1st I believe

They both came after the Android Google+ app...

Re: This year's iPhone design trend: Side navigation

#59

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
Post reply on HN