publications

mobx, the big bang

30 November 2011, 19:47

And now for part two of my MobX lecture. In part one we saw how old mobile was becoming bloated, more complex and slower. And then…

boom!

January 9th, 2007 the iPhone was introduced. It was the big bang of mobile. Looking at that first version hard‐ and soft‐ware today, it looks quite humble:

During a year or so after the introduction I caught up with my contacts at mobile manufacturers and networks. I found out that the response had been universal across the industry: ‘oh shit.’ This was followed by an investigation, ordered by the highest company level, into ‘why did we not invent this?’

culture club

That is a question of culture. All these companies have many very bright researchers. The question is what is being done with their work. That is a management problem. As is excellence in execution. Good enough is simply not good enough, today.

We also know that Apple had to keep the mobile networks out of the loop to make sure that the iPhone would not be any old mobile. At the end they found AT&T prepared to sign up, sight‐unseen, for the iPhone. After the introduction the genie was out of the bottle and no mobile network could put it back.

touch rules

Mid‐2007 I was for a couple of weeks in the US to work on the interaction fundamentals of an ‘iPhone killer.’ It was my first chance to get my hands on an iPhone, introduction in Europe was in November of that year. It took only a few days to figure out the rules of touch (apart from the obvious changes):

• The user interaction is more within a given screen, instead of being defined by transitions, as it was for old mobile.
• Use the whole screen. Whatever you do, make it as big and gorgeous as possible.
• Pixels are no longer the unit of measurement; it is the finger grid in centimetres.
• Touch interaction is addictive. Especially sliding, swiping or flicking things is the stuff that joy of use is made of: satisfaction guaranteed.
• No Options menus anymore. They are virtually gone.
• Back‐stepping (pressing the Back softkey) was such a natural part of old mobile that it was not even shown on the chart. With touch it is mostly avoided.
• This is not a phone. It is a handheld computer that happens to make calls.

In the two years that followed, I led the interaction design work on more than one ‘iPhone killer,’ for corporations that were simply not getting it. They were still insisting that their devices should have green and red hardware keys, as if they were making a telephone. Usability folks at these corporations were not exactly helping the innovation, playing it safe by insisting that everything should be operated by means of simple tapping. What was that about swiping?

like a robot

Now that we know the rules of touch, can someone tell me what is going on with android? April last year I was at a conference—nothing to do with mobile—and Google gave away a nexus one to every participant. It took only a few days to figure out that something was really wrong. They’re back:

The return of the Options menu and Back hardware keys is not just a case of old‑think. It is a serious problem. This is because the bright and shiny display is where the interaction is, and these two buttons are not part of it. And that is how users are perceiving it, they always pause when their next step can only be performed with either key. They get torn out of their interaction flow, press the key, then re‑enter the flow.

It is the law of the platform and android is stuck with it. But those of us who design user interaction for android apps can help. Why not put all the interaction on the screen? Refuse to depend on these two keys. And when the guidelines of android still prescribe to make use of the Options menu and Back keys, then treat them as a backup solution.

This is analogous to the situation on the desktop, where for instance in iPhoto most of the interaction can be performed in the main window, and the menubar is there as a slow, but safe, interaction element prescribed by the guidelines.

glass half full

What about hybrid touch, aka touch and type? Is it half‐baked? Looking at the image below it is obvious that the bottom half of this devicee cannot be used to watch a film, read a webpage or play a game. But, you can type like it’s 1999.

When I first had a prototype for this device in my hands, I thought: ‘wow, finally something is not trying to be an iPhone.’ This one is doing its own thang and deserves some love. The UI however is a direct adaptation of old mobile, adjusted for the obvious changes: direct touch input; no soft‑ and scroll‐keys. This must have really helped in the feasibility department, but it does the device no justice.

but there is hope

Early last year I led the interaction design for a software project for these devices. Without going into the project, I would like to show you that there are opportunities to push the envelope. Ignoring what is on the screen, let’s concentrate on the softkey line:

That softkey line is a touch area, of course. And because it is on the bright and shiny display, it is usable, unlike the android keys. Being touch, you can do whatever you want, which I did:

I put three icons (placeholders shown here), giving users direct‐access navigation between three sections of the application, as seen on touch devices. Together with the remaining right softkey, it is a truly hybrid solution. I kept the boss of this UI platform in the loop and she was very encouraging. She was eager to see innovation on the platform.

So do not despair when you have to work as an interaction designer on a hybrid touch project. It is a grey zone which means lots of opportunity to define it yourself. Go on and break the rules, and innovate.

the future of old

Looking at the graphs below, from the incredibly useful asymco blog, we see both for the US (left) and globally (right) smartphones—today most of them touch devices—are definitely on the rise towards dominating the market. Note that in our context both symbian and RIM are good old mobile—and were never that smart—but they follow the trend and are in decline.

source: asymco.com

Before you now predict the death of old mobile, let me point out that something as simple as component costs will keep proper touch out of the hands of most of the world population. Serving the worldwide middle classes: yes; everyone: as soon as the total parts cost is $10 or less.

So old mobile is here to stay, for a while. Let’s not forget outside the western world there is a lot of service innovation going on that puts the western world to shame. All of that is on old mobile. And no, working on old mobile does not need to be nagging legacy support.

dual strategy

I have blogged before about working on Nokia’s first dual‑SIM phones. I can talk about this project for hours, but what you need to know is how the fundamental equation of mobile phone was changed from one user, one SIM to one user, two SIMs. This triggers a massive engineering effort, every software component in the phone is affected. And if you don’t watch out, then for the UI you are up for redesigning hundreds of screen layouts, implementing these and re‑specifying all software that use them.

Because of this massive effort it was not that sure at the beginning of the project that we were going to make it. I was the interaction lead for the whole phone. I created the solution strategy and accompanying design patterns. Then I worked with Nokia designers and mentored them while implementing these patterns. And we made it:

And that was in part thanks to the solution I designed. My top priority had been good user interaction, but a happy side‐effect was a great reduction in UI design effort and overall engineering work. In May this year the first Nokia dual‑SIM model appeared on the market; today there are five models.

When you look at the phone above you see it is good old mobile. The solution could have been made in 1997: it is all just lists and Options menus. And the fist device we designed it for is low spec mobile, with just about the smallest screen size Nokia ships.

the future is bright

The dual‑SIM project turned out to be one of the most satisfying projects I ever worked on. And it was not just because of the challenge, the mind‐boggling complexities; not for the travel involved or the rewarding cooperation with my colleagues. It was so satisfying because all the time we worked on it, we knew how much it mattered.

How much it mattered for Nokia’s business was proven a couple of weeks ago when its third quarter results were released. In between the gloom and doom there was some light. They had shipped 18 million dual‑SIM devices that quarter. Through this they had gained market share in India. Even though with dual‑SIM we are talking about cheap devices, that is around a billion dollar in turnover.

In the financial statement and all marketing material, Nokia proudly communicates that their dual‑SIM solution ‘enables users to personalize up to five SIM cards.’ Cool, I designed that. The personalisation: instead of calling the SIMs just A and B, let users name the SIMs for what they mean to them, like ‘cheap calls’ or ‘free SMS.’ And that number five, I set that as the minimum to remember. It is quite normal for users in these markets to juggle three SIMs every day, and to change one or two of them, every month. 3 + 2 = 5.

Just the other week Nokia CEO Stephen Elop spoke at a press conference of the ‘halo effect’ that dual‑SIM has in the market. All sorts of Nokia devices are selling better because dual‑SIM is now shipping.

users + nerds

Also on the user side we knew how much the dual‑SIM project mattered. There was a pent‑up demand for this and now it is safe to say that out of those 18 million people that bought these devices, 100% did it for the dual‑SIM. And 100% of them are using it every day. Compared to the one percent I mentioned in part one, that matters.

Reviewing all this, I am thinking: maybe this touch UI vs. old mobile is all relative. Maybe it is just designer nerd‐talk? It reminds me so much of discussions developers have about the coolness and merits of doing a project in C, C++, Java or something new, like lua. Just maybe, it does not matter that much.

So for us designers, it might be more rewarding to be excited about how relevant the project before you is for your users and the business of your client. And at the end, you will know you have worked hard enough only if you are excited about how elegant you made the interaction, and about how much innovation you put in.

postscript

That’s it for my lecture. I could only share 5% of what I had lined up in my mind, but there was only half an hour on stage for each speaker and time goes fast. I am looking forward to the next opportunity to share some more.

Labels: fundamental, lecture, mentoring, mobile, practical

—ps

1 comments, link‐ins, forward this posting:

mobx, mobile before January 9th, 2007

28 November 2011, 22:22

Hot on the heels of the WUD there was the MobX conference. Very cool to be invited for this one, the speaker lineup was promising and delivered. The feedback of the conference audience was enthusiastic, both on the day itself and via all the familiar networks. As usual, here is the write‑up of my lecture.

mobile before and after January 9th, 2007

I started in mobile user interaction design as a contractor at AEG, in early 1997. At that time, mobile looked like this:

source: handy-sammler.de, thanks for the memory!

The pixels on this mobile’s screen were not square, they were rectangular; more high than wide. This was to save on screen cost and on memory needed to drive it. What I learned quickly is that a mobile is a complete computer, with an operating system; network communication stack; UI frameworks and applications.

More fun trivia: I did not own or use a mobile in those days. Only two years later I got my first mobile. I had seen mobiles before, more of them in the UK in ’95, less in Holland in ’96. But I had never made a call with one.

spec work

Work on mobiles was in those days driven by the GSM specification, which regulates how mobile networks work and type‐approval of mobiles. These specs are written by a committee of manufacturers, but I learned that they did this in order to please the network operators, to create new revenue streams for them.

The SIM toolkit, which I worked on in ’97, is an example of that. It lets networks add menus and UI to mobiles, for proprietary services. Speaking of services, in those days SMS was used by virtually no one, it was simply too expensive.

touch and go

Looking back it is quite amazing that we were working in ’98 on a touch UI model, for production. OK, it looked more like the model above than an iPhone, but still it had handwriting text input. Alas, that work stopped in the mid‑1998 when AEG got out of the mobile business. Nokia had invented segmentation—different mobiles for different people—and were solidly beating companies like AEG who were making only one model at any given time. Segmentation seemed to be the way of the future…

a cup of joe

We now fast‐forward to 2001, when a long stretch of mobile work started for me. Nokia was about to start working on their first java‐equipped phone, the 6310i:

This model still had a 1‑bit, black and white screen; two softkeys and 2‑way scroll keys. I still see the 6310i in use today, nine years after its introduction. They were built to last.

Mobile models were at that time differentiated by ‘extras’ which had taken over from the GSM spec as driver of development. I was asked by Nokia to design the first java mobile applications (MIDlets) to ship with the phone, together with a Nokia colleague. From this phase of ‘old mobile’ I would like to discuss three things I learned that are still valid in today’s touch‐dominated world.

1. work on a chart

This is the UI chart of the first MIDlet I designed, the converter. It converts units, like pounds to kilos and gallons to litres:

The point is that this is the complete user interaction. It is accompanied by an error chart—derived from the UI chart, it shows what happens when things go wrong, e.g. memory full—and a short document, less than ten pages, that specifies details. This is all you need to develop and ship the MIDlet.

Case in point. A couple of years later I worked on version two and three of Nokia’s java email client. Version one reached me in the form of a 189‑page document. Text‐only: a section for each screen, with gotos at the end for the transitions. It had taken nine months to write and was unusable. I spent a week decoding the document and made this chart:

Now Nokia knew what they had been developing. The chart was my first deliverable and it was a revelation to them. Worth every penny, they thought. In a much shorter timeframe, nine weeks, I did a redesign for version two, which had a lot of new stuff included. The result had to be put on two charts, though.

incomplete story

Every once in a while, I see storyboards being used to communicate an interaction design. You know, a row of screens showing what happens in sequence:

This may work—even well—to present work to people who are not in on the project. But it is not a working tool for interaction designers. It is not fit for communicating the design to development. That is because it cannot show a complete and coherent picture of the interaction.

seeing is believing

What I learned after a while is to read the chart. To see the quality of the user interaction from the patterns. This works because in old mobile, a lot of the interaction is not determined by what is on the screens, but by the flow between the screens. Here is the basic flow of old mobile, there is not much more to it than this:

1. Without even looking at what is on the screens, you just know that this is the Options menu.
2. Under it are the task flows, each completing a task.
3. The return point for the flows. After a while I sensed that this is a point in the UI where users feel calmer, more secure.
4. The flows themselves are more uncomfortable for users, they do not like to hang out there.
5. Longer flows spell trouble; one screen more and I would be alarmed and investigate. Note that this is about feeling (see 4) and not about number of clicks (a most useless metric).

If a chart has arrows flying all over the place, then either you have not drawn it very well (try again) or the user interaction needs a redesign. This is why I like to have the complete and coherent picture. To see how everything is connected and relates to everything else. That’s why I say: work on a chart.

2. there is no such thing as cross‑platform

I learned this one the hard way. So there we were at Nokia. There was a java team that had to make a toolkit that would run any MIDlet in the world. And there was me asked to design real Nokia applications using this toolkit. This was a constant struggle.

I do not blame the java team. They had to adhere to a common‐denominator specification and do the best they could. But the loss of control on my side meant too many cases of close but no cigar. The make‑or‐break details of user interaction could not be put in order.

difference engine

After a while I was also designing for multiple devices. All Nokia devices, but the differences started to bite. It is easy to see the big impact of changing the number of buttons on a device. From two to three softkeys; introducing 4‑way scroll.

Remarkably more buttons was not always better: I had optimised the converter so much for two softkeys, that when the third came along, the problem was what action to assign to it. At the end I put the conversion selection, but it was clear that the converter had not been aching for three softkeys to come along.

size matters

More subtle were the differences in screen sizes of the devices. This meant changes in how much text or how many items one could fit on a screen. This situation is quite elastic, but sometimes there would be a catastrophe because something would not fit anymore or an opportunity because an extra thing would fit.

This would trigger a redesign, and I do not mean just of some screens. Whole flows had to be changed because of the catastrophe/opportunity. I think today with touch UI this screen size factor is even bigger than with old mobile. Pixels sizes do not count anymore, it is the finger grid, measured in centimetres. That means less elasticity.

So when somebody says ‘we are going to do this cross‐platform from one codebase’ or someone else says ‘I got a cross‐platform UI toolkit,’ then I say: no you don’t. You have no idea what user interaction is really about.

3. be obsessed with elegance

So there I was, designing these small MIDlets that really only did one thing. And I started to be obsessed with how elegant the interaction could get. An example is the Nokia translator, which translates a couple of thousand words between five languages.

This looked easy, but there was one thing that bugged me: should users constantly be telling the translator what they are translating (German–English or English–German?). Language is a two‑way thing, so this directionality had to go. I was obsessed with this for more than a week, day and night. But then I had it.

Language is the answer. Just look up the input word in all five dictionaries. Spelling will sort out in which language it was. We ran some tests that confirmed the plan. The result was a leap in elegance. And a small, very satisfying UI chart.

complex issues

I used to have a complex, designing these small MIDlets that really only did one thing. Other people were working on bigger things like call, phonebook or SMS that were also used by a lot more users. I have always estimated that one percent of users used these small MIDlets that I designed. With an installed base of half a billion that still gives five million users, which is not bad.

These days, small programs that really only do one thing, and are used by only a fraction of users, are called apps. They are perceived as beautiful and people have no hang‑ups about working on them. And elegance rules this domain.

grinding halt

With hindsight it is easy to say that being small is beautiful. This is because I can now see that around 2005 something was clearly going wrong:

Meet sensor, today you would call it a social network, in this case a short‐range one: it worked via bluetooth only. It is so large it needed four UI charts; you can feel my pain. I redesigned this from the original symbian version. It was quite a bit of work, because there is no such thing as cross‑platform.

This is really exemplary of what was happening at the time. Mobile was getting bloated and more complex. Users were noticing it. Everything just felt slower. Straightforward things were no longer straightforward.

That is, until January 9th, 2007. Read about it in part two.

Labels: fundamental, lecture, mobile, practical

—ps

1 comments, link‐ins, forward this posting:

12 interaction tips for startups

10 October 2011, 14:03

Over the last year or two, we at m+mi works have seen a remarkable increase in projects with local startup companies. For us this is tangible proof of the alleged trend that Berlin is the location for your next startup. I can see the driving forces behind it though. Having set up shop myself in Berlin, I can only confirm the advantages and benefits of doing so.

Comparing our experience of working with startups with that of many years of working with clients great and small, I have noticed commonalities and some differences, and have digested these below. If you are running a startup that is working on a product that has user interaction, check out these tips.

1. do you really want to?

Do you really want your product—application, mobile app, website or online service—to be compelling and elegant to use? I have to ask, because a lot of folks I talk to say they want this, but in reality very few take the necessary steps to make it happen.

Starting with the right mindset (is the value in features or in user experience?); followed by finding the right people to design your user interaction and putting them in charge; then, when it is crunch‐time, standing by your user experience goals, instead of declaring them ‘nice to have.’ This is just a selection of what it takes.

If you are wavering at this point—or think you can cleverly bypass one of these steps—then you might as well stop reading, with the certainty that your product will never have a great user experience. Maybe you can make it regardless (‘if no competitor bothers, then…’). However, if you know that your success depends on your user experience, then read on.

2. you have a rare opportunity

At startups we regularly find the kind of environment that is conductive to the design of great user interaction. Working directly with the top decision makers; a lack of conservative and reactionary forces; genuine believe in the product; relentless focus on product inovation; a ‘can do’ mentality; knowing that only the best survive.

Add to this a product idea that must be innovative (‘me too’ or ‘feature parity’ equals death) and you can see why it can be exhilarating for us at m+mi works to work with startups.

My message to startups: you owe it to yourself to make use of all this energy. Unlike most other companies, you have the opportunity to produce something truly innovative, with user interaction that sets new standards. Grab it.

3. yet another development company

In some regards a startup is not that special. It is simply a software development company, which is governed by the same ‘laws of nature’ as any other software company. It is not that working at a startup gives a divine shot of inspiration and ability to developers, visual designers and product people for creating user interaction, is it?

The laws of nature dictate that if you want your product’s user interaction to be a hit and drive the growth of your company—instead of impeding it—then you need to involve specialists. No, the creative guy with photoshop is not it.

Similarly, going around friends, family and neighbours, asking them ‘here, try this’ or ‘whaddaya think?’ is not a usability test. Have an introductory talk with a usability specialist to find out what goes into testing of your user interaction. I am sure you will find it worth your while.

4. if you take UI seriously, budget for it

You are determined to take the necessary steps to give your product the user interaction it deserves. I think the following truism will not surprise you: you get what you pay for. Interaction architects are quite thin on the ground; we are usually busy; and we work at the top of the software development pyramid.

If you want a permanent interaction architect on your team, you are looking at making him or her a partner, with the equity share that goes with it. A person with the right ability—and experience—will know that user interaction is the one and only embodiment of the product, and will only accept a position where the accountability comes with the necessary authority: a ‘C’ position (CUIO?). As the startup grows, more junior interaction designers can be added. But the first one has to be a leader.

Involving external user interaction experts does take a healthy budget. The good news is that if you are familiar with the day rate of a good freelance developer, you will not be knocked out by what interaction firms charge. Bonus tip: the kind of visual designers or front‑end developers who say that they also do interaction design as part of their job, will be exactly the ones who can’t.

5. to save money, you can work more

An important asset of a startup is to compensate a lack of time, money, expertise or personnel by just working more, a lot more. I have used this fact to make a project with one startup happen. It turned out to be very successful and enjoyable. However, there are some hard limits to this approach.

Certain talents and skills need to be available at the startup to be able to take over a good chunk of the menial design and specification work. This is not always the case and it will have to be ascertained before a project starts if sharing the design work is feasible. Then, there is simply no substitute for expertise. Scaling back the involvement of experts simply scales back the depth with which the interaction challenges are met. You get what you pay for.

6. you got to have a vision

Creating good user interaction does not consist of applying some ‘divine’ rules, library patterns or platform guidelines. Also simply copying something that you like from another site or app does not get you anywhere. Designing interaction means creating the embodiment of your product and to help you with that, the interaction architect needs to know what it is.

A product vision is your short, sharp statement of what your product is. It answers three questions: what is the identity of your product; what are the core user groups; where is the end‑user value? The first thing we do in a project is to moderate a session where we help you to draw up your vision statement. Once done, it will be the fundamental basis for answering any interaction design question, our pact for the rest of the project.

If you fail to get your product vision together, then I am afraid your product is doomed. Examples of failing visions are:

• identities solely defined in a derivative way (‘like twitter with music, really’);
• user groups that are impossibly broad (‘everyone’) or schizophrenic (‘for baristas and nuclear scientists, yes’);
• only being able to offer features, when value is asked for.

But not to worry, it is rare for a vision to fail. And when it happens, it tends to be at big corp.

7. zealots, infidels and you

So you got your vision and—as I know startups—you are constantly ‘selling’ it to anybody who wants to listen; including yourself, to keep the faith. But wait, who is actually ‘buying’ it? Well, ultimately only those who invest in it. Either with capital (money, machines, bandwidth, etc.) or with a slice of their life (partners, working ‘for nothing’ for a while). Besides them, there are two more groups.

First there is the huge group of total outsiders to your startup. Talking to them is, at best, a form of market research. From experience I say: because they are not part of creating the future, they are a most reactionary force (‘micro‐blogging in 140 characters? no way’). The magic trick is to stick to your vision, but in the meanwhile filter the occasional nugget of gold out of this stream of feedback.

The second group are those—internal and external—who work with you on realising your vision, creating the future together with you. Are these people cynics, because they refuse to invest in your vision and want to be paid directly for their goods and services? I say: no, these people are very valuable as objective collaborators. Don’t take it as a rejection of your vision, they work with it every day. But without roze‐tinted glasses and no IPO on their mind, they are in a better position to see—and tell you in plain language—the reality of implementing your vision. Make use of their professionalism.

8. you have to build an organisation

Here is something I learned, the hard way: startups have, by nature, no track record of their capability to really develop and ship software. Yes, this is also true if one or two grizzled veterans head up the development. The first reason for this is that the organisation has to establish itself: procedures, communication, support systems, information flow, etc. The second reason is that it takes quite a while to find out if everyone on board is really up to the job.

As a startup you really have to take this into account. It starts with working on that organisation. Yes, even if there is only one developer. There is still information flow; bug tracking; an interaction design to be communicated; perhaps content or a visual design to merge. The one person responsible and accountable for building a software developing and shipping organisation is the CEO, and no one else.

Another way of taking all this into account is to plan with the overhead, delays and other surprises that are caused by both reasons above. With all that agile and iterative development that is in fashion at the moment, ask yourself what the dependencies are if one or two people are not able to deliver. I have seen processes like that completely unravel, with ugly knock‑on effects.

9. structuring is more than half the work

For any project interaction architects do, structuring the design process and implementing our methods is the backbone of our work. The feedback I get indicates that when working with startups, the value of this reaches the next level. I see two reasons for this.

First there is the factor of order. True, for just about any company we work with, our structure and methods supersedes a mostly haphazard and random UI creation process. With established companies, this comes in the form of process change. But with startups this coincides with the organisation building discussed above, and the clean‑cut structure that gets established is much appreciated.

Second factor is clarification. Working with a startup on their product vision; followed by compiling the functionality overview; then some user scenarios to represent typical use; it forces to make concrete what was only there on a subconscious level, or in a state of constant flux. Startups realise that this clarification work we do is a first and necessary step towards shipping an actual product.

10. you will have to manage

As you are building your startup, you are in a rapid process of transitioning from doing everything yourself to hiring professionals—internal and external—to handle all kinds of competences: product, interaction, visual design, development, testing, usability, sales, legal etc. Here is one that is sometimes overlooked: project management.

When you have picked the right people, they bring their skills and industry experience; they structure their work and act with authority—within their competence area; they know what it takes to get it done. But you will have to put them all together. Project management does not just happen by osmosis.

Building that organisation; realistic planning; keeping everybody on‑planning; dealing with contingencies; QA; multi‐platform issues; alpha, beta and rollout phases: you will have to manage it, or have a professional do it for you.

11. ‘real artists ship’

The proof of the pudding is in shipping it. Well, you know what I mean. A product does not exist until it is out on the market. And I mean shipping, not promised, announced or private beta. Now, a quest for perfection gets you nowhere. Question is: how much are you willing to give up to get it shipped?

My point is that you should not be staring at a feature list to find out the minimum you can bare to ship. Instead, think of minimum coherent user experience. If you got to be embarrassed when you ship your first version, let it be caused mostly by ‘missing’ features, instead of ‘good enough’ user interaction.

If you want your‐product‑v1.0 to have an impact and form a basis to grow, then its embodiment, the user interaction, should be designed, not an afterthought. So start small, that helps with getting it out; have the essence of your product designed and then ship it.

12. beware of strangers bearing gifts

There is quite a bit of support out there for your startup. University programmes, incubators, venture partners, business angels, subsidy from city, province, country and the EU. Perversely, some of this support comes with a serious helping of red tape. This can reach a point where the founders of a startup do not have the autonomy to act like executives and entrepreneurs.

I’d swear that the point of a startup is to innovate like no ‘normal’ company can. No naysayers playing it safe, no bureaucracy, no controlling. It means selling the vision to investors, then doing whatever it takes to ship it. And failing fast if the vision or its development is unrealistic.

Startups that live in a bubble, protected from harsh reality by a checks‐and‐balances bureaucracy, end up being humdrum R&D departments. They miss the urgency and agility that enable startups to ship great, innovative products, with great user interaction.

what type of interaction?

And that’s it for now. Maybe you expected something else, like tips about sign‑up forms, touchscreen finger grids, widget toolkits, the merits of toolbars. Actually, the twelve factors discussed above are a couple of magnitudes greater in impact where it comes to user interaction. Some of them are elephants in just about any software company’s rooms. Now what you need to do, is to return to tip one and ask yourself: do I really want to?

Labels: architects, fundamental, practical, product vision, startups

—ps

1 comments, link‐ins, forward this posting:

KDE UX sprint: inline outline

30 April 2011, 12:34

Last week I spent three full days at the KDE UX sprint. It was a lively meeting of KDE developers, a variety of (interaction) designers and usability folks. m+mi works contributed with two experts to the sprint, my associate Kate Price was also there to help out.

Many an interesting topic was discussed:

• What doe it take to bring the same application to different platforms, e.g. desktop, tablet and mobile touch devices? I say: more than just different widgets or rearranging screen layouts. The different vibe of each platform—the sofa factor of the iPad, being on the move with mobile—leads, in my experience, to non‑trivial differences in UI structure and flows, for the same app.
• Is it great that interaction designers can build a UI (prototype) themselves with languages like QML? I say: the interaction design must be specified first, with all the subtlety and freedom of the written word and drawings. Turning this design into the real thing/prototype always amounts to development. With good interaction designers so incredibly scarce, why should they do development instead of, well, designing?
• We looked for Calligra at screen layouts of windows, toolbars, inspectors for office‐suite applications. Even the ms‑office ribbon came up (Celeste Lyn Paul hit the nail on the head: icon puke). We quickly found out that the problem is highly complicated, with a lot of variables involved. I say: this is hardcore. Without a highly experienced team of interaction architects, implementing some strict, tight methods get a grip on the thousands of possibilities, this one will go nowhere. Oh, and one size does not fit all; applications in an office suite are still different enough to need different layouts.
• Overarching theme for three days: developer–designer relationships. The world could really do with more trust between both sides. I say: It takes developers and designers to create a decent piece of software. If either of them is missing, it becomes incredibly hard: mission impossible.

For the rest of this blog post I would like to report from the session that Kate and I worked on Friday afternoon. It was a classic example of interaction design consulting.

flowing in from the web

The topic was brought up by developer Aurélien Gâteau and concerned—we had to invent the name for it—inline dialogs. I am sure you have seen some of these; here is one that appears in my web browser for finding text on a webpage:

In the image above, a bar has been inserted in the window layout, between the title bar and the web page canvas, to handle some simple search interaction. Another example is positive (green) and negative (red) message bars that can be found at the top of web pages. We at m+mi works have been using them in recent years in our designs for several app‐in‐browser customer projects.

According to Aurélien these inline dialogs have recently started crossing over from web space into desktop applications. For KDE he was looking for guidance on how to design widgets for these and guidelines for developers to integrate them.

slicing + dicing

During our process that afternoon, we evaluated a number of examples, picking the good interaction ones, deconstructed them, settled on a classification, generalised these classes and took it from there. That took a couple of hours and here are the results.

The main reason for using an inline dialog in a desktop application is to not have a dialog overlap the window, combined with low (no) impact on the layout of said window. If that sounds too trivial to you, then here is a twisty corollary that I found: inline dialogs that do not span a full content column—and by definition smaller in pixels—are more intrusive than full‐width ones:

I quickly whipped up the example above by erasing more than half the bar. This ‘part‑bar’ is more intrusive because it is in effect overlapping the content: when scrolling up, content on the left will be covered later than content on the right. Yes, that is an issue fully driven by user perception, not by pixel calculations.

not in Kansas anymore

Another thing that can be said in general is that two of the reasons to use inline dialogs in web browsers; i.e.

1. the fact that a web page is (nearly) fully disconnected from the browser menu bar that is displayed right above it; e.g. it cannot rely on Edit->Undo from the menu bar;
2. the fact that the web browser has (nearly) no chance to insert its own controls in a web page; e.g. it cannot place a ‘Remember’ checkbox near every password field;

disappear in general for an application in a desktop environment. Unless of course, one or both reasons are valid for a particular desktop application. It takes however some serious stuff to trigger this condition, like a runtime environment where the environment owns the menu bar and the user interaction is running inside it as content (e.g. a web browser).

that’s classified

These inline dialogs are just that, dialogs. So the 30‑year‐old rules and variants of dialog boxes are all valid. Except for one: because inline dialogs are subtle and not exactly in users’ way—their main benefit, I say—they are not made for situations that need a modal dialog.

Now on to the classification, here are the different classes of use in desktop applications:

negative feedback

The same arguments that rule out modal dialog use, also suggest that inline dialogs—those negative (red) message bars—are too subtle on their own as negative feedback. So they only work in combination with something non‐subtle, something big, communicating failure. Then inline dialogs can be used for further clarification, close to the source of trouble.

positive feedback

Where for negative feedback it is too little, for positive feedback it is easily too much to use an inline dialog. It really only makes sense when there is a heightened user need for reassurance.

For both feedback classes above, I expect the normal situation to be that after doing some methodical interaction design, one realises that there are better solutions than using inline dialogs. They are to be used in exceptional cases. Two more classes of use:

opportunistic interaction

This is about offering low‐hanging fruit, on the side, e.g. after inserting a CD in the computer, a music collection program can offer to import it, as a ‘footnote’ in the overall window layout. I think this class of use can be very useful for getting chores done without breaking the main flow of an application. Get more done with less fuzz.

secondary tasks

Quite a mouthful this one: for tasks that are secondary—certainly not essential—for an application; users start them, concentrate on them for a while, intermittently if needed, until users decide it is done. Examples: find (and replace) and spell checking. The main benefit of using inline dialogs fits these situations well. Please, no close box on this class of inline dialogs, users are Done.

rewind; fast forward

And that is it. At Friday’s session we did not only put the necessary structure into inline dialogs in desktop applications. By also generalising in the form of above classification, we open up space for innovation in their use. I hope the results I have presented here will be as useful for you as it will be for us in our next projects.

Labels: fundamental, practical

—ps

0 comments, link‐ins, forward this posting:

the rise of proper integration

23 November 2010, 00:51

This year’s world usability day in Berlin marks my return to blogging. The hiatus was triggered by google’s deprecation of my publishing method, which had some knock‑on effects, both organisational and in publishing discipline.

Our usability day was bigger and better visited than ever. As a long‐time co‑organiser, sponsor and speaker, I think that’s cool. My lecture built a bridge between the theme of the day—mobile communication—and the new meet the expert sessions. The latter offered executives a chance to meet senior usability or interaction design experts to discuss about strategic, big‐picture issues.

My lecture was titled ‘the proper integration of interaction design and usability, or, the rise and fall of mobile empires’ and this is how it went.

first things first

To anchor the meaning of my lecture, I started off with my definitions of both usability and interaction design.

usability

both the measure of how usable something is and the profession where experts approach user interaction in an empirical way: surveying, observing, performing exercises with users. I always say: usability means getting the facts on the table.

Asking users what they prefer is not usability. That is market research territory. Usability is about measuring how users tick and if interaction works.

interaction design

both the complete plan of how the interaction works and the profession where experts create user interaction by shaping it in broad strokes; by innovating; integrating every single detail into the overall plan. Interaction design is about creating the future by making innovation jumps forward.

My complex relationship with the word design is known. It is not about making it pretty, design is solving the problem. It is about structure and how the interaction ticks. Elegance is defined in the mathematical sense, of how a solution covers all with a minimum of complexity.

Also note my old acid test for when we have slipped out of interaction design and into visual design. The baggage that comes with the word ‘design’ makes that I rather call myself an interaction architect. That also reflects much better the role of being the one who integrates the overall interaction plan.

separated at birth

Interaction design and usability are two distinctly different professions. Now you may think that I am painting this too much as a black and white issue. Is there not a huge grey‐zone between the extremes, where usability experts also design and designers also avidly test? Well, I only found out about the dichotomy because it is so pronounced. The grey‐zone, where professionals seriously combine both, is much smaller than one would expect.

trouble in paradise

With these definitions out of the way, I moved on to state how troubled I am by the way usability is deployed today. If companies want to get a serious return on investment in usability, they should understand that:

• It is not enough to commission some usability tests, when they are performed late in the project and there is no chance anymore to sort out the UI. I have too many frustrated usability colleagues who perform tests for the same clients, same products, version after version, only to find the same usability errors.
• It is not enough to employ usability specialists, when they are kept at bay by the rest of the software development organisation, who label their recommendations as ‘optional enhancements.’ I have experienced enough developers who were wildly enthusiastic about usability help, only to start overruling when it came to taking action on the results.
• It is not enough to have a usability department, when it is undersized for the development capacity of the company; when other departments manoeuvre to keep it catching up with the situation; when there is no interaction design competence in the whole company to solve the problems at hand.

The same can be said for interaction design:

• It is not enough to commission a UI redesign, when it is received as a collection of nice and flashy ‘ideas,’ when there is no follow‐through by designers during implementation. Which means with every next step, every decision, the design further crumbles to dust.
• It is not enough to employ interaction designers, when they have to work in fireman mode: to review and correct whatever happens to be already developed at the moment; when technical architectures and hardware are ‘already fixed’ from the start; when developers reserve the right to decide which corners can be cut in the design.
• It is not enough to have a design department, when their designs end up in drawers; when they do not lead the development of the UI; when there is no usability competence in the whole company to provide a foundation for the design work.

So there we were, at the end of a successful world usability day, and I had to spread this doom and gloom. Could I maybe offer any hope, instead? Yes I could, in the form of a three‐point plan for the proper integration of interaction design and usability into development projects.

1. work with a vision

Interaction design and usability work is not performed in a vacuum. It is not implementing, and testing against, some kind of general list of guidelines. Actually, interaction design and usability start where the UI guidelines end.

When designing interaction, we are creating the (generally) sole tangible incarnation of a piece of software with a certain identity, for a certain target group, delivering the reason why one actually would invest in using the software: value. In parallel, usability recruits participants from the target group, for instance to test if the software reflects the identity and if the value is delivered or hampered by the interaction.

It comes as no surprise (to those who know me) that identity + target group + value make a product vision. In order to put a bit more practice—mobile practice—into my talk, I then showed how a product vision is made for a fictive example.

everywhere you go, you always take…

Starting from the situation where a product manager comes in and says ‘we are going to build a weather widget,’ I demonstrated how by interviewing the persons who are driving the innovation, they can be coaxed to deliver something much clearer:

‘The weather widget is an always‐available, quick forecast of the weather for one location. It allows hi‑tech seekers and lifestyle junkies to plan ahead for the next 4–8 hours, while on the move.’

There is plenty in there for identity and value, what’s in it and what not, to design from. The user segments—‘hi‑tech seekers and lifestyle junkies,’ mobile is full of that—are used for usability recruiting and come with a lot of defined market data, like the use of mobile data.

everybody is scarce

While demonstrating this I hit the point where for target group you get the standard answer: ‘everybody.’ In my experience, there is one type of software that really is for ‘everybody,’ and that is infrastructure.

Software that provides infrastructure is easy to spot: it is so boring, that nobody is interested in talking about it or working on it. Literally, I have seen it make people run away. My own main experience here is the openPrinting project my firm is working on: pure infrastructure. So is call handling on a mobile phone. Duh, no? Should just work, no? My point exactly.

As soon as software is not coma‐inducing boring, it is no longer for ‘everybody.’ Yes, even the weather. In this mobile example the user segments of the phones that the widget is made for set a much narrower target group, which means the interaction design can be much more optimised.

all together

Working with a product vision is a form of insurance against moving targets and endless discussions. It is also a form of integration, where the goals of the project are firmly implanted as the root of the whole interaction design process.

2. process integration

Let us look at the timeline of a development project, it starts at the left and ends at the right:

Now let us say that the project decides to involve interaction design at the point where the orange marker is:

I say: sure you can do that at that point, as long as you understand the following two points:

1. Up to this point, you haven’t done nothing for your user interaction. Sure, also in my experience developers—and if you got them visual designers—can come up with exiting nuggets of interaction innovation, but it has to be clear that the job of making the whole interaction work starts at this point.
2. Having started at his point, it cannot be that things—like technical architectures and visual layouts—that heavily impact interaction design are ‘done.’ These are significantly formed in symbiosis with the interaction design.

Yes, you are right: that orange marker is better placed a lot earlier in the project.

Now, let us take the same project and instead of interaction design, involve usability at the point where the green marker is:

Par for the course, I say. But there are two more points:

1. Yes, ‘you haven’t done nothing’ until this late in the project.
2. The test will get the facts on the table. Knowing the industry standard for chances of surviving a usability test, I have to ask you: what did you think you were going to do now, in so little time?

Practically speaking, creating interaction starts a lot earlier than building it and it only ends when the last bug is fixed and the software ships:

As you can see from the color coding the overall interaction project is interaction design territory. Following through, keeping the interaction concept together as time pressure and compromises start eating into it is a prerequisite for success.

A serious deployment of usability looks like this:

Detailing each wave by number:

1. Initial research of how the target group users tick. This provides a grounding for the interaction design.
2. Test of initial, rough interaction design. The most important thing about this test is that one is fully prepared and capable to throw everything away and start anew, when the results tell one to do so. Testing on paper is good for that.
3. Test of the much more solid interaction design. Medium level stuff can still be turned around when the test says so. Still testing on paper.
4. Interaction design has been working with development for a while, a software prototype can be tested in a more high‐fidelity test.
5. This is just as ‘late’ as in the single test example. In this case, we are really just testing last niggly issues; icons and graphics that have been produced by now; final wording of texts in the UI.

At the end of each wave, usability and interaction design work together to analyse the results and splice the outcome into the foundation of any further interaction design work.

all change

Introducing usability and interaction design means process change. It is the only way to morph a technical software code producing machine into one that delivers products.

3. organisational integration

This process change must be accompanied by a redistribution of authority. And here lies the rub:

• Product managers know exactly that the interaction of the software is the one and only embodiment of the product. With mobiles, it is the remaining one once the product has been bought and the spell of hardware design dissipates. Product managers don’t find it funny to lose control over this embodiment.
• The development manager simply has to get it done. So (s)he does not find it funny that the definition of done has become so clear and explicit, e.g. in a UI specification. The room to fudge, to declare it done no matter how primitive the implementation, is gone.
• My experience with developers is all over the place. A good deal of them find it a pleasure to work on UI at a whole new level, to have exactly clear what needs to be build and to get on with the engineering. Others don’t find it funny that playtime is over. That—although there is room to do proof‐of‐concepts and contribute nuggets of innovation—as soon as it comes to production of user interaction, there is no more improvisation involved.
• Visual designers don’t find it funny that ‘design’ gets extended into dimensions that they are really not comfortable with, that layouts come pre‐structured and that text has to be in un‑cool, readable sizes.

This triggers standard tactics from all of the above in order to keep their fun going just a little longer:

• ‘these folks work subordinate to me in this organisation’
• ‘well, it is only advice’
• ‘we decide on that together’
• ‘I am doing the development, so who is going to stop me?’

But I say you cannot have it both ways. You cannot ask usability and interaction design people to deliver what is unreachable for you—make the user interaction work—and in the meantime sideline them so everything stays as in the ‘good old days.’

irresponsibility

Being made responsible for something, like usability, is almost a poisoned chalice. Responsibility comes with all of the workload and none of the freedom to execute. What is missing in today’s practice of usability and interaction design is the complementary pair of accountability and authority.

The accountability—one’s neck being on the line—comes naturally to interaction designers. To make that user interaction represent the product and that it all works for users and that it is feasible to build: who else is going to do the job? It is about time that the authority—the final say in what is being built—gets respected, as part of the deal for taking on that accountability.

And let’s not chicken out on usability, although it is empirical in nature. Usability folks should be accountable for getting the relevant and correct facts on the table. By doing this they earn the authority to report the fact that software is working or not, for users. Let’s stop calling it advice and consulting.

great balls of fire

Nobody is going to give up their slice of fun just like that. It takes organisational reform to make this work. This diagram shows how accountability and authority should be implemented. The ‘boss’ stands for the person who has the authority to sign off all the funds that pay for the software production:

Below the ‘boss’ we find, left–to–right, product management; development; interaction design and usability, all at the same level. Each of these can be a single person or a hierarchy that culminates at this point. Each of these can be in‑house or outsourced. All four are accountable to the ‘boss’ and the ‘boss’ lends each the authority to get their job done.

The only variant of this structure that I can think off, is when there is no ‘boss.’ This is the case with open source: the maintainers are the top of the development tree. It is also the case with start‑ups and other partnership situations. What we then have is a flat‐top hierarchy, with clear accountability and authority as before:

It also shows what kind of partners you need in this type of set‑up. ‘Boss‐type’ decisions will have to be made a consensus or committee type of way, in open source that will involve even more persons as shown here. The worst that can happen here is that one of these four gets elevated to the ‘boss’ position, but still keeps her/his original role. Conflict of interest is then pre‐programmed.

capital punishment

So am I here on a prima donna ‘designer’ power trip? No. I think that ‘having your head chopped off’ when the design cannot reasonably be built, when it does not embody the product or when it is unusable really focusses the mind and stops ego trips.

Over the last years I have come to the conclusion that interaction design thrives with tension, i.e. when the conditions are tough. When for product, development and usability heads—even better, for the ‘boss’—only the best is good enough. I once was leading a top‐secret project to design the ‘easy, intuitive phone of the future.’ My team thought immediately of paring back the ungodly number of features of mobile phones by a factor of three. But that would have been too easy. I saw there and then that greatness would come from designing for (almost) the whole feature set and deliver on ‘easy and intuitive.’

So yeah, challenges, tough requirements, great tension are fine with me, as long as I have the authority to solve all of that as I see fit, to create and roll out the best user interaction I can.

So what happens when push comes to shove? When someone insists the interaction design has to be changed and the interaction designer has reconsidered everything and knows this is the best solution. I say only three things can happen:

1. the ‘boss’ supports the interaction designer and it gets built and rolled out exactly as designed;
2. the ‘boss’ fires the interaction designer;
3. the interaction designer resigns.

Anything else, e.g. a horrible compromise to keep the peace, is unacceptable and should trigger scenario number 3.

1 + 2 + 3 = ∞

So there we have it, the three‐point plan for the proper integration of interaction design and usability into development projects:

1. work with a vision;
2. process integration;
3. organisational integration.

Can interaction design and usability experts in any way encourage the reform needed to achieve this proper integration? Yes we can, by stopping being happy with just any kind of work that comes our way. By saying no to:

• working on a project that cannot be coaxed into formulating a product vision;
• a late, first usability test and suggest instead that the same money be spent for testing at the beginning of the next project;
• designing interaction as a layer over a ‘done’ piece of software;
• working in situations where the ‘boss’ thinks interaction design and usability are ‘nice to have’;
• jobs at companies where interaction design and usability are down on the org chart;
• being just responsible.

We better spend our energy and our capital—the stuff it takes to create great user interaction—at places where we can see that one, two or even three steps can be taken in the direction of proper integration. And deliver there, to enable the next step.

And on that note I end part one of my wud lecture coverage. Read on for the rise and fall of mobile empires.

Labels: fundamental, lecture, mobile, product vision

—ps

0 comments, link‐ins, forward this posting:

from open source to symbian

3 November 2009, 19:42

Last week I was in London, at the symbian foundation and SEE2009. The reason for that is that I am a complete schizo. Well OK, not really. Let me explain: there are these two major—but completely separate—themes in my career as an interaction architect.

First one is mobile. For more than twelve years I have been working on fundamental and application interaction design for mobiles. There are more than half a billion mobiles around with software that I designed.

These days at m+mi works, I am fortunate to be lead interaction architect on some of the more interesting mobile projects, solving their fundamental challenges; I enjoy mentoring a next generation of mobile interaction designers for our clients; and I provide deep analysis of mobile usability test results, showing cause and solutions.

the other peter…

The second theme is open source. Since 2005 I am involved in the open‐usability scene in Berlin. You can read all about my involvement with openPrinting and GIMP on this blog. However, there is no mobile in my open source work and no open source in my mobile work. That’s the schizo split. It was because of GIMP that I ended up in London.

When Scott Weiss, UI technology manager at the symbian foundation, adopted our UI brainstorm to start the symbian UI brainstorm, I got in touch with him. A good talk resulted in an invitation to do a presentation during a symbian foundation UI workshop and to take part in a panel at SEE2009. Both with the aim of sharing my experience in working with open source projects with key players in the mobile industry.

fast forward

The condensed version is that commercial and open source work are 90% the same. Which means that everything learned in commercial projects can be used in open source. And vice versa, new methods I developed for open source projects get used in my commercial work.

The 10% difference is openness —surprise!

This openness creates an interesting dynamic where users are literally using today what was programmed yesterday. And that for serious work. This allows for experimental modes of interaction design and creates unique opportunities for usability testing.

However, as I have explained before: without usability or interaction design experts on the project, the very direct contact and feedback between users and developers in open source only leads to awful usability.

seriously

Working on open source is not just a hobby of mine. It is a strategic activity for m+mi works. By working openly and publishing about it in this blog, we have a fighting chance of making understandable what interaction architecture is. And making clear that it is missing in most development processes today.

You will notice that this blog does not talk about all that mobile work that we do. All of it is under NDA. Which is logical—in a closed source way—because yes: interaction architecture is highly strategic. It fully determines what a product or piece of software is, for its users.

feels like yesterday

As part of my presentation, I recounted how my involvement with GIMP started; talked about methods like the scenario weekend; gave examples of ideal cooperation based on infectious enthusiasm; and of course told the story of the making of the brainstorm.

At the SEE2009 panel, form, audience and the venue were different, but above condensed version was woven into the narrative of the panel. Both the workshop and SEE2009 turned out to be good opportunities to meet interesting people. I thank Scott for inviting me to be part of it.

More related musings in a couple of days.

Labels: fundamental, GIMP, lecture, mentoring, mobile, practical

—ps

1 comments, link‐ins, forward this posting:

teaching interaction /09

28 July 2009, 14:40

At the end of May it was again my pleasure to teach interaction design at the FH Vorarlberg, Austria. I will discuss what was new and notable compared to last time, show which new GIMP functionality we worked on and then present the results.

full intent

Kicking off with ‘what’s different?’, I had fine‐tuned the goals of my course:

structure, structure, structure

If there is one thing I want my students to take away from this course it is a project structure that enables them to tackle any (interaction) design project. I took the structure and methods used in my daily practice and condensed them to a project survival guide. In a fine example of ‘the medium is the message,’ these structure and methods also form the programme of the course.

true interaction

Furthermore I want to introduce the students to what pure interaction design is and what it takes to do it professionally. I chose our design project such that no one could simply fudge their way through using visual design or information architecture skills. How the interaction flows in time is our focus.

The title, interaction design for the real world, reflected that once again the course was all about working on a real design project on real software. New this year was the increased ‘real world’ focus, where for many aspects I related to the students how these are ‘business as usual’ for interaction architects: to deal with certainty with the uncertainties of any given project.

time + space

The time set‑up was different this year, with three full days of working together at the FH and the students sending me their final work two weeks after that. Also different this year was that my course was fully booked, with sixteen students participating.

I divided the students into four design teams and used our three days together for intense and full‑time design work (hey, just like the real world…), using the structure: day 1: from 0–to–100 on the project, ending in an expert evaluation; day 2: brainstorming to create as many solution options as possible; day 3: narrow down to a single design concept.

Each team had to then deliver a design concept document two weeks later. Looking at what could be achieved in three days, I set the scope of this document to be a project‐internal briefing, for the principal interaction architect.

GIMP + vector

On to our design project. I want that the work produced during this course ends up contributing to the real word. So I chose GIMP as our ‘client’ to design for, because I can ensure there that interaction design is advanced towards implementation.

During LGM the GIMP team discussed readying last year’s SoC vector layers code for inclusion in GIMP v2.8. That was exactly the type and size of interaction design project I was looking for. I will now introduce the material my students started out with.

The proof‐of‐concept code allowed to take a path:

and convert it to a vector layer, receiving an outline stroke and/or a fill:

the shape of the vector can be changed for ever like any path, and when not edited display like this:

the fill and stroke parameters could be found and changed in one dialog:

and that was it.

spoiled for choice

The exact set of functionality (aka features) has a major impact on the interaction design and interaction architects have to rightsize this set before even starting to think about interaction. Usually this means fighting too many features, since anybody—developers; users; marketing folks; managers—can come up with more features.

In our design project, there was plainly not enough functionality to be useful/usable. So before the interaction designing started, each team sat down to brainstorm and then decide on their essential set of functionality. What struck me at the start of this phase was to hear talk of ‘window’, ‘click’, ‘button’, ‘slider’, et cetera.

That had to stop immediately. It took a couple of rounds of explanation—‘it is just a boring list of what functions it has’—to get the cold, analytical side out of my students. But then they were on top of the functionality, as it should be. As we will see next, functionality like vector layer management, managing and combining shapes and working with simple shapes (rectangle, ellipse, etc.) was integrated.

four team results

Now the grand finale, the results of the four teams. First let me make clear that the work of all four teams is available under GNU Free Documentation License 1.2. I present them in team order.

team one

• members: Andrea Chavez, Christoph Bischof, Julian Tomaselli + Tamara Christina Blumer
• design concept document (pdf, 2.7 MB, limited pdf viewer compatibility)

Team one was the one with the hottest debates. That may sound a bit inharmonious, but it was good to see the whole team so worked up about making good interaction.

The main theme every team fundamentally had to deal with was the integration of the new vector functionality with the existing interaction, like that for paths and geometry transformation. This team solved it by introducing a shape tool in the toolbox and using the path tool for advanced vector manipulation.

Team one was the fist of several teams to arrive at the solution to use a library dialog for selection and management of a large set of user‐defined vector shapes. This works analogue to how brushes are selected and managed.

Apart from a doing a good job overall of keeping all the aspects of the interaction together, I especially liked their use of the modern GIMP sizing handles for the simple shapes.

team two

• members: Sara Geller, Laura Ramirez, Jakob Tripolt + Florian Wenger
• design concept document (pdf, 9 MB)

Team two shows us that all it takes to deliver a detailed design concept is pencil and paper. Funny enough this team, that did the most note‐taking, also resisted for the longest time to use the pinboards that I strongly recommended for gathering the results of the brainstorm phase. At the end, they did.

Team two integrated shapes and vectors into the path tool, giving the path tool different modes.

Overall they went deepest into a lot of interaction issues and solutions. I really liked their serious workflow analysis.

team three

• members: Mona Seiffert, Giselle Anahi Salinas, Markus Angerlehner + Anna Weiss
• design concept document (pdf, 732 KB)

Team three shows that it does not take a long document to get the core concept across. To my surprise this team dived into making pixel‐perfect mock‑ups of their ideas quite early in our design process. That was another thing that had to stop immediately.

In our high‐pressure environment where the teams had just enough time to arrive to a solid concept, the focus has to be on staying agile and creative. While all the time the scope of the design gets wider and the big picture becomes clearer, any part‐solution needs to be hot‐swappable for a better one until the very end. You can do that when solutions are pencil sketched, not so easy when they are visually designed with considerable effort.

‘Keep it brief’ is what I asked for the design concept document. But vector layers turned out to be a design project that was more multifaceted than the humble introduction would let one believe. So apart from the core concept, a lot of peripheral interaction issues needed addressing, as the other teams did.

team four

• members: Daniel Corn, Katherina Donner, Marko Heijnen + Lena Seeberger
• design concept document (pdf, 528 KB)

Team four introduced not one, but two new tools in their design concept. And for good reasons, like addressing smooth workflow, or an appreciation of the elegance of the free‑poly selection tool. So they introduced a freehand tool besides a shape tool, the former converts freely drawn shapes to stroked/filled vector shapes.

Also this team did a a good job overall of keeping all the aspects of the interaction together and I am quite taken in by their clean and effective little storyboards.

after the project is before the project

From the moment I selected vector layers as our design project down to the moment I am writing this, I have kept out of actively designing this feature, by simply not starting to. This in order to stay as objective as possible, while working with the students; while grading their work; even while describing it here.

But now it is time for me to get started. I will take the concepts of all four teams as the starting point for my interaction design of vector layers for GIMP. I’ll keep you up to date on that here.

Finally, I would like to thank the students for their hard work during the three intense days that we spent together. It was great to feel the vibe and I had a great time.

Labels: architects, fundamental, GIMP, practical, teaching

—ps

3 comments, link‐ins, forward this posting:

notes from san francisco: testing 1‑2‑3

6 May 2009, 06:39

This second blog posting about the openPrinting summit in San Francisco covers the usability testing of the printing dialog. First, a few words about usability testing.

I have worked with people who saw a usability test as a kind of final school exam: better send something into the test that will not rock the boat. This kind of fear surely stamps out any kind of interaction design innovation. Under those circumstances I say: why bother doing this project at all?

hard knocks

Experienced software developers appreciate working with a dedicated software test team. Yes, these testers aim to take everything apart, but the resulting software will be a lot better when it hits the streets. Similarly, I enjoy working with a usability team.

The usability test delivers hard‐hitting facts, but these flow straight into debugging and adding depth to my interaction designs. And when the test says it works, then my work is validated and that marks the end of doubt and discussion.

before the test is already a test

The usability test was performed by Jan Mühlig of relevantive, who also headed up the first involvement of openUsability with openPrinting in Atlanta, 2006. Although I took over the project at the Lexington summit in the same year, Jan has been closely involved at different phases of this project.

Straight away the preparation meeting was a hoot. For interaction architects, having a frank, uncomplicated discussion with professionals who have empathy and usability experience is both a pleasure and highly valuable. Jan’ feedback triggered a redesign that Kate, my associate at m+mi works, and I performed during our preparation of the test material.

agile like paper

The test was performed using a paper prototype. I played ‘computer’ in most of the test sessions, driving the dialog response to users’ input. Working this way allowed us to do three rounds of testing—with in between two further rounds of redesign—in exactly six days.

Being a usability researcher, Jan was not going to take for granted that any of our big, innovative concepts—no matter how sound they looked—was simply going to work. ‘Just print’; two levels of detail in the dialog; always a preview; quick presets; parameter tagging: he gave all of them a real workout during the tests. They had to prove to be a real improvement over the current state of printing dialogs.

the results are in

Walking you through the results, I will illustrate them with the latest iteration of the design, the one that went into the third test.

‘just print’

Printing still does not exist. At the start of test the participants were interviewed about what printing means to them and how they experience it. Again and again the answer is that the act of printing is not interesting, only the result counts. Here are some quotes:

‘What I think about is hard‐copies, really; a piece of paper I can look at.’

‘…but most often, I’ll just press print.’

‘I just click on print and… —[Jan:] the print appears by magic? —Yes.’

Although ‘printing does not exist’ is our number one guiding principle, it is striking to experience in the test how strong this force is. Our solution for supporting this is ‘just print,’ bypassing the print dialog altogether. Below you see the jury‐rigged file menu we used in the test:

I had put ‘Print one copy’ as a label in there for ‘Just print’ in the first test, but that did not work out. So, if you want to learn something, take some risk and use the test results. From the second test on the menu was as above. It fared better, but more testing is needed here before setting this label in stone.

preview

If ‘printing does not exist’ is a strong force, the print preview is huge. We are not talking here about participants getting along nicely with the preview and they knowing how to flip trough it. We are talking about seeing that for 100% of the participants the preview addresses a fundamental need.

Although it was my vision right from the beginning to design the print dialog around the preview, it is still amazing for me to see in the tests how deep it has an effect on users. So deep, that participants of the ‘just print’ persuasion started going through the print dialog more after seeing it—and the preview—only once. It is a huge effect to have the voodoo taken out of printing.

Now as an interaction architect I expect that long‐term—after the printing dialog has built a new level of trust in the print process through the preview and other factors—users will start taking up the offer to ‘just print’ for boring, predictable print jobs. But at any moment: if there is a hint of doubt, then the preview rules. Below we see the preview in the compact, level 2 dialog:

We added to this level the only universal printing parameter in the world: number of copies. If there is one thing we learned from this whole test cycle is that the way to the print is through the preview. The preview is the last thing to check and the Print button is logically located just below it.

tagging

Because of a lucky labelling flaw in our test set‑up, all the test participants went through the situation where the first tag they chose did not deliver the printing parameter they were looking for. After selecting a second tag they did not get the familiar situation of seeing different parameters, they got more of them (all parameters referenced by both tags). Then in 100% of the tests the conversation was the following:

Jan: Is this surprising?
Participant: Yes.
J: is it negative or positive?
P: I think it is positive, it is good that these are shown together because […].

Every participant formulated the last answer in a different way, citing a different reason why it was an improvement. But it was striking how the pattern returned in every test. Based on that Jan declared that he does not have to see dozens of tests more to know whether it works, it simply does. Below we see the full‐fledged level 3 dialog:

The whole tags + parameter section functions as an extension of the level 2 dialog. What is new is that the tags are now sectioned, along the lines of old‐fashioned functional vs. new user needs. Twelve of them in a single grid was simply too much. Next up for us is a parameters on the left vs. on the right design exercise and further work on the individual controls.

trouble

Not everything went that smooth from the beginning. I will illustrate that with this level 2 dialog that went into the first test (thus, now an obsolete design):

The test showed the following problems:

• participants had trouble identifying what the quick presets (on the left in the dialog) really were: a preset controlling all parameters or a single parameter settings?
• participants had trouble getting to level 3 in the dialog (via the More control button);
• participants were looking to ‘open up’ a quick preset to show what the actual implications (parameter settings) of it were;
• participants were looking to ‘open up’ a quick preset to show the printing parameters.

To find out what was going on we did a full‐risk redesign for the second test. That fared even worse. But now we knew what was going on:

1. we were relying on the actual labelling of the quick presets to communicate what they actually were;
2. our labelling was not good enough and since in production the real labels will be supplied by the printer manufacturer, they will never be perfect;
3. the preview does not contain enough information to show what a quick preset completely entails;
4. the information structure in the dialog was not clear: we were not showing that a quick preset encapsulates a full set of parameter values and thus the whole print.

into the light

To see how we solved this puzzle, let’s have a look again at the level 2 dialog that went into the third test:

The quick preset—now called ‘Current setting’ for users—now serves as a banner for everything but the printer. Under it, what is an essential print setting and not ascertainable from the preview is listed in short‐hand for a more complete overview what a quick preset will accomplish.

Furthermore, a change that meant the end of a principle that I had long cherished for the dialog: visibility and 1‑click selection of quick presets. With the limited reliability of quick preset labelling, the visible listing of them has limited value. Making the choice of quick preset a pop‑up enables to run it as a banner, closing the circle.

This design tested well in the third test. This means the big concept bugs have been debugged and fixed. For the actual quick preset pop‑up I have some innovative ideas in mind that I want to see explored. If they ever make it into the design, they sure will need usability testing, of course.

encore: labelling insights

While preparing for the first test, we spend some time straightening out the tagging used in the dialog. There we discovered some subtle factors in the labelling. Some of the tags had labels that looked like an end‑goal (‘fit to paper’), instead of a range where users can find their own optimum (‘paper fit’). The former gives the impression of a quick preset and is thus incorrect.

Similarly we have seen that quick presets can give the impression to be a single parameter setting. Although users have every right to store such ‘single issue’ presets, factory‐shipped presets should target broader goals and be labelled as such. ‘duplex: on’ is a very bad preset label, ‘good enough for jazz’ is a good label.

That’s it for dialog usability testing. Next up: the trouble with infrastructure.

Labels: fundamental, openPrinting, practical

—ps

1 comments, link‐ins, forward this posting: