A little while ago, I was arguing with my interaction designer about our application's Contact editing screen. To argue his side, he invoked a couple of native user interfaces. To counter, I dissected those user interfaces. The dissection was a useful exercise in itself, as well as being a form of banishment of what had been invoked.
I say dissection because I flatter myself that there was a level of precision in my analysis. Also, when the analysis was done, I felt that I had exposed the workings of the user interface and gained understanding by doing so. When you read my analysis, you may say that I simply wandered about, slashing unmethodically. And that I rendered the pretty flesh of the user interface into a gnarled stew of sinew and tendon. Either way, what follows is not a glance at superficial beauty, but a dig into the functional depths.
But first, a preamble covering my interaction designer's side of the argument …
Invocation of the native
Invocation of the native user interface (UI) is an incantation that is often effective. Mobile software developers are probably already familiar with the incantation:
Abracadabra! If iPhone does it, it must be right.
Or you may have heard an alternate form:
Abracadabra! If Android does it, it must be right.
You may even have heard the most powerful abracadabra:
If iPhone and Android both do it, it must be right.
(iPhone is a trademark of Apple Inc. Android is a trademark of Google Inc.)
I'm being facetious, because I didn't agree with my interaction designer. There is actually some sensible analysis behind these mantras.
When designing a user interface, we sometimes need to make it like the user interfaces of other applications that are used in the same context. In other words, if it's running on iPhone, make it like other iPhone applications.
The counter analysis is that we shouldn't make the same mistakes as other applications in the same context. We also need to make our UI best so that we can be proud of it. So if we can do better than, say, the Android native Contacts application, then we should. To establish what the mistakes are, and how we can do better, we need to take the native UI in question and examine it closely, by which I mean dissection.
Bring out the bodies…
Subject of Dissection
Here are a couple of screenshots. These were the subjects of my interaction designer's invocations, and therefore the subject of my dissection.
 Native UI A |
 Native UI B |
The screenshots are of the native Contacts applications of two different mobile phones. To avoid potential issues, I've designated them UI A and UI B, rather than use their branded names.
Superficial Analysis
(In anatomy, superficial means near to the skin. The opposite is deep.)
At first glance, the UIs both look fine, and quite similar. Both have pretty, designery graphics. The two screens have quite similar layouts. Both consist of a list of fields with values. In both cases, the list is presented vertically, with each listed item occupying a single row. Both contain a feature that my interaction designer wanted in our software, but which I did not. (We will come to what the feature is, but later. For now, patience.)
Cutting through the surface, however, will reveal that there are differences between the UIs. Hand me my scalpel.
Dissection
My first cut reveals that one UI has a glaring shortcoming
A Glaring Shortcoming
In native UI A, not all of the Work e-mail address is visible. Quite a bit of horizontal space is occupied by the controls, and this has squeezed out the field with the value. If the Work button were narrower, and the minus button absent, then there would be enough horizontal space for the field to display the whole address.
Native UI B has roughly the same controls but doesn't have the same functional shortcoming. The whole of the address “e.gadsby@wooster.com” is visible.
How can this be? Dissect and discover…
On the device with UI A, the field would be edited in place, on this screen. This means that the font has to be large enough that a cursor in the field is visible, and that a user could tap within the field to place the cursor.
On the device with UI B, the field would be edited on a separate screen, opened when the user taps the field. The font on the separate editing screen must be large enough to be tapped, as with UI A. But the font on the screen under dissection need only be large enough to be legible. So UI B uses a shrunken font on this screen, compared to the editing screen. Not only that, but the shrinking is dynamic. There are two e-mail addresses in the UI B screenshot. The longer address is displayed in a smaller font than the shorter address. The result of all this is that more information fits on this screen, and hence function is improved.
(Also in its favour is that te device showing UI B probably has superior screen hardware. With UI B, the hardware manufacturer and software developer happen to be the same company. This is not the case with the device showing UI A. On device A, the software is open source and must be able to run on a range of hardware. The designer of UI B didn't have to worry about whether the UI would work on screens of lower resolution, for example.)
For whatever reason, this is a problem in UI A that does not affect UI B. But, there are problems that affect both UIs. For starters, what's with those minus buttons?
Minus Buttons
Both user interfaces have a column of minus buttons down one side. In UI A, this is on the right. In UI B, this is on the left. Tapping a minus button deletes the adjacent field's value. This was the subject of my argument with my interaction designer. He liked the minus buttons; I didn't.
His case: Without the minus button, in order to delete the value, the user would have to select the field and then tap backspace as many times as there are letters in its content. I agree that this would be tiresome, but…
Why facilitate deletion of a field's value?
Deletion of an individual phone number, or e-mail address, must be an infrequent task. Consuming precious screen space with a control that facilitates a task that is only infrequent seems like bad design to me.
I'll go further. Infrequent actions that are destructive, such as deleting a field, should be … whatever is the opposite of facilitated. It should be difficult to destroy data. This is what we're doing when we add an are-you-sure confirmation dialog: making the interaction more difficult. Facilitating destructive actions only facilitates the user in making mistakes.
The real reason for the minus buttons in UI B may be that there is a need to fill space. Using a smaller font is good because more information is displayed. But it's bad to show a lot of white space on a screen, especially a small expensive one. The user feels cheated. But this solution is not good. Padding out layout with function is the tail wagging the dog. And speaking of layout …
Layout
The visual layout of UI B is not perfect, for me. I find the alignment of the labels to be a little jarring. The field labels (mobile, iPhone, home, work) should be set further to the left. The “add new …” button seems not to be aligned with any other element. The button would look better aligned to the right, next to the chevron. The button would also look better with its left side aligned to the left side of the field values, or to the left side of the field labels.
But the functional layout of the values and buttons in UI B is good. The “add new” button is placed at the end of the list. This is better than having the plus button at the top of the list, as in UI A. It's more intuitive at the bottom of the list, I think. Suppose I am given a phone number for a contact, perhaps by the contact themselves. I read down the list to see if I have the number already. I reach the end of the list without having found the number. Now I know I need to Add New. So the bottom of the list is the right place for the Add New button, not the top.
Both UI layouts seems to have been designed with attention paid to the consumption of vertical space. UI A consumes vertical space with the headings for the type of detail (“Email”, “Phone”) and then saves space by putting the plus button alongside the heading. UI B only consumes vertical space with the “add new …“ button. There are no headings, as such, in UI B, but the button's label includes the type of detail (add new phone, add new email). So the button is doing double-duty, as the Add New control, and as the heading.
So, in both UIs there is one row of vertical space that is consumed by something other than data. Vertical space is scarce on the phone, so it's good to minimise its consumption.
This seems like a good time to mention a non-layout point: Translation. I expect that UI A is easier to translate than UI B. The headings are not sentences but only single words. The words (Email and Phone) probably occur in a number of places in the UI, so the localisation is simply re-used. That benefit seems marginal though.
(Sorry, I said that translation is not a layout issue, which is something of an over-generalisation. Translating between, say, English and French, probably doesn't involve layout issues. But translation between, say, English and Arabic, might well do. A user that reads right-to-left probably expects that the label is to the right of the value.)
Another aspect of layout is visual grouping. Native UI B has a stronger visual grouping of the fields under each heading than UI A. In UI B, visual grouping is achieved with rounded corners, a different background, and a vertical gap. In UI A, there is only a horizontal line. Stronger visual grouping may be necessary in UI B because the “heading” is not at the top of the list, where the user's eye expects a heading to be.
I prefer the visual grouping of UI B, but I don't think it could be used in UI A. UI A has an extra button on every row. These buttons, like all buttons, need dead space around them so that the user can tap with confidence. If a button is surrounded by other buttons, or active space, then the user has to be careful, and may become anxious. To paraphrase Steve Krug: Don't make me care. These buttons are doing double-duty too…
Click-able Type Labels
In UI A, it is obvious how I will change the type label on a value, by which I mean change “Home” to “Work” for example. I see the type label is a button, so I know that I'll tap it to change it's value. In UI B it's not obvious, although the method used is common throughout the device: fields and labels are edited on a separate screen.
Conclusion of Dissection
The big drawback of UI B is the lack of in-place editing. I'm told that even its fans think this. But, having done the above dissection, I can see the validity of the approach. Editing is relatively complex. Having editing in-place, on the same screen, adds to the complexity of the screen. Moving editing to a separate screen results in two simpler screens. Also, the separate screen approach is tied in with a number of other design decisions. Changing to in-place editing would mean changing those decisions too.
So, what we have here is a compromise. There's nothing wrong with compromise, although many designers think of it as a dirty word.
Here's a statement that would annoy such designers: Beauty is optional, function is mandatory. We've all seen uncompromising design and loved it. It just wasn't on a product that's successful in the market.
Conclusion about Dissection
Dissection is interesting, and reveals how everything is connected to everything else. If you don't believe me, ask an anatomist.
The mobile user interface is smaller than the desktop UI but, ironically, stands more dissection. You'd think that cutting up smaller things would be more difficult, and it is. But it's also more important.
So should everything be dissected? Should dissection become part of the everyday mobile design process?
Simply: No. Dissection should not be applied to incomplete software. Let the thing live before cutting it up, I say. After all, when does something that has been dissected get up afterwards? Apart from anything else, it's discouraging for designers. Designers like pretty things, and the UI stripped bare by her programmers is anything but pretty.
As to the presence of minus buttons in the UI, I can tell you that I didn't win the argument. I can also tell you that the interaction designer was made redundant, and I miss him.
Thank you for reading and if you're looking to hire an interaction designer, please comment on this post.
Copyright © Jim Hawkins, 2010
