publications

the making of: GIMP UI brainstorm

September 22, 2007, 20:02

It all started with Esteban’s message on the GIMP developer mailing list, asking where he could ‘upload a mock‑up of UI changes.’ That destination didn’t exist, yet. In my reply, the words visual brainstorming pop up and the idea was born.

That was the eve of my summer holiday, during which I spent some time thinking about how to make this work. The more I fine‐tuned the rules for a UI brainstorm, the more I felt it would be worthwhile to roll out.

trigger happy

A UI brainstorm is a great way to let everybody, regardless their experience in the field, contribute to a interaction design project. The whole idea is that one idea intuitively triggers the next and that in the context of the brainstorm anything is possible.

No matter how boring, impossible or just plain whacky the idea, it is a valuable contribution. Either it triggers a reaction from other participants in the opposite direction, or it invites to meander for a minute along that train of thought (‘imagine there really is no menu bar…’). Both are a step in the right direction.

get off

Participating in a brainstorm is a gratifying experience because ones ideas become officially part of the project. For us who organise the brainstorm, the contributions are valuable because we again get triggered by them. The result of that goes into our design process.

happy, clappy

If there is something that destroys the creative process above, it is negative thought. Any kind of naysaying or discussion of merit of an idea destroys the atmosphere where anyone can come forward and contribute.

For this reason I said ‘no polemic, please’ from the start. No written contributions, images only. And quite topical, to ask participants to express themselves graphically.

Looking at the kind of heated comments that usually accompany a GIMP news item, I knew comments would hijack and sink a brainstorm forum in no time. So in line with the positive vibe: no comments.

tech crunch

‘It is going to take ages to build an automated forum for this’ I thought, while still on holiday. Then I realised that all it takes is a mailbox, a blog and some manual labour in between. Ready to roll, that is if the use of google services was not objectionable.

I ran the idea past Sven and although not enthusiastic about the google angle, he also saw the point of getting things running. So a couple of weeks later I put the whole thing together on a Saturday afternoon.

…two weeks later

Although only announced on the same GIMP developer mailing list, the news spread fast across the internet. Sixty thousand visits from 145 countries, 334 sites reporting on the brainstorm and sending visitors.

Seventy contributions up to now. More came in, some people thought they could game the system: send in text‐only images or plain screenshots of other applications where obviously they did not invent any pixel themselves. Those did not make it. Good thing that moderation is built into the manual publishing of the blog.

sifting through

Kamila and I went through all of the published contributions during our team meeting yesterday. We analysed the issues the contributions address and got triggered by several contributions, giving us valuable ideas that one time or another will come in handy.

I think that quite a few people are enjoying the GIMP UI brainstorm. We look forward to see it develop in the coming months.

Labels: GIMP, practical, ucd

—ps

6 comments, link‐ins, forward this posting:

     

printing, design, students

February 07, 2007, 15:38

I just finished the selection procedure for my second openUsability student project. This time, I will be working on openPrinting with an associate. Meanwhile, the pilot GIMP project is still running fine.

I want to thank Ellen Reitmayr for suggesting that openPrinting take part in the openUsability student program, and for organising the whole shebang.

After reading the CVs and interviewing candidates, here are some of my impressions.

printing is not sexy

Significantly less people applied for the printing project than for GIMP or for other popular projects in this round of student projects. My conclusion is that printing does not really tickle the imagination of interaction and usability students.

That is a pity, because the field of printing interaction is actually wide‐open for innovation. Having performed an evaluation of the available desktop platforms, I present here my take on the state of the art in printing interaction:

windows

no idea about vista, but printing on xp is stuck in the early nineties. One size fits all; add a tab for bells, and one for whistles when needed. The lack of interaction support for new categories of printing developed since the early nineties is apparent, and one can forget about new patterns in working. ‘We’ve got to do better than that,’ is the consensus among the openPrinting project.

mac os‐x

late‐nineties printing interaction, but there is constant innovation going on at Apple. ‘Give us something like that,’ is the consensus among the openPrinting project. But I know Apple is looking further ahead, and why would I copy last year’s model, and sell it as new design to a project?

