4 ms·

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 requi

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?

timmins 14y ago
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/ 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.

timmins 14y ago

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/ 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.