Where are Android's User Interface Guidelines?

The answer, it seems, is “nowhere.” As far as I can tell, there are no user interface guidelines for Android. Microsoft provides design guidelines for Windows Mobile. Apple has pretty good iPhone Human Interface Guidelines, for web sites designed for the iPhone as well as for native iPhone applications. Even Symbian has some usability documentation. Google, it seems, has nothing.

Will this hurt Android?

Well, go and take a look at the results of the Android Developer Challenge. Download the Top 50 Slideshow (pdf) and look at the screenshots.

In my opinion, from a UI standpoint, the results are rather sad. Don’t get me wrong, the applications themselves are awesome. There are some great, great ideas, and I will definitely pick up an Android phone as soon as I can. However, the user interfaces are all over the place.

There is no consistency. Many applications invent their own iconography and nomenclature for things. Most applications have custom buttons, windows, color schemes and widgets. Applications use different typefaces and font sizes, sometimes inconsistent within the same screen. The icon style seems to be undefined; some use flat icons, some have realistic pseudo-3D icons, some have even other icon styles; they all look different from each other.

Even worse, many applications have small, tightly placed buttons. These interfaces will be useless without a stylus; it seems these apps were designed to run inside the Android emulator, where they can be controlled using a mouse.

Frankly, while most of the application ideas themselves are awesome, the inconsistent (and, in a few cases, just poor) UI design is disheartening. Hopefully, these UI issues will be fixed before users get to try these applications.

June 7th, 2008 / Tags: Google, Symbian, Apple, iPhone, Microsoft, Windows Mobile, Nokia / Trackback

MDIs on the Mac

Way back when the first graphical user interfaces were created, Apple and Microsoft went similar ways. Both used the desktop metaphor with files and folders, both had overlapping windows which showed documents and folder contents. However, they also took different paths for a few fundamental UI concepts. Apple had the “always on top” menu bar, while Microsoft put the menu bar inside windows. Apple went with an application-centric model, where each application could only be launched once but have many windows, while Microsoft went with a document-centric approach, where applications would sometimes launch multiple times.

The Multiple Document Interface — Apple very strongly went with the idea that each document corresponds to exactly one window, while Microsoft introduced a concept called the “Multiple Document Interface” (MDI), which allowed applications to have hierarchical windows: document windows reside under a parent application window.

MDIs have some advantages; they naturally help reduce clutter by grouping windows. They make it easy to hide all windows for a given application. If you tend to use applications in full-screen mode, having a MDI makes sure you really only see the active application and no other application.

Either way, Mac applications never had MDIs.

The times, they are a-changing

Mac applications used to have many windows. Recently, this has started to change, mainly due to Apple’s influence. Mac applications such as iPhoto, iTunes, iMovie, Aperture or iDVD tend to only have one window.

However, these applications do not have MDIs. Neither of these applications are multi-document applications. They are either media managers (iPhoto, iTunes, Aperture), or they are typically used to open only one document at a time (iMovie, iDVD).

MDIs on the Mac — Unfortunately, some companies have taken Apple’s new one-window-approach to UI design as a hint that they should introduce MDIs (or an MDI-like approach to UI design) on the Mac. Nolobe’s Iris, otherwise a very capable program, is such an application: Note the list of open images in the bottom row of the single window.

Adobe’s CS4 applications will also use MDI on the Mac (albeit only optionally - one can only hope that it will not be the default choice): Note the tabs above the image.

MDIs on the Mac are generally a very bad idea.

So why are MDIs on the Mac a bad idea?

Glad you asked. There are many reasons why MDIs are a bad idea; some of them generic, some of them due to how the Mac normally works.

Why MDIs are bad in general —

Please note that these lists are not exhaustive; also, not all of these points apply to all MDI applications. To name one example, Adobe has gone to great lengths to make sure their MDI would work around almost all of the issues in this list.

