You Need to Build for the OS, Not Your Brand

I wanted to make a few notes to those developers who want their apps to have the same brand-overpowering ‘custom’ experience across operating systems.
First, you’re creating an experience for a specific operating system. Each OS has their own specific, special interaction model. For example, all three mobile OSes implement the ability to go back in an application, but they each do it differently.

You’re building for the user, not your brand. 99% of users will not have an iPhone, Nexus, and Lumia next to each other comparing each platform’s app. In fact, it’s probably just you, as a developer, and you shouldn’t be doing interface comparisons on completely different systems anyway. It’s bad practice.

Developers need to stop making their applications about them when it’s about the user. Your experience should not be vastly different from the rest of the device. There’s probably a reason they chose to use that device, so you’re basically giving them the shaft. That’s not a way to make users happy.

The Web has made developers think they can customize their native applications to the point they’ve been removed from the OS itself and what the user is expecting. Once again, the Web is not native, and native apps are not Web sites.

So, in summary:

  • Design your app to look and behave like a core application on the user’s operating system. It should say ‘iOS’ (or whatever you’re developing for), not ‘[Your Brand Here]’. You already have someone using your app, you don’t need to keep selling it to them. It will annoy them.
  • You aren’t the user. You’ve heard it before, but apparently some people need to hear it again.
  • Don’t go against the grain or break the host OS’s interaction model because you don’t like it. That’s not a good enough reason.
  • Don’t use a custom font for anything in the UI. The system font across all three platforms—Windows, iOS, and Android—have been designed for readability and consistency. Breaking that is jarring to the user. It’s a bad idea.
  • Don’t make the user’s experience of their own phone inconsistent.

User Expectations Regarding Files & Mobile Applications

There has been a fast foray by most business software companies into ultra-mobile computing. Microsoft is finally starting to catch up on non-Windows Phone devices with Office for Android. I say that they’re only starting because I met a critical flaw in their own application.

Mobile software has taught users—myself included—that you only need to save documents on full-fledged computers, not smartphones or light tablets (i.e., anything with an ARM chip). It’s great, because that’s one less step to do with a tiny keyboard on a tiny display using an interface that wasn’t designed for handling files.

In fact, it’s one of the intentional decisions made by Apple, and later Microsoft, with their respective mobile platforms: removing the file system from the average user’s view. This is great for most users: you don’t expose the underlying system, so the system appears less complex and it’s less intimidating up front for people who haven’t learned to use the system.

Apple took this step with OS X: they’ve hidden the Library folder in users’ home directories and have somewhat replaced their file browser from being the center of interaction when you first turn on a Mac by introducing Launchpad.

While the rest of the industry starts moving away from exposing the file system to non-power users (and Apple just hides it from everyone), the shift is clear: we don’t open files directly anymore. Instead, we always open applications to handle files.

Some developers have handled this well. Their apps automatically save changes, even to drafts. If the operating system terminates the application when it’s in the background, the file is safe and, to the user, the application’s state hasn’t changed when the user switches back to it. And there’s no need to worry about finding a place to save a file when you press Save; you just need to tap the name of the new document, Untitled, and type in a new name. It’s saved until the user tells the application to destroy it.

Now, here’s my gripe: a certain app for Android doesn’t do that. It still uses parts of the file metaphor (which is partly due to Android as a platform having a silly insistence on exposing the file system for normal users despite everyone else realizing it makes things more complicated) and, its most egregious sin, doesn’t autosave files or drafts.

I just lost an entire hour’s worth of fiction I wrote before sleeping that I’ll never be able to recover, because someone didn’t think about how the modern device’s user environment handles files as part of the industry’s standards, the platform, and the user experience.

If your application doesn’t automatically save changes, please warn me now so I can avoid it.