With 320x480 iPhone screens, we had to be economical for navigation, tools, and the content view. (BTW, the content view is UI. The entire app is UI.)
Screens got wider and taller, which gave us more space for the content view, without having to sacrifice navigation and tools.
But look what happened. In many cases, it actually got much worse, with vertical space eaten up by things that were never even visible before.
So why are we now sacrificing navigation and tools?
It’s not “just nostalgia.” The original iPhone’s size constraint made for tough decisions that led to incredibly clear and usable UI.
But when given more space, just like extra lanes on a highway, they just got filled up. Instead of giving more space to the “content,” it actually gave more space to “UI.”
The very thing Alan Dye pretends to be saving us from is a problem he is responsible for creating. It wasn’t always this way. He made it this way.
There’s no reason for any of us to think Alan Dye has a better idea of how to make apps than you do, when you probably have more experience with making your app than he has running Apple’s design team.
So, trust your own instincts. You know your customers. You know the device. You don’t have to do things the way Apple is. You can still be on the platform and do things better.
Think different.
There’s a reason that we have the term “back to basics.” It’s a good thought process to recall what once was, the core components of what are necessary. You can design around those to create a great UI.
With fewer constraints, it gives more flexibility to more missteps. So with larger screens, we actually have more opportunities to screw up. And not just us, but Apple themselves.
When designing modern apps, it’s really valuable to look at the original iPhone OS to understand what made it good.
I think Apple has long forgotten what core components exist for apps.
Whatever your app is, your app will make sense to users if they can see and understand all the core components of your app. If you hide them inside of your UI through menus, you will make your app’s features invisible to users. Hiding tab bar items? Hiding tools behind a menu? Those choices don’t help a user understand what they can do.
It’d be bad advice to follow Apple’s lead. They’re no longer leading with good examples.
Apple has often been a north star for developers when creating their own apps. Looking at what Apple is currently doing has almost always been good advice, because you get to lean on Apple’s own design process, their expertise, and their platform knowledge to save time making decisions with your own app.
But as it becomes clear that they are being led in a bad direction from someone who doesn’t understand software design, it comes down to you and your own judgment when designing your app.
@louie as one of your followers (and blog readers) I find additional value of blog posts in how easy they are to find them when I want to read them again (yes, I do read some blog posts more than once).
Hope you find this helpful
@louie Turning long threads into blog posts is good practice, I think.
Several of my most read posts (even some I reference the most) started out as an outsized discussion thread that I migrated to a blog post.
@louie Yeah, I reject the basic premise of a strict dichotomy of “content” vs. “UI”. That sort of makes sense for some contexts, like a photo browser or a video player, but there are plenty where the “content” of an app would be its controls. Not everything is passive browsing.
UI isn’t some shameful thing to hide away!
Holland Heese
Louie Mantia, Jr.
Cai
Kostiantyn Tymoshenko
ArneBab
Steve Roy
Ryan the Design Lion
Brandon Butler
Benjamin Gibbs