• Most modern computers support multiple screens, and a lot of people make use of this feature. MDIs don’t support multiple screens; since all of your documents are inside one window, you can’t put one document on one screen, and another document on another screen. Note that in the CS4 UI, it’s possible to pull document windows out of the main window, so this criticism does not apply.
• MDIs often make it hard to compare several documents belonging to the same application, or to view them side-by-side. CS4 supports tiled views to allow for this.
• MDIs make it hard to drag from one document to another inside the same application. In Photoshop, dragging layers between applications is something I do daily. MDIs make this hard (or even impossible, depending on the implementation), and force the user to copy-and-paste instead. Adobe’s CS4 UI supports spring-loaded tabs, which isn’t quite as good as direct drag-and-drop, but should be a workable solution.
• Some implementations of MDI make it hard to remove palettes from the main window. This is bad because in a multi-screen environment, a typical setup is to move all palettes to one screen, while keeping documents on the other screen. Again, the CS4 UI allows for this, so no complaints here
• MDI takes away space on larger screens. After your screen reaches a certain size, it doesn’t make much sense to maximize windows anymore. Having an MDI means you always waste space with a ton of application chrome around your documents - space which could be used by other applications running at the same time. Again, CS4 has a solution for this; hitting tab removes the application chrome (although I wasn’t able to get it back easily - hitting tab again did nothing at all). Unfortunately, the application chrome is not hidden if the application is put in the background while in MDI mode.

Why MDIs are especially bad on Macs —

As if these reasons were not enough, there are a few additional reasons unique to Macs:

• MDIs break Spaces. You can’t have one document in one space and another document in another space if all documents must reside inside the same window.
• MDIs (including tabbed browsers) break Exposé. This is what happens when you activate Exposé in Fireworks when the MDI is active:

Obviously, it’s entirely useless. This is what happens with the MDI turned off:

Much better.

By the way, Adobe, “zoom to fit” is currently broken and maximizes windows instead of zooming to fit their content - yet another Windows behaviour that has no place on the Mac. Also, the little “this document contains unsaved changes” dot in the close button does not work, which is probably another result of the MDI; UI elements don’t need to look the same in all apps, but if they look similar, they need to behave the same so as not to confuse users.

What Adobe did right, and what they did wrong — Adobe actually implemented workarounds for most issues I list. However, they are often non-obvious. Furthermore, if other applications with MDIs try to fix these same issues, they will most likely find different solutions, creating an inconsistent user experience.

Since there is no history of MDI applications on the Mac, and since Apple doesn’t have anything similar to these applications, there are no established UI guidelines. Hence, MDI-based applications confuse users since they behave inconsistently with each other.

Replacing an obvious, consistent solution to a problem with a non-obvious, inconsistent solution is generally a bad idea, unless the new solution is shown to be considerably better than the old solution (as an example for this, check out the Ribbon UI in new versions of Word for Windows - it’s non-obvious and inconsistent with other Windows apps, but it’s so much better than earlier versions of Word that the change is worth the issues it causes).

In this case, consistency with the host OS and its applications seems a lot more important than consistency with different versions of the same application.¹ In my opinion, the Mac version of Photoshop should look and (especially) behave like a Mac application, rather than like the Windows version of Photoshop.²

I should point out that I don’t have access to Adobe’s UI test results. One would hope that they did usability tests and found that the new UI is much more usable for Mac users than the old one before deciding to go with the MDI UI on all platforms. If so, changing to the new UI is the right thing to do.

Apple is to blame, too

Apple itself has at least one document-centric MDI application, too: Safari. The fact that Apple has an application which uses tabs to switch between several documents inside one window is probably partially to blame for the recent third-party enthusiasm for MDI apps on the Mac.

Originally, tabs were not meant to switch between documents. They were meant to organize “things” (such as settings) into groups of similar “things”, or - at most - to switch between different views of the same document. Not so switch between different documents.

It is kind of unfair to blame Apple for introducing tabs in Safari - after all, users demanded the feature, and Safari’s tabs are turned off by default (something other developers should copy if they insist on bringing MDIs to the Mac). It’s just very unfortunate Apple’s choice helped usher in a new era of MDIs on the Mac.

Conclusion

MDIs are bad news on the Mac because they break a lot of behaviours Mac users are used to. They should be avoided.

Addendum: John Nack replies to my blog post (scroll down to the comment linking to this post). He points out that most of my criticism of MDIs doesn’t apply to the CS4 UI since it’s possible to have (tabbed or single) windows outside the main window (Admittedly, I noticed this while trying the Fireworks prerelease, but actually thought it was due to a bug because I wasn’t exactly sure how I ended up in this state).

He furthermore thinks that it’s Apple’s fault for not giving developers a way of supporting Exposé for tabbed windows, with which I agree; still, Apple doesn’t force anyone to create interfaces which don’t support Exposé :-)

I’ve updated this post to reflect the fact that CS4 provides solutions for most issues MDIs normally cause.

Addendum 2: I mistakenly claimed that Final Cut Pro was a one-window application. This is false: I have not used FCP in a while and misremembered how its UI works. While FCP looks like a one-window application, the different areas of the UI are actually individual non-standard windows. Thanks to Ben De Rydt for pointing this out to me.

Addendum 3: Mike Lee, the world’s toughest programmer, disagrees with much of what I write, essentially saying that the concept of an MDI is not in itself flawed, but that it’s a question of context (how is the application in question used?) and implementation. He makes some good points, and furthermore calls me “chef,” so I recommend that you read his post. Also, who wants beef with the world’s toughest programmer? Not me!

I do have to take exception with two things he says, though.

He claims that it is false to differentiate between media managers and document-based applications. He does not, however, explain why this is false, except for pointing out that both Photoshop and iPhoto work with “media.” However, iPhoto is not a media manager due to the fact that “the documents in question are media.” iPhoto is a media manager because its main use is in managing your data. Faulting a media manager for having multiple documents in one window would be akin to faulting the Finder for allowing more than one file in a folder: In the application’s model, you are typically working with representations of your documents, not with the documents themselves.

Then, just after writing that “nobody likes Adobe,” Mike claims that I did not use Photoshop as an example “because people like Photoshop.” This is not why I used Fireworks. I went with Fireworks instead of Photoshop because I do not have access to a Photoshop beta, only to a Fireworks beta. The two share the same user interface, so any criticism I have made applies to both applications equally.

June 7th, 2008 / Tags: MDI, UI, usability, HIG, Apple, Iris, Nolobe, Adobe, Photoshop, Fireworks / Trackback

Preferences Considered Harmful

Every programmer and user interface designer eventually comes to this point: You can’t decide how a specific part of your user interface should behave. It’s easy, of course. Just make it a preference, and everyone will be happy.

After a few years, you will end up with a preference window looking like this:

BBEdit has so many preferences that Bare Bones Software actually included a full-featured search function within the preferences window. At one point during BBEdit’s existence, somebody must have been annoyed with BBEdit’s default window stacking algorithm and requested that it be made a preference. Here it is:

BBEdit actually allows you to select the window stacking algorithm. I’m sure somebody, somewhere absolutely needed that feature, but by implementing it, Bare Bones Software forced everyone else to also consider that preference when trying to change a setting.

Now, I want to make it clear that I don’t fault Bare Bones Software for this. Their audience is a diverse set of power users. Programmers, writers, sysadmins and other high-end Mac users all use BBEdit for vastly different tasks, which is why BBEdit has ended up with a huge set of preferences.

However, unless you’re working for Bare Bones Software, your product probably is no BBEdit.

For most applications, the target audience consists of — or at least includes — casual users. These users easily get confused by preferences, and they can become frustrated when they attempt to use a familiar application where somebody has changed preferences.

For this reason, it’s best to avoid preferences.

Configurations aren’t Preferences

Not every item you find in an application’s preference window actually is a preference. Before talking more about how you can avoid preferences, I want to define what I mean by the word “preference.” I find it useful to distinguish between configurations and preferences.

Configurations

When a given feature of your computer needs you to change settings to make it work, this is a configuration. For example, most entries in “System Preferences” aren’t preferences at all. You don’t “prefer” to turn on Screen Sharing; turning on and setting up Screen Sharing is part of your system’s configuration. You don’t “prefer” that only some users have access to your computer’s screen; you configure your system so only some users can access it:

Preferences

Changing a preference does not change the functionality of an appliation. It only changes the look or (superficially) the behaviour of an application. Often, preferences are introduced to appease a specific group of users. For example, when Apple introduced Mac OS X, a lot of preferences were introduced to make OS X behave more like Mac OS 9.

On NeXT systems, both scroll bar arrows were at the same end of each scroll bar, while on Mac OS 9 and earlier, they were on opposite ends. Instead of deciding on one behaviour, Apple simply made it a preference:

Additionally, Apple added a hidden preference for those who wanted both arrows on both ends.

Why preferences are bad

There are several reasons why cluttering the settings windows with unnecessary preferences is bad.

First of all, it is confusing to people who have legitimate reasons for changing settings. If you want to find out how to change your Dock size, you don’t want to work your way through a list of preferences which includes useless settings about how windows look while they minimize.

Often, applications’ preference windows are cluttered and confusing to the point where it becomes unclear whether something can’t be changed, or whether you simply missed the option in the flood of checkboxes.

Second, it makes applications inconsistent. If a user is used to a system where the Finder’s “Always open folders in a new window” setting is enabled, he can easily become confused and frustrated on systems where this is disabled. If a user is used to getting a warning before emptying the trash, he could easily inadvertently delete files on a system where that warning is turned off. And if he is used to a system where the Finder opens blank DVDs, he could quickly get stumped when a system instead opens iTunes.

Third, it makes reproducing errors harder. The more preferences there are, the more code paths you generate. Trying to reproduce user issues can quickly become a nightmare if you first have to reproduce specific sets of preferences.

How to avoid preferences

So, if preferences cause so many issues, how can you avoid them?

Say no to users

Sometimes, it’s better to lose a few users than to endanger the application’s overall health. Perhaps having pink windows simply isn’t in the application’s best interest, and if not having pink windows means having a few customers less, so be it.

Decide on the best behaviour and run with it

If at all possible, get rid of preferences and go with the most desirable behaviour instead. Often, interface guidelines state how an application should behave. Adhering to the standards not only helps you get rid of preferences, but also helps you be consistent with other applications, which makes your application behave in a manner predictable to your users. If the interface guidelines don’t specify how your application should behave, an ad-hoc usability test should help you decide which behaviour is preferable. Create versions of your application with both behaviour and let some users who have never seen the specific function use the app while you look over their shoulders. Which behaviour do they grasp more easily?

For most preferences, there is one option which works better. Find out which this is, and make it the standard behaviour.

Remember the application’s state

Often, you can avoid preferences by keeping track of what the user is doing. Instead of letting the user specify default data, remember the most recent actual data he generated. If the user switches to list view to see his “things,” open in list view by default. If the user opens a window and turns the toolbar off, remember that for the next window he opens. If the user sorts list entries by date, remember that the next time he opens the application. Always remember window size and position, and when the user has to enter data, try to provide reasonable default data.

Be careful not to be too clever, though. Adapting the UI to statistical analysis of user behaviour typically leads to a frustrating user experience, because the user interface becomes non-deterministic from the user’s point of view. Make sure the rules used are always obvious to the user.

If you can’t avoid preferences

There are cases where you simply can’t avoid preferences. If this occurs, make sure you spend time on finding reasonable defaults, and on labeling them in a way which is obvious to users.

What about an “Advanced” section?

Some applications try to de-clutter preferences by partitioning them into a “regular” and an “advanced” section. I would avoid this because the difference between normal preferences and “advanced” preferences is arbitrary. If you’re looking for a specific setting, having an “advanced” section means you have to hunt through additional screens.

May 18th, 2008 / Tags: prefernces, bbedit, bare bones software, apple, finder, usability / Trackback

Installing Applications on the Mac is Broken

When recently visiting my parents, my dad asked me to help him install Firefox on his Mac. He was able to download the application just fine, but actually installing it proved a bit more confusing. The reason for this is that installing applications under Mac OS X is essentially broken.

How it used to be —- Installing apps on a Mac used to be simple. In Mac OS 9 and earlier versions, you would typically download a StuffIt file. All Macs came with StuffIt Expander, which would open the .sit file, put the contained application or a folder with the application in its place, and remove the .sit file. You could then simply use the application right where it was, or you could move it somewhere else. That is not the case anymore.

How it is today —- Apple probably realized that relying on a third-party application for installing apps was not a good idea. So they stopped bundling StuffIt Expander with Mac OS X. Instead, developers started to abuse images to deliver downloadable applications. Nowadays, most Mac applications come on .dmgs. After the user downloads the application, Mac OS X mounts the image. The user is then supposed to drag the application to the applications folder, unmount the image’s volume and throw the .dmg to the Trash. This is too complicated. Most “normal” Mac users don’t understand that the application on the mounted .dmg is not really on their system. They start the application from the .dmg and end up confused when it disappears after a restart. To fix this, developers started adding instructions to the mounted dmg’s window. Here’s how’s Adium’s mounted image window looks:

The picture is supposed to show the user that he should drag the Adium icon to the Applications icon. Of course, this is still too confusing for many users. Even worse, it doesn’t work like this for all applications. Here is the mounted image window for the aforementioned Firefox:

If you thought you could actually drag the Firefox icon to the Applications folder icon, well, tough luck. The Application folder icon isn’t actually an icon at all, it’s part of the background image. The idea is that you open a second window and drag the Firefox icon to the second window’s Applications folder.

These are more than two kinds of Mac “installers.” Google (among other companies) rolls its own installation thing. Adobe uses a third-party for its installers, which are often less than perfect. Some applications use what Apple confusingly calls “internet-enabled images.” These are images which, upon double-clicking, replace themselves with their content and then move the .dmg file to the Trash. Obviously, Apple saw the issue with images and tried to fix them, but only managed to create additional confusion. And of course, Apple doesn’t use any of these solutions. Apple generally delivers its software as normal .dmg files with files which start Apple’s own installer application. Some applications have now started alerting the user when they are launched from a mounted .dmg, asking whether they should move themselves to the Applications folder.

All told, installing applications on the Mac has become inconsistent, confusing, and just plain broken. It’s time for some kind of usable standardized consistent behaviour to emerge. Perhaps having the application work as its own installer, asking the user whether it should move itself to the Applications folder if it’s launched from a .dmg (and afterwards ejecting the .dmg, and launching the installed application, as wel as optinally installing an icon in the Dock), would be a good first step.

Addendum: Michel Fortin, author of the excellent Sim Daltonism, a color blindness simulator which I use to test user interfaces for “compatibility” with color-blind people, has an article on the subject. His solution is to provide applications as downloadable ZIP files. Safari will open such files automatically, replicating how Mac OS used to work before OS X. This is a reasonable solution; the issue I see with this is that downloadable .dmg files have trained people to expect some kind of window showing the new application to open automatically. Downloadable ZIP files simply place the application in the downloads folder, where the user may then promptly forget about them.

Addendum 2: Versions, a Mac Subersion client, throws up a dialog box saying “Versions is downloading, you’ll find it in your downloads folder.” after you click on the download link. The download itself is a ZIP file. Quite a neat solution, I think.

April 6th, 2008 / Tags: mac os x, apple, installer, firefox, adium, user interface, usability / Trackback

Code Signing on the iPhone and on Mac OS X

Mike Ash of Rogue Amoeba has written a fantastic article about code signing, and about how Apple is using it in Mac OS X and on the iPhone.

if Apple doesn’t sign your iPhone app, it does not run. Even for local development, you need to get the code signed. The iPhone SDK is free, but by itself it won’t let you load apps onto an iPhone. When you pay Apple the $99 to enroll in the program, they send you a certificate which can be used to sign your applications. However, they will only work on iPhones which have been provisioned with this certificate.

Actually, if you haven’t already, stop right here and go read the article. Don’t worry, I’ll wait.

Done? Good.

Personally, I don’t mind Apple signing applications they sell on the iPhone app store. What I do mind is that Apple does not give me a way to write code, run it unsigned or self-signed (with a non-Apple certificate) on my own iPhone, and give it (again, unsigned or self-signed) to my friends who have iPhones. In other words, I want to be able to sign code with a non-Apple certificate, and I want a way to tell the iPhone to accept all code signed with a given certificate, even if that certificate has nothing to do with Apple. There are several reasons for this.

First of all, I recognize that Apple is under no obligation to make it easy for me to run applications on the iPhone. Still, I think it’s wrong for a company to serve as a gatekeeper, imposing its own morals (if a company can even be said to have morals) on the users of its devices. A technology company should enable people, not disable them. Telling its users what applications they are allowed to run is ultimately hurting them, and hurting progress. While I can understand that media companies have an incentive to hurt progress, tech companies should avoid going down the same road; in the end, it will only hurt themselves.¹

Second, it hurts the iPhone. Apple’s guidelines effectively disallow many perfectly legal applications. In his article, Mike mentions porn. Porn is an important market force. It’s no coincidence that pornographic web sites make up a huge part of all web sites, and pornography makes up a large amount of all internet traffic. I understand that Apple doesn’t want to sell pornographic material on its store, but by not allowing Apple-unsigned code to run on iPhones, they’re not only keeping porn out of their store, they’re keeping porn out of the iPhone entirely². And this is not the only genre of applications affected; Apple’s guidelines forbid applications which run in the background, which affects things like social networking software, VOIP clients or chat applications. By keeping these apps out of the store, Apple keeps them out of the iPhone; many groundbreaking applications which could have made the iPhone a rule changer are effectively forbidden because the iPhone only runs code signed by Apple.

Third, it’s bad for application quality. Typically, developers run beta tests to find bugs in their applications. How can a developer run a beta test if running code on a beta tester’s iPhone requires that the code is signed by Apple?

Finally, how do I send review copies to magazines, or free copies of my app to friends?

Requiring code to be signed by Apple is a dangerous path to follow. Unfortunately, Apple already seems to have plans to require signed code on Mac OS X. That, by itself, is quite inconvenient, but not necessarily a bad thing; it gives users the security of knowing where code comes from. However, requiring code to be signed by Apple even on Mac OS X would be a tremendously bad move, and would probably ultimately hurt Apple, its developers, and its users.

Update: Rogue Amoeba has now started filing bugs against these restrictions. Good idea.

March 8th, 2008 / Tags: iphone, sdk, code signing, mac os x, apple, rogue amoeba software, mike ash / Trackback