Most apps use this navigation style in their table-views:
Your eyes tend to follow the selected list element off to the left of the screen, and then you have to scan the new screen until you find the important stuff at the top. In this case, the item you select is a Facebook icon. After you follow it off of the screen, you then have to scan for the important stuff on the new screen, and what is it? Another Facebook icon.
You lose a lot of context, end up scanning the screen for new information, and at the end of it all you’re looking at the same darn thing.
When you tap an item in a list, all of the irrelevant nonsense should fade away, and the important stuff should stay in a prominent position. Jarod and I tried this in our most recent app, Fini:
What if the user selects an item from the bottom of the list? What ever shall we do?
The important stuff should move to the new position. But normal movements are boring. So we made ours bounce:
If we adopt this new method, then what purpose does the nav-bar serve? None? Yea, we thought so. So we tried removing it (kinda):
The issue is that we already had our hamburger-menu button there. And that’s important!
This is difficult to program. Sharing an element between multiple views isn’t as straight-forward as you might think.
For really complex menus, like the iPhone Settings Menu, it’s more important to have navigational context than it is to maintain focus on prominent items between views. In these cases, the card-style navigation is justified. However, most apps have really short, 2-layer navigation from their list-views. And the developers of these apps should invest just a little bit of thought into how users interact with these menus. Like we did. We’re awesome.
Also, our transitions look a lot better in the real-time framerates (as opposed to these gif’s on the site). You should download our app and see for yourself here.