gnome

they copied an old‐timer (windows) for their brand‐new printing interface. No vision equals no inspiration, not worth all the development effort…

kde

a raw, technical representation of a config file, missing any interaction concept. Enough said…

So let’s bring printing interaction into the 21st century, and get gnome and kde on board to realise it.

method overload

‘These students know more usability methods than I do!’ was my first impression. But after googling some of the unusual suspects, familiar descriptions appeared. Another case of alphabet soup.

I interviewed three candidates, and all of them were concerned if we were going to use enough of those usability methods. I had to explain them that printing is so general—in a way, so abstract—that Jan Mühlig, Ellen and I have recognised that throwing more usability methods at it simply creates a bigger jungle of facts.

So the preferred approach is architectural. Usability plays an important role in validating and debugging our concepts, and in proving the client projects—openPrinting, gnome, kde—that our innovative concept is a clear improvement.

the design gap

All three candidates I spoke to went to study at design institutes with the dream of making software and the web function better, for users. All three were disappointed to realise that, all the teachers and their fellow students were interested in, was making things prettier.

So these young designers are graduating, not trusting their fellow designers to be even aware of the usability issues they create. They feel their education is incomplete, and have to look for other ways to obtain interaction architecture skills.

They know they have to, to be able to improve the interaction that surrounds us all.

Labels: fundamental, openPrinting, ucd

—ps

0 comments, link‐ins, forward this posting:

     

users, vision + architects /4

November 29, 2006, 23:32

Today we cover the section in the article by Don Norman, titled ‘static screens versus dynamic sequences.’

‘The methods of HCD seem centered around static understanding of each set of controls, each screen on an electronic display. But as a result, the sequential operations of activities are often ill‐supported.’

Don Norman

This matches my experience. My usability colleagues seem to perceive the initial screen/page/window segmentation as set in stone. That is,

• how a system is segmented into particular screens;
• how a website is segmented into particular pages;
• how an application is segmented into particular windows.

In my experience this segmentation is in 99.9% of projects either very technical; very functionality oriented; or simply bollocks—but always inhuman.

meanwhile, upstream…

Instead of starting with incremental improvement of layout and display within the given screens/pages/windows, I find it much more rewarding to focus on flow.

That is, user flow. Focussing on elegant flow for essential user activity is a very powerful tool for arriving at a natural screen/page/window segmentation.

As a side effect, a lot of the initial layout and display problems have by then simply disappeared, and the right approach for the remaining ones has become obvious.

don’t call me a…

Every now and then I am mistaken for an information architect. Or worse, information architects imply we’re all one big family.

Interaction architects add the dimension of flow, to the two‑dimensional world of information, and that makes all the difference.

next…

…stay tuned for the fifth article, on dealing with user requests.

Labels: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting:

     

the wud and the chainsaw

November 23, 2006, 14:09

Tuesday last week was world usability day. Apart from m+mi works sponsoring and co‐organising the berlin event, I also gave a lecture.

Our wud was held at the meistersaal. This former masonic concert and banqueting hall used to be hansa studio 2. It was here that David Bowie recorded his best work, among it ‘heroes’, his pall Iggy Pop recorded ‘lust for live’ and U2 a good chunk of ‘achtung baby.’

unified lecture

Jan Mühlig of Relevantive proposed to combine our individual lectures, and demonstrate the ideal user experience process we are implementing for the openPrinting project. After a kitchen meeting, some wiki collaboration and unified by a single keynote theme, we were ready for prime time.

We structured our lecture like our projects, with Jan covering the usability parts at the start and end, and me covering the central interaction architecture section.

So Jan kicked it off by outlining the complexities involved in the world of linux printing, and the usability process of uncovering objective user‐related facts.

the central section

Our lecture was the final one of the day. After hearing all day how usability will save the software world from user apathy, it was time for me to point out that there is a big gaping hole in the middle of every usability process, and the interaction architect is the ideal partner to fill it.

Qualification and cooperation were themes of the day, so I showed the qualifications necessary to become an interaction architect, which forms the basis for seamless communication and cooperation with the technical, usability, design and managerial personnel in a project.

gentlemen, start your engines

Then it was time to show how usability methods collect you a jungle of facts:

To get anywhere useful with all these facts, an architectural approach is needed:

This process is one where for a moment the cooperation stops. This is pure interaction architecture. The result is a set of discrete, solvable problems:

At this point cooperation kicks in again, with usability folks first, discussing interaction concepts. Validation by usability testing can start here as soon as the first sketches are scribbled on paper.

When the interaction architect's concepts have been debugged, then the cooperation can widen with interaction/graphic/web designers and developers joining to negotiate the nitty‐gritty of realisation.

wrapping up

Jan wrapped up the session by observing:

• how the fundamental approach towards solutions taken by the interaction architect structures the rest of the project in a profound way;
• how the neutral position of the usability expert, and the mediating role of the interaction architect lead to solutions that are embraced by all parties in complex projects like these;
• how a unified user experience process, combining usability and interaction architecture, delivers validated innovation.

Labels: architects, fundamental, ucd

—ps

0 comments, link‐ins, forward this posting:

     

users, vision + architects /3

September 28, 2006, 00:23

After the summer break, let’s continue with the next instalment in this series, which deals with the section in the article by Don Norman, titled ‘why might hcd be harmful?’

‘…HCD has demonstrated clear benefits: improved usability, less errors during usage, and faster learning times. What, then, are the concerns?’

Don Norman

Following this quote, Don touches upon three interrelated concerns, each of which I will discuss below.

emphasising learning

The first concern is that one is actually customising the software for a limited number of users. I want to go deeper than that. My concern is that one is actually customising the software to improve the ease of learning for a limited number of users.

Ease of learning competes with ease of use and ease of remembering. One has to strike the right balance between them in each project, using 3E’s analysis.

The human‐centred methods usability folks depend upon are uniformly biased towards measuring and optimising ease of learning. This is inherent to the methods, and all usability professionals I have talked to agree with me on this.

The result is that with human‐centred methods one shortchanges the ease of use and ease of remembering requirements of the software.

discrete and limited

The second concern is that of not achieving seamlessly scaling software.

Scaling software offers a stable but discoverable environment which grows more sophisticated as the user masters the activity—and this by the way, can take years.

Human‐centred methods employ a limited, discrete number of users in limited, discrete number of exercises. This does nothing to uncover the seamless, incremental nature of software use. What should be a smooth ramp is analysed and modelled as a (preferably) three‐step stairs.

sprawling software

The last concern is that of loss of cohesion. No powerful, elegant interaction models can be harvested from users, but you do get lots of personal feature requests. Both of these work in the same direction: confused, sprawling software.

In no way does this lead to a compact concept for natural working environment, where the software allows straightforward actions that can accommodate any kind of activity.

instead…

All three concerns are interrelated, and there is also where the solution lies. It is the big picture.

It is perfect to use usability methods to map out how the user thinks and works. But then it is time to create value and this is an architectural process, asking for strong concepts. It is then perfect again to debug the concept, with usability testing, but it is the architect that keeps the model intact during these necessary changes.

Interaction architects are constantly aware that they are taking decisions for anywhere between thousands and tens of millions of users. They value the input from usability methods, but also know where this value ends.

next…

…stay tuned for the fourth article, dealing with information architects.

Labels: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting:

     

back from the m+c 06

September 14, 2006, 15:50

I came back from holiday at the end of August, and could dive straight into the final preparations for my tutorial session for the usability professionals’ track of the mensch und computer 2006.

For a practical example to illustrate the tutorial with, I selected the tv‑browser. I had already developed the product vision and the user scenarios together with the project team. An hour and a half session flies by once you get a discussion going, so I had to allocate most of the available time to the essentials:

• show how I developed the product vision with the project team;
• explore with the audience new interaction designs, based on the product vision.

so, how did it go?

A big surprise was that the hands‑on practical sessions were hosted in a steep lecture theatre. So I could forget about my idea of letting the people sketch interaction for 15 minutes while I walked around and coached them. Also because of the steepness of the theatre, I could only see the first two rows of people, the rest where already too high up to see their reaction and to communicate.

I asked all the audience to sit in the first three and a half rows, to be able to discuss without the need for a microphone. I really enjoyed the discussion, and I could see that there was a resonance with the dyed‐in‐the‐wool usability practitioners who have been struggling with projects where defined goals where a luxury. The technique of kicking off a project by writing down a product vision was an eye‐opener for them.

any revelations?

One thing I learned to stress more when exchanging thoughts with usability people, is that sandwiched between the user centred phase of surveying and observing users to get a feel for the domain, and the user centred phase of usability testing to validate and incrementally improve the software prototype, there is the not user centred phase of creating the concept for the interaction.

In the concept phase the value and the inner strengths of the software project team have to be expressed. It is the interaction architect who guides the development and graphics team to achieve this.

I noticed in my—and also in other—sessions, that for many usability professionals the concept phase is a black hole in the middle of their user centred process where they lose their footing, and try to regain a sense of security by employing user involved brainstorming and sketching techniques. This passes the creativity buck to the user group. Alas, where it comes to interaction, users are a most reactionary force.

other sessions

The day after my session I had time to attend some lectures, and of course I had to see usability of presentation software by Meinald Thielsch, having done the openOffice Impress redesign project last year—see our lecture. The gist of the session and the big surprise: there is almost no published usability research available on powerpoint & co. I was surprised to learn that by performing the expert evaluation and redesign of Impress, I obtained some pretty rare expertise.

So it turned out that with Meinald, Matthias Müller-Prove from Sun (starOffice/openOffice) and me in the room, we had a remarkable high concentration of worldwide presentation software experts. Meinald is in Berlin regularly, so we’ll have the chance to meet up and swap stories.

That’s it for now, stay tuned for more episodes in the users, vision + architects series.

Labels: fundamental, product vision, ucd

—ps

0 comments, link‐ins, forward this posting:

     

team spirit

August 03, 2006, 10:45

Picture this:

An interaction architect is hired to lead a user centred design team on a very important project. First day on the job she discovers that some of the team are fine at UCD techniques (interviews, paper prototype testing, usability testing), but are completely missing the vital element in the middle—interaction design.

…or else…

She needs to take her team out of their comfort zone. If they don’t do the design, the business teams will do it, and we all know who we prefer to be designing interfaces…

So she posed the question if training techniques like peer critiquing could be used to get the team up to speed on interaction design.

thousand year old advice

Here is what I replied:

‘I propose that you steal from the thousand year old practice of architecture.

‘You are the principal architect. You were already contracted for that role, so no problem there. All major decisions have to be taken by you. You keep the model(s) pure and in one piece under the avalanche of input, feedback and usability test results.

‘You can multiply yourself by making whole UCD team associate architects. Either solo or in pairs you let them work on a certain sub‐system. They’ll have to do most of the legwork. In one or two meetings a week you work together with each person or pair. Here all decisions are taken and the design actually advances.

‘I don’t think you need a coordination meeting with all the associates. You coordinate in your work meetings, and if the UCD team sits together then they can cross‐pollinate there.

‘By working in this way they can learn a hell of a lot from you, and maybe one of them has got what it takes to be an interaction architect, and will float to the surface.’

Labels: architects, fundamental, ucd

—ps

0 comments, link‐ins, forward this posting:

     

users, vision + architects /2

July 29, 2006, 00:33

Let’s move on with the next two sections in the article by Don Norman, starting at ‘human‐centred versus activity‐centred…’

‘Successful devices are those that fit gracefully into the requirements of the underlying activity, supporting them in a manner understandable by people.’

Don Norman

‘Does this UI optimally support the activity’ is one of my key criteria when I perform an expert evaluation, or when selecting from different interaction design variants for my clients.

Supporting the activity is the difference between UI that ostensibly makes the functionality available to the user and UI that makes the activity a piece of cake, and the software a true joy to use.

‘only software that supports the activity adds user value, and is worth using’

ps

Hitting the sweet spot where the UI optimally supports the activity is a great development team motivator. On every project I work on, the eyes of all involved start glowing when we have that Zen experience: we got it. You can see the developers calculating how with a little bit of effort they can put together this really cool piece of software.

‘only software that supports the activity adds company value, and is worth developing’

ps

users will adapt

Actually, users suffer in silence, when using software. This leads to the ‘we did not get any complaints’ phenom­enon. There is a backlash from this when it is time to innovate.

Remembering the last time they had to learn how to ‘work around’ the current UI, which does not support their activities, users fight change hand and tooth. Many parts of the software industry are stuck in the dark ages because of this.

The only way to break this loop is to hit the sweet spot. Show people UI that optimally supports their activity and they’ll want it, right now. They will have their Zen moment: this is the best thing since sliced bread.

highly efficient machines

It is the interaction architect who takes the responsibility to lead the development team to the sweet spot. To focus on the activity, take a collection of features, functions and technology and to shape them into a nifty, highly efficient machine that supports the activity.

next…

…stay tuned for the third article, dealing with user testing and ease of use.

Labels: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting:

     

users, vision + architects /1

July 18, 2006, 17:52

So let’s get started with the article by Don Norman at the top‐left corner, and work our way through the introduction, up to the musical instruments.

the paradox

Norman starts off by observing a paradox:

• there is quite a bit of software in this world that, while produced according to human‐centred principles, is complex and confusing;
• there are lots of tools and objects (not software), that have been made without any human‐centred design methods, but that are used successfully across the globe.

Norman goes on to explain that the latter may be the result from a deep understanding of the activity performed. He then defines activity as the big picture of what people do.

In the final part of this introduction, Don shows—with examples—that it is quite normal for people to adapt to rather artificial systems, simply in order to get things done.

living with the paradox

The 99.9% of functional analysts, GUI developers and multi‐media/web designers out there, who work on projects that involve no human‐centred design at all, may feel vindicated by all this. And by the way, all those projects that ‘ask users how they prefer their GUI’ are part of the 99.9% (an upcoming instalment will cover why).

We all have read the reports about how some of the top‑5 software companies in the world (in revenue) have impressive usability departments, and are adviced by the biggest names in my industry. But I have to say: where did all the effort go? Look at the market‐place indicators:

• a cottage industry of training companies for this software (official slogan of one: ‘we are the aspirin for the headache of having to use xyz’);
• project implementers for this software relaying to me their customer’s response: ‘oh please, not xyz’;
• the wide‐spread reputation among users of this software.

stop smiling

It is my experience that those 99.9% of software/multi‐media/web projects are not achieving the second part of the paradox. Because the ‘deep understanding of the activity’ is missing.

As long as the project team keeps working at the level of features and functionality, it will not understand the activity. It is staying within the relative safety of supplying an addictive commodity (new features) and practising UI as a technical discipline.

Only when when the team can leave this level behind, and use methods to acquire this deep understanding, to get the big picture, then I say: ‘welcome to interaction architecture.’

next…

…stay tuned for the second article, dealing with highly efficient machines.

Labels: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting:

     

users, vision + architects /intro

July 14, 2006, 19:29

Two weeks ago a link was posted on the iXda mailing list to an article by Don Norman on what he calls activity‐centred design. I finally got around to reading it, and check out what that entails.

What Norman describes in the article greatly matches what I have experienced and learned myself in the past 13 years in this industry. This has resulted in the methods that I have developed and put into practice at m+mi works.

the series

By the time I finished reading the article the idea had been born to publish a series of blog articles, where I comment, expand upon and put into perspective the different themes in Don’s article.

So stay tuned for the first article, dealing with the paradox.

Labels: architects, fundamental, ucd, users/vision/architects

—ps

0 comments, link‐ins, forward this posting: