| This blogger has moved! |
I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs |
Bjørn Rybakken has a take on design-by-committee in his excellent new book Formsans og Design. Enjoy:
Unfortunately the book is only available in Norwegian, I'm not aware of plans to publish it in english. (The shaky translation of the illustration is mine).
| This blogger has moved! |
|
I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs |
It’s really hard to create polite software for mobile phones.
What purpose does your software have? Is it to enhance productivity, empower users, move stuff from the inbox to the outbox? Is it to keep its owner informed and up to date on the latest news? Is it to maintain a Bluetooth connection between the phone and the laptop?
Should your software be upbeat and helpful, should it be efficient and toned down, or should it simply be invisible and out of the way? Software has a predominant manner of representing themselves to the user. Programs whose appearance and behaviour conflict with their purpose will seem jarring and inappropriate, like a clown at a wedding, to quote Alan Cooper.
(I have quoted liberally from the iPhone Human Interface Guidelines and especially from Alan Coopers book About Face throughout this post. Both are necessary reading.)
Cooper describes three application postures:
Sovereign posture programs takes over the entire screen, for example a spreadsheet or a word processor. Since Sovereign posture programs are used for extended periods of time, the users tend to be quite familiar with the program. Speed and efficiency is far more important than ease-of-use. Colours are muted and it's OK to display a large number of UI controls. Toolbars? Bring them on!
Programs having Transient posture come and go. They perform a single, high-relief function with a tightly restricted set of accompanying controls. A printing dialogue box could be an example. Transient posture requires clear, easy-to-understand appearance and use. Bold and large is good. Come and go quickly. The taxicab of applications.
Cooper also groups desktop widgets/gadgets with transient apps. The purpose of desktop widgets is to give easy access to changing information with zero interaction. A desktop widget should be easily glanceable while staying out of the way so you could argue it had more in common with the next posture:
Daemonic posture is a program that normally doesn't have a screen presence or lives in a control panel. It's mostly invisible, doing its thing in the background. Only when important events or errors happen does the daemonic program alert the user.
Apple doesn't talk about postures but suggests 3 different application types; Productivity, Utility and Immersive.
A Productivity Application enables tasks that are based on the organisation and manipulation of detailed information. People use productivity applications to accomplish important tasks. Mail is a good example.
Data is often organised hierarchically and the user interaction model in a productivity application typically consists of organising the list, adding to and subtracting from the list, and drilling down through successive levels of detail until the desired level is reached, then performing tasks with the information on that level
A Utility Application performs a simple task that requires a minimum of user input. People open a utility application to see a quick summary of information or to perform a simple task on a limited number of objects. The Weather application is a good example of a utility application because it displays a narrowly focused amount of information in an easy-to-scan summary.
A utility application tends to organise information into a flattened list of items; users do not usually need to drill down through a hierarchy of information. The user interaction model for a utility application is very simple: Open, scan information, close. Optionally, change settings.
An Immersive Application is what it sounds like; full-screen video, fun and games.
Are Coopers postures relevant for mobile? Yes, to a large degree. Sovereign posture is relevant in for example email applications. Use the pixels efficiently and provide as many shortcuts as you can.
Transient postures are for all types of dialogs like “send this picture as an email”, and for the current crop of mobile widgets. Daemonic postures for the battery indicator and the SMS alert.
The trouble is of course that the choices 3rd party developers have when developing an application is the following:
A little bit exaggerated perhaps, but true in essence. All the iPhone application types have sovereign posture. The reason is because that it is the only way to build apps on that phone. The same goes for Nokia, Samsung, Sony Ericsson (albeit to a slightly lesser degree).
If you want to build a weather app and you think it makes sense to add it into the calendar? Or maybe add it to the idle screen? Sorry, you have to build a full screen weather app. Want to build a sync app and add it as a menu choice in the phone book? Sorry. Want to build an image manipulation app and plug it into the camera app? Sorry.
There is no basic human right that says that you should be able to plug your software into anyone else's. No one is required to open up their apps or data to others. But for smartphones, that is the smart thing to do. It is hard for one piece of software to serve all users’ goals. Let applications behave cooperatively. It works on the internet…
There are some examples of efforts towards different behavioural stances in mobile apps. See for example a previous post about living icons (read the comments).
Google made a search app that is available from the idle screen.
Photo from www.allaboutsymbian.com
For the most part, current phones have siloed applications built with a Single Document Interface. Do you have examples of applications that successfully integrate or cooperates? Please share in the comments.
| This blogger has moved! |
|
I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs |
Google co-founders Larry Page and Sergey Brin appeared on rollerblades at the G1 announcement. Being true nerds, this is of course not random. Maybe a bit far fetched, but my guess is that it’s probably a poke at Apple, saying “You have turned into a bunch of elitists. Android is the phone for ‘the rest of us’”.
Bill Verplank tells this story:
25 years ago we asked Apple: If the Macintosh was a car, what kind of car would it be?
"Oh, it’s a Beetle (a Volkswagen Bug) who thinks it’s a BMW."
What will it be in the future?
They all agreed that it was going to be some kind of rollerblades.
(Volkswagen is German and literally means “[The] People’s Car”.)
PS: If you don’t know about Bill Verplank, you should check him out. For example this podcast: Bill Verplank interviewed by Jared Spool
| This blogger has moved! |
|
I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs |
At the Design for Mobile conference last week Mike Lundy, Design Lead for the Sprint Instinct, talked about the design and development process for the phone. He had some pretty interesting things to say.
(This is my impressions and takeaway from the talk, any errors are mine, etc, etc.)
The Instinct has become the most successful device launch in Sprint history. The Instinct represented a change in the design relationship between a carrier, an OEM and application providers. More importantly, it represented a fundamental change in development tactics and design authority within the carrier.
In addition to selling well, the Instinct also got some pretty good reviews. Mike Lundy and his cohorts must have done something right.
The degree to which an operator customizes a phone before they sell it varies a great deal. Some operators do nothing, they sell phones just as they come from the manufacturer. Some customise the look with colours and icons and their own web start page. And some, like Sprint, put a lot of extra software on the phone.
Sprint has a multivendor approach where many different companies (OEM’s) deliver different parts of the phone software. In addition to the phone manufacturers own OS, there may be a dozen more applications, all with slightly different different buttons, menus, user experience.
For each feature, like music, email, navigation etc. operators have their own product managers with different budgets and objectives. This often leads to a very bureaucratic development process. Typically, product managers fight to give their service highest priority, without worrying too much how much this may affect the overall user experience of the device. They are after all measured on how well their service are doing, not everybody else's. In short: there are way too many cooks in the kitchen.
The UE team may have the task of creating a unified experience, but often not the means since the UE team does not own the overall design. Sprint used to do feature level requirements, and only bug level enforcement were possible. This means handing off a word document or a wireframe to the developers, and all you can do if you don’t like the result is file a bug report. More, when design decisions were made, there were no engineers and no visual designers in the room. 
A small dedicated team of only 12 people (The Tiger Team). Visual lead, Design lead, some engineers, some product managers and one exec who informed externally. The team had clearly defined roles, clearly defined goals and executive backing.
Development was done in isolation from the rest of the organization. The rest of Sprint didn't know about the project, if I understood Mike correctly. The team moved out to a different building with their own security (I guess that was to keep product managers out). Samsung sent 20 or 30 developers to the Sprint site to work on the phone.
Very fast turn around. 24 hours to come up with a design suggestion to any given problem, 48 hours for the design lead to evaluate it.
With the Instinct, the design team were owners of the overall design.
Competitive pressure from the company that shall remain unnamed, the touch trend and experimentation with a new design approach.
The design was centred on habitual use, not on ease of discovery or ease of learning. "When you adopt it, it is so efficient to use that you don't want to change".
There was very little user testing or input, it was a very heuristic design process.
There were only 9 months from project start to shipment and 36 apps to redesign. 13 vendors contributed, all had apps that had to be adapted to the new UI.
The hardware/software platform was chosen before the team started their work. The hardest thing about the entire project was that the hardware was underpowered for the task, it was never designed to do what they asked it to do. To make matter worse, the various applications to be included ran 4 different systems (Native RexOS, Java, BREW and TAT.) The effect can be seen. The address book runs native code and the list scrolls very smoothly. The music player is written in Java (that runs on top of BREW in this implementation, making it very slow) and the lists doesn’t really scroll, the text jumps to simulating scrolling.
All existing Samsung UI code was thrown out. The design team created a a common set of UI widgets that all vendors had to adapt (framework widgets). This drove design consistency. When the vendors complained about UI shortcomings, this brought attention to exceptions.
No more “paint by numbers” for the visual designers. Visuals was included in the wireframes sent to engineers so they had pixel perfect designs in hand. Visuals were also used to improve and clarify interactions including the physics of the interactions, acceleration and deceleration formulas for gestures.
Screen real estate is at a premium on a touch screen device because everything has to be visible on the screen.
The Swiss army knife approach was rejected. All features were removed by default and every feature was interviewed again for inclusion.
For example; 70% of revenue for one music service came from a banner ad (presumably because the service has hard to use and people didn't buy music). The new design did not include the banner ad, and the music product manager was upset. 70% sounds like a lot, but on closer examination it turned out that it was 70% of very little. It would be better to improve the service so people actually bought music. The ad was not included in the new design.
The phone was going to be sold on unlimited data plans only. That meant they could remove a lot of warnings and alerts. It also reduced user anxiety over billing and reduced purchase anxiety (there is no choices to be made by the buyer. It's one package only.)
Here is an interview of Mike Lundy where he talks more about designing the Instinct.
Founder at Rift Labs. http://about.me/morten
Recent Comments