Debate: cross-platform design consistency vs being "platform native" in design
-
The company I work for has two major mobile apps for our niche. Both are available on iOS and Android; the older one also has a Windows desktop version. But that latter platform is out of scope for this question.
Note: this in context of different codebases for each platform, using native languages (in our case, Swift for iOS and Kotlin for Android). Not using some sort of web/html/css/js or Xamarin "cross-platform" system.
Which do you prefer:
-
The visual design of the apps should, as much as feasible, be consistent between platforms. That means if one of them does navigation in a right-hand nav bar that slides out when you press a hamburger button, both should. If one uses a dropdown in a particular location, the other should as well. Ideally, if all you see is a screenshot stripped of anything that identifies the platform (like the top status bar), you shouldn't be able to easily guess which platform it's running on.
Pro: easier to design. You only have to do one set of mockups and wireframes and annotations.
Pro: Helping users is easier, since everything stays in the same place.
Pro: Anyone using multiple platforms will always know what they're doing, because it's all in the same place.
Pro: Visually distinct, which is good for branding (?)
Con: A pain to develop, because many design patterns and visual paradigms are either not present (dropdowns on iOS pre-iOS 15, for example) or are radically different. Frameworks push strongly toward platform conventions, requiring significant custom UI code, which tends to not adapt gracefully for sizes without additional work.
Con: Feels alien, breaks muscle memory (such as it is), especially around gestures. -
Each app should use platform conventions wherever possible, even if that means divergence. That could mean that one uses a sidebar/hamburger menu for navigation while the other uses a bottom tab bar. The apps will inevitably be trivial to distinguish by anyone who knows platform conventions.
Pro: Feels like a native app. Works with muscle memory
Pro: Easier to develop, can use native interface elements most of the time.
Con: Requires designers familiar with the different platforms and their conventions.
Con: Easy for apps to drift.
Con: User support requires more work.
-
-
Definitely 2. 1 is the choice of designer wankers who don’t care about making things work right for the platform, but do need it to look pixel perfect like in their special little
design they came up with.
If you look wrong on every platform, that’s not consistently good but just consistently wrong.Also, generally speaking, I don’t use your app on a dozen platforms, but I use a dozen apps on my single platform. If they each work the way they’re supposed to on the platform, that’s a lot less to learn for the user than if each behaves in unique, wrong ways.
Of course that assumes ideal world, spherical cow conditions. If you don’t have the resources to make either work well,
.
-
@topspin said in Debate: cross-platform design consistency vs being "platform native" in design:
Definitely 2. 1 is the choice of designer wankers who don’t care about making things work right for the platform, but do need it to look pixel perfect like in their special little
design they came up with.
If you look wrong on every platform, that’s not consistently good but just consistently wrong.Also, generally speaking, I don’t use your app on a dozen platforms, but I use a dozen apps on my single platform. If they each work the way they’re supposed to on the platform, that’s a lot less to learn for the user than if each behaves in unique, wrong ways.
Of course that assumes ideal world, spherical cow conditions. If you don’t have the resources to make either work well,
.I'll say that this is my preference. And I'm marshaling my reasoning, because our designer just left, so her preferences no longer matter.
I'm not going to propose redoing everything, but gaining flexibility to have the UIs of the two apps diverge and lean more on native elements and paradigms would be a major thing. I just fought one (relatively simple) change for 12 hours on a 4 hour ticket, because it just goes so far against Apple's preferences for UI design. And, frankly, doesn't look all that good.
-
2 is definitely The Right WayTM but I understand the maintenance overhead can be a pain. Especially if an OS update dictates a whole new UI paradigm to adapt to.
But if you're already using two different codebases for the two big platforms, I feel as though that overhead is already there. You already have to code for two different platforms, and that means testing on those platforms individually, so I don't think adding the UI differentiators really adds too much to that overhead. The drift and user support you mention in your Cons is already there.
To address some individual points:
Pro: Anyone using multiple platforms will always know what they're doing, because it's all in the same place.
The only people I know who use multiple platforms are developers who are testing on multiple platforms and folks who might, say, have an Android phone for their work and an iPhone for their personal cell. The former is moot because they wouldn't care. The latter is probably not a factor because I imagine most people would keep their apps on one phone and not the other. If your app is more for personal use, they'll only install it on their personal device. If it's for business, they'll likely only install it on their business phone.
In a way, this sort of really lends itself to what is good about option 2. I'm an Android guy. My wife uses iPhone. Whenever I use Grubhub on her phone, I get frustrated by the difference in UI, because they do follow the iOS conventions. Likewise when my wife uses my phone, she gets frustrated. But if the app didn't follow either of those conventions, we'd both be frustrated.
Pro: Visually distinct, which is good for branding (?)
This is entirely struck down as a Pro just by the "feels alien" con. Yes, it's visually distinct. If you designed a car with the shifter on the ceiling and the power windows operated from switches on the steering wheel, that'd be visually distinct too. That doesn't make it a good thing. Don't drink the marketing kool-aid!
Con: Requires designers familiar with the different platforms and their conventions.
If you are designing for a platform but don't know its conventions that's the
You gotta do the research to build a good product. I don't know what else to say.
-
I figure the main reason most people may end up on multiple platforms is phone + computer (assuming the app exists and makes sense on both). But those are different enough in format (and modes of interaction) that attempting to be consistent across them isn't going to be useful anyway. It'll just result in garbage on both ... or garbage on the computer, if you subscribe to the everything-is-a-smartphone idiocy.
Edit: That said, probably Option 2 over Option 1. Although I probably care less about this than applications randomly reorganizing their UI on a semi-regular basis for no apparent reason.
-
Nobody is consistent even with themselves between two pages anymore. "Platform-native" is a concept from the 90s that died in late 2000s and has been deader than Flash for some time.
Go for cross-platform consistency, if only because it reduces work needed. Nobody cares anyway, except people you can safely ignore because they're gonna figure things out anyway (ie. nerds). But keep the possibility of platform differences open in case Google Play's and App Store's verification teams don't agree on how you should do things.
-
As a general rule, I don't care about your company's app. I care about doing whatever task I'm using your company's app to do. So it should work like all the other apps on my phone.
Also, let's face it. If you're going to pick one set of UI conventions and use the wrong ones on the other platform, you're going to make Android users use Apple UI conventions. When you do that, it sends the message to me that your company is either too cheap or too lazy to support me as a customer.
-
@GuyWhoKilledBear said in Debate: cross-platform design consistency vs being "platform native" in design:
Also, let's face it. If you're going to pick one set of UI conventions and use the wrong ones on the other platform, you're going to make Android users use Apple UI conventions.
And vice versa, of course. And when you do neither you've given yourself the added job of coming up with a new UI vocabulary that is supposedly "better" than the native ones (else you'd be using those, is the perception) and implementing it with tooling that isn't geared to favour it.
-
@Watson Remember not to call them
Activity(Android),Page(Windows Phone),Scene(Flash and Unity and iOS Playgrounds),Window(desktop), orWindowGroup/DocumentGroup(iOS mainline).
-
@Watson said in Debate: cross-platform design consistency vs being "platform native" in design:
@GuyWhoKilledBear said in Debate: cross-platform design consistency vs being "platform native" in design:
Also, let's face it. If you're going to pick one set of UI conventions and use the wrong ones on the other platform, you're going to make Android users use Apple UI conventions.
And vice versa, of course. And when you do neither you've given yourself the added job of coming up with a new UI vocabulary that is supposedly "better" than the native ones (else you'd be using those, is the perception) and implementing it with tooling that isn't geared to favour it.
It would be just as much of a problem going the other way, but in my experience, we're usually talking about an app that runs on Android but uses Apple UI conventions because the designer is more likely to use Apple themselves.
-
@Watson said in Debate: cross-platform design consistency vs being "platform native" in design:
@GuyWhoKilledBear said in Debate: cross-platform design consistency vs being "platform native" in design:
Also, let's face it. If you're going to pick one set of UI conventions and use the wrong ones on the other platform, you're going to make Android users use Apple UI conventions.
And vice versa, of course. And when you do neither you've given yourself the added job of coming up with a new UI vocabulary that is supposedly "better" than the native ones (else you'd be using those, is the perception) and implementing it with tooling that isn't geared to favour it.
Of course this is the path we really chose. More specifically, we're using the same basic patterns as we do on the web. Which is
.Navigation? That's a side menu...on the right side (so not like Android, which generally goes on the left). Dropdowns on iOS? Got them. Abuse of UITableViews? Yup. Reinvented "modals" that aren't actually system sheets or dialogs, instead they're views plastered over the top of the main view (and look, frankly, hideous with the partial transparency). Etc.
-
@cvi said in Debate: cross-platform design consistency vs being "platform native" in design:
But those are different enough in format (and modes of interaction) that attempting to be consistent across them isn't going to be useful anyway. It'll just result in garbage on both ... or garbage on the computer, if you subscribe to the everything-is-a-smartphone idiocy.
QFFT!
-
@TwelveBaud said in Debate: cross-platform design consistency vs being "platform native" in design:
@Watson Remember not to call them
Activity(Android),Page(Windows Phone),Scene(Flash and Unity and iOS Playgrounds),Window(desktop), orWindowGroup/DocumentGroup(iOS mainline).No problem, I'll just call it a
Viewlike a civilized person! #TeamWPF
-
@Gąska said in Debate: cross-platform design consistency vs being "platform native" in design:
@TwelveBaud said in Debate: cross-platform design consistency vs being "platform native" in design:
@Watson Remember not to call them
Activity(Android),Page(Windows Phone),Scene(Flash and Unity and iOS Playgrounds),Window(desktop), orWindowGroup/DocumentGroup(iOS mainline).No problem, I'll just call it a
Viewlike a civilized person! #TeamWPFAndroid has those too!
-
@ObjectMike as does iOS.
-
@GuyWhoKilledBear said in Debate: cross-platform design consistency vs being "platform native" in design:
It would be just as much of a problem going the other way, but in my experience, we're usually talking about an app that runs on Android but uses Apple UI conventions because the designer is more likely to use Apple themselves.
Those are the worst.
I have actually stopped using apps on Android because they did not support the standard "back" button (or back-swipe these days, if I choose to configure it so). Instead there is always some weird way to go back because there is still no standard way after all those years of iOS development.
This looks like a very small thing, but becomes a major annoyance very quickly. Even for me as a user of multiple platforms (Android on phone, iOS on iPad, Windows and Linux on pc).
-
I'm in the option 2 camp.
And i don't think that much time is actually saved in the end by using "build once, bugfix everywhere" frameworks because you'll spend the time with chasing Steve crosspiling bugs instead of building something for each platform.
-
Another annoyance I regularly encounter: often-used actions on the top of the screen.
I generally hold my phone in one hand (left or right, being somewhat ambidexterous), and use my thumb for the screen. And I can't bloody reach the top of the screen that way.
I know that many applications require more interaction than just the thumb, so be it. But when not, just keep it in the bottom half of the screen!
-
@nerd4sale said in Debate: cross-platform design consistency vs being "platform native" in design:
Another annoyance I regularly encounter: often-used actions on the top of the screen.
I generally hold my phone in one hand (left or right, being somewhat ambidexterous), and use my thumb for the screen. And I can't bloody reach the top of the screen that way.
I know that many applications require more interaction than just the thumb, so be it. But when not, just keep it in the bottom half of the screen!I have size 12-13 hands so i can reach most of a phones screen onehanded, but I still do not buy phones with large screens because it's unpleasant to stretch the hand across a phone like that.
-
@Carnage said in Debate: cross-platform design consistency vs being "platform native" in design:
Steve crosspiling bugs
Any relation to Kevin?
-
I'm in the
camp. 
I'm joking, but actually no, not really. The path of least resistance is actually often a pretty good choice -- if you're picking it knowingly and not just because you're a moron or "meh".
You said that option 1 was forcing more work to shoe-horn UI ideas that are foreign to each platform. Ideally, there would be one platform where your UI originates from and that would be easy, but in practice it's likely you will end up picking bits and pieces from all platforms (does anyone else remember the "all the things" meme?) so none of the platforms will be easy to develop.
Almost everyone prefers option 2, and if I was only given the closed choice "1 or 2" I'd pick that as well. But the nice (?) thing about it is that, unless your framework is totally fucked (and if it were, then option 1 would not require more work!), going for option 2 will also require less work. Just let the framework do its thing.
There is the risk of code drift between the platforms, but in reality option 1 already has those -- except that instead of being in the visible UI, it's hidden in the hacks that you have to do to get the same UI. What do you prefer, code that is different in obvious and glaring ways ("menu is on the right or left"), or code that looks the same on the surface, but has subtle hidden tiny differences to work around each framework limitations?
User support is harder, but then again by using platform conventions you should also make user support easier within each platform as users won't ask you questions about UI that breaks conventions.
In my case I've solved that problem by using the same framework (Qt) on all our platforms (which are all desktop), and letting the framework decide where it can be platform-compliant and where it diverges. Of course the result is that my application looks neither "Mac" or "Windows", instead it looks "Qt", but the framework is "good enough" that it's not jarringly bad to users of either platform (or at least, the jarringness caused by the framework is less than the jarringness caused by our own code being TR
).
-
@remi said in Debate: cross-platform design consistency vs being "platform native" in design:
subtle hidden tiny differences
Yes. Those are much more fun. (For
definitions of fun.)
-
@HardwareGeek Somewhat related and it could go in another thread:
This week I (re?)discovered that in Qt,
QWidget::isVisible()is not the same as!QWidget::isHidden().That caused a subtle bug, because we were using one and not the other, that took me a few days to find out.
-
@remi said in Debate: cross-platform design consistency vs being "platform native" in design:
In my case I've solved that problem by using the same framework (Qt) on all our platforms
That's what we're using too, except we're working in an embedded environment, so cross platform issues are kinda moot. (QNX, Yocto, Ubuntu are all close enough)
For my personal stuff, I've been using wxWidgets for a while.
-
@remi said in Debate: cross-platform design consistency vs being "platform native" in design:
@HardwareGeek Somewhat related and it could go in another thread:
This week I (re?)discovered that in Qt,
QWidget::isVisible()is not the same as!QWidget::isHidden().TIL. Good to know...
-
@dcon In case you wonder:
A widget is "visible" basically when a user would consider it as such (ignoring things like "the widget is behind another window" or "outside of the screen"), so a widget inside a container that is itself hidden, is not visible.
OTOH, a widget is "hidden" only if that specific widget (regardless of its parent) has been explicitly hidden.
Specifically in my case, a sub-widget deep inside a tab widget that is showing another tab is not visible, but also not hidden. We have some code that can actually hide that sub-widget (inside its parent) and to check whether it was the case, our code should have checked whether it was hidden, not whether it was not-visible.
If you spend long enough thinking about it, it makes sense, both from the developer's point of view, and from the grammar-
's point of view ("hidden" is not "invisible"). But if you spend long enough thinking about it, it means you've not only lost that time, but also all the time that lead you to that.
-
@remi said in Debate: cross-platform design consistency vs being "platform native" in design:
@HardwareGeek Somewhat related and it could go in another thread:
This week I (re?)discovered that in Qt,
QWidget::isVisible()is not the same as!QWidget::isHidden().That caused a subtle bug, because we were using one and not the other, that took me a few days to find out.
That makes sense. I've never used Qt, and it's been ages since I did any GUI programming (using Swing, Tk, and decades ago I played a little with raw X; that way lies madness), but I seem to recall that
isVisible()or it's equivalent in other frameworks could be false if the widget was, say, obscured by another widget, or something like that. The widget is there, it's not hidden, and it will be visible by getting rid of whatever is in front of it.Edit:
-
@Benjamin-Hall I'm strongly against 2 because the less I have to touch XCode directly the better.
-
@Rhywden said in Debate: cross-platform design consistency vs being "platform native" in design:
@Benjamin-Hall I'm strongly against 2 because the less I have to touch XCode directly the better.
In that case, I'd say use something like Xamarin. Which is decidedly out of scope for us, but not a bad solution.
Because both 1 and 2 require mucking around in XCode a lot when you've got a native-language client for iOS.
