publications

from open source to symbian

November 03, 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, practical

—ps

0 comments, link‐ins, forward this posting:

teaching interaction /09

July 28, 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

—ps

3 comments, link‐ins, forward this posting:

notes from san francisco: testing 1‑2‑3

May 06, 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:

we were relying on the actual labelling of the quick presets to communicate what they actually were;
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;
the preview does not contain enough information to show what a quick preset completely entails;
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:

all zap and no design

October 29, 2008, 01:16

A week ago I was at zap your PRAM, an un‑conference ‘for people who don’t like going to conferences.’ Here are some of my favourite reports from other participants: Stephen, Deane, John and Deb.

It was a remarkable event. Instead of terrible air conditioning there was a log fire in the central hall spreading a wonderful scent through this old mansion. Instead of awfully calculated ‘networking’, it was totally natural to talk to a bunch of interesting people.

dissenting voice

Steven Garrity had invited me to participate on a panel discussing the value of design. He proposed that I show the impact of design on GIMP or openPrinting. Instead I thought I could spice things up by talking about my problems with the word design, along the lines of my recent I’m not a graphic designer post.

Steven thought that was ‘…potentially contentious, which could be fun.’ Here is the gist of my ten‐minute talk:

I am not a designer, part 2

I am simply not able to call myself an interaction designer. The interaction part is brilliant, it is all about flow, actions in time to achieve certain goals. The problem is the word design, which has been hollowed out over time.

Hollowed out…

…by consumers: aka users. They perceive and value design as the outer shell of an object, website or a piece of software: ‘making it look cool.’
…by clients: of designers: the producers of said objects, websites or software. They share the consumers’ outlook on design and are happy to superficially cater to it. Adding insult to injury, they schedule the design at the end of development processes, as a special sauce that gets poured over the actual product right before serving.
…by designers: who seem happy to participate in this game between the two groups above and deliver those outer shells, that special sauce.

meanwhile…

Designers are forgetting to solve the problem. Forgetting that when something needs to be designed, it means that it will interact with people. That this interaction with people defines what this artefact, this object; website or software, actually is. That designing means making it work, beyond a pile‑up of commodity functionality.

common theme

The difference is empathy. At zap your PRAM that turned out to be sort of the theme‐of‐the‐day. Hannah Donovan, lead designer of last.fm, had already held an excellent talk in the morning that heavily featured empathy.

To me empathy means feeling the pain of users. Yes, in your stomach. Instinctively knowing that ease of learning, ease of use or ease of remembering targets are not met. And it is keeping you awake at night. Empathy is what it takes to be a designer.

a picture is worth a…

At my talk I had to show at least one example to get the non‐designer‐geeks tuned into what I was talking about. Some well‐known website where obviously money is spent on ‘design’ but problems do not get solved. Ebay came to the rescue:

Top‐left next to the ebay logo we see me being greeted. That tells me I am signed in. See the two red buttons at the bottom of the pic? Their message (sign in or register) contradict the fact that I am signed in and destroys my confidence surrounding this concept.

Now I do not know how many designers were involved with producing the pieces with which this page is built up. But I do know that one designer with a good dose of empathy should have been in charge of making the whole signed‐in concept work.

1971

There is nothing new about this story. In 1971 Victor Papanek published a book titled: design for the real world. Focussing on product design, this book is full of intriguing ideas, concepts and challenges that are applicable to interaction design today.

One central theme of the book is that product designers are creating shiny junk that is designed to sell, but fails to work even according to basic criteria. Think of american cars at the turn of the ’70s: every year new huge impressive‐looking models, with same‐old technology under the bonnet and total disregard for road‐safety issues.

golden showers

The US design establishment was really grateful for Victor pointing out the elephant in the room and asked him to resign from his professional design organisation in the US. I should blog one day about the long‐tail impact of this book.

the big picture

I wish designers would start designing, with a healthy dose of empathy, focussing on solving the real problems. As soon as that becomes the norm, I will be happy to call myself an interaction designer.

Labels: fundamental

—ps

0 comments, link‐ins, forward this posting:

the armpit of usability

September 20, 2008, 11:27

I remember it clearly, it was during the first world usability day in Berlin, during a lecture by Jochen Prümper on productivity and SAP. He was talking about the relationship between verticality and usability. Suddenly, years of project experience and analysing software products gelled.

down the ramp

The graph below shows how the average level of usability ramps down to zero, depending on how vertical the market of a certain type of software is:

Software gets more specialised as we move from left to right:

general: intended to be used by everybody. e.g. desktop environments; web browsers; email, chat and call software. Office applications live on the border with the specialised category, with inherently lower usability.
specialised: not general‐purpose but still used by many in many different situations. e.g. graphics, drawing, charting, outlining, presentation and project management software.
vertical: focussed on supporting one profession or hobby only. e.g. CAD, accounting, simulation, audio/video production, genealogy software.
bespoke: made‐to‐order software: projects instead of products. Includes custom implementations of software products (SAP et al). Both the number of users and developers can range from singles to thousands.

‘I am doing just fine…’

What is remarkable is that this usability ramp is matched by an identical average willingness to work with interaction design and usability professionals:

cause and effect

I am convinced that the primary driver of the usability ramp is contact between users and developers: the more vertical the software, the more direct the contact between them.

There may still be a layer of (project/product) managers or functional analysts between these two groups. But the more vertical the software, the more tempting it is for these folks to wash their hands of user requests and pass them on directly to developers. The customer asks—and pays—for it, no?

mind the void

Because users are living inside the software they use, for them innovation seems to consists of yesterday’s software—like it has always been—with some new features added. A lack of real innovation combined with feature‐bloat equals destroying the little usability that was there to begin with.

So the more vertical the software, the more its development is driven by reacting to what users ask for (features!) and fear of changing ‘like it has always been’ through innovation. And that ramps usability to zero.

splendid isolation

At the general end of the ramp the relative isolation of the developers forces that they have to think more systematically about their UI, which is beneficial to usability. Still these developers make all the classical mistakes—like imagining themselves to be typical users—which limits severely the maximum of usability that can be reached.

Everywhere along the ramp the exceptional occurrence of good usability raise the average. These exceptional specimens have ignored what users asked for and instead given them what they really needed. They have innovated their UI beyond ‘like it has always been’ and not fallen into the ‘people are used to outlook’ trap.

The quickest and cheapest way to get there is to integrate interaction and usability professionals in your development processes. But…

‘I said: I am doing just fine, really…’

…then there is the work‐with‐pros ramp, which I have used since its invention to quickly estimate if a company will really go ahead to improve their usability, or are just talking the talk. It holds up pretty well up to now.

At vertical‐software companies, the domain knowledge they took the years to gather about their niche markets is considered a barrier to entrance to interaction and usability professionals: how on earth could we help them? I have given up on trying to explain that we are highly experienced in getting tuned in in a matter of days into the activity of their customers, in dimensions these companies did not know existed.

penny‑wise

When it comes to bespoke software, it is very simple: unless the customer insists on interaction/usability pros on the project and is prepared to pay in full for them (including a nice mark‑up for the software company), it is not going to happen. Any other interaction/usability set‑up is a direct threat to the bottom‐line of software companies and their room to fudge/negotiate a project into a ‘finished’ state.

Looking at both ramps—seeing rotten usability and slim chances of that changing at the sharp end of the wedge—I have dubbed vertical‐market and bespoke software to be the armpit of usability:

the implications for open source

Open source software has a reputation for especially bad usability. I say: it is not that much worse. From my lofty position there is not that much difference between awful (commercial) and goddamn awful (open source) usability. Both decimate our productivity and daily joy‑of‑use.

I see open source tracking the usability ramp of commercial software, starting off lower at the general end. By the time commercial software slides into bespoke territory, open source does not fare worse:

The difference is that because of the community character of open source, developers are more in direct contact with users than their equivalent commercial developers. This makes open source developers work more ‘vertically’ than they have to, at the cost of usability.

a win‐win situation

In the future usability ramp and work‐with‐pros ramp will multiply to cause a quadratic effect for the former: at the general end, interaction and usability professionals will steadily improve average usability, while the armpit of usability will be as miserable a place as it is today.

Labels: fundamental, practical

—ps

2 comments, link‐ins, forward this posting:

to Istanbul via Tokyo

July 18, 2008, 14:09

Last week I was on the road for openPrinting. First a couple of days in Tokyo to discuss with the Japanese printer manufacturers my printing dialog design. There was appreciation and encouragement, but the best news last week was that the printing dialog is scheduled to go in all major linux distributions next spring.

With that under my belt, I spent a couple of days in Istanbul for guadec, the GNOME developer conference. I did a presentation to raise awareness among developers for openPrinting.

the 8 rules of printing interaction

For my presentation I condensed the challenges, findings and solutions of printing interaction into eight rules:

1st rule of printing: printing does not exist

m+mi works’ partner company, relevantive, performed user research at the beginning of this project. It showed that for users there is no worthwhile, productive activity between the moment they want to see something printed and the moment it comes out of the printer.

Printing, like streetlights, is infrastructure and it just has to work. This has important implications as we will see.

2nd rule of printing: printing does not exist

When I got started on this project in October 2006, I evaluated all printing dialogs for GNOME, KDE, windows and OS‑X. The overall impression was one of stagnation, a time warp back to the mid‑nineties. Only OS‑X is inching forward, getting ahead of the others.

Since then I have learned where the stagnation comes from: no one can be bothered to do the development work. This ‘can’t touch this’ approach was again palpable at guadec. Delivering an innovative interaction concept has broken this negative spiral. Alex Wauck is developing my new dialog design, for GNOME and KDE at the moment.

3 levels of printing

Taking the paradox of the first rule to its logical extreme, we introduced three levels of printing.

level 1: Printing that just works. Users know for 90% of the printing they do that ‘it will be OK’ when done like last time. As the first—and probably most important—innovation in this project, we complement today’s Print… command with ‘Just Print’, which shows no dialog and prints using defaults and last used settings.
level 2: A basics level of involvement: what printer; maybe set a quick preset; check the preview; done:

level 3: Detailed. Parameter. Tweaking. It is ironic that within the openPrinting project we will spend most of our time, discussions and effort on covering this single last percent of usage.

4th. wysiwyg is overrated

There is no better way to derail a discussion about printing than by using the example of printing a word/openOffice writer file. These applications are one of the few out of tens of thousands where the data is already paper‐formatted on the screen. That takes our mind off an important part of the process.

Spreadsheets; web browsers; email; MP3 collections (iTunes); anything based on a database: all these applications will have to put their data through a transformation to get it on paper, when they print. This is exactly the point where application and printing infrastructure have to cooperate most.

5 million use cases

Being a generic piece of infrastructure, printing turns out to have as many use cases as there are users. Try to take the encyclopaedic route and map these out: you will go mad with an exponentially ballooning amount of variants.

Life is easier being a printer. Each model is made in relative limited numbers for a specific market. This focus is useful for the printing dialog design. But I can not run a design project saying ‘gee, everything depends on the printer model.’ So early 2007 we surveyed the printer market and formed the following printer clusters:

This covers more than 95% of the market. I am in the process of designing a printing dialog for each cluster. Printer manufacturers can customise these best‐practice examples for their models.

6th. unknown: good printing dialog

What is the ideal layout for a printing dialog? I can tell you that only when I know the specific user’s goal (one of those five million), in the context of the application that is used and the printer that is targeted. Of all of us, only that specific user is present when these three meet.

The solution is user‐configured printing dialogs. Users shape the dialog so that they can achieve their goal for that print. The dialog configuration will be persisted as it was left, for the particular user + application + printer combination. It will be ‘just right’ next time that user prints from that application to that printer.

7th. tabs considered harmful

I am talking about the tabs, at the top of the dialog below, that segment the printing parameters into technical categories. Apart from the danger of separating parameters that were related or putting one in the wrong category—both from a particular user’ point of view—there is a more fundamental problem.

Assume six tabs as shown here. And the better‐than‐real‐life situation that all printing parameters are evenly distributed over the tabs and that users actually know where to find each parameter.

is it not a pity to have to change tab once to set one parameter? there is a 83% that this occurs;
is it not annoying to have to change tab twice to set two parameters? 75% chance;
set three parameters, what is the worst that could happen? to have to change tab three times: still a 50% chance.

That is an untenable situation. Tabs work great in some situations—e.g. tabbed browsing, preferences dialogs—but not in a printing dialog.

8th. tags not tabs

The solution is to associate multiple printing aspects with each parameter instead of just one category. Tags instead of tabs:

As a result from rule five, this mapping will come from the printer (PPD). Implementing rule six, users will configure their dialog by selecting the aspects (tags) that interest them, seeing as a result all parameters they need in the dialog (animated gif):

printing rules, OK?

Those are the 8 rules of printing interaction. Stay tuned for a small encore, the guadec special: what about pdf?

Labels: fundamental, openPrinting, practical

—ps

1 comments, link‐ins, forward this posting:

I’m not a graphic designer

March 26, 2008, 13:35

I really enjoy inspired graphic design and typography. Whether on screen or on paper, I appreciate the added value when a master of these crafts has pulled through a bold vision, down to the oh‑so‐important details.

Having a heightened perception of the two crafts, I have read about their theory and techniques during the last twenty years. And I am able to apply some of that, for instance in my presentations, which are not of the ‘force‐fit the powerpoint template’ variety.

at the interface

This perception and knowledge also enables me to work and communicate much better with graphic designers and typographers on my projects. I understand their point of view: it is not about making it look cool, it is not decoration. I talk in their terms about goals and possible solutions.

Which is important since the interaction architecture (making the ‘building’ function) sets the scope and boundaries for their design (the ‘interior,’ so to speak). Both of these have to be up to scratch and made in cooperation, or else the result will be a damp squib.

however…

But I know I am an amateur in graphic design and typography. From Latin: amator, meaning loving these crafts, I must also admit that I am no good at them. Whenever I try, I futz around, endlessly. It has all the symptoms of not being competent: not knowing where to start; no vision and steady direction; and most telling of all: not knowing when I am finished.

I am still ashamed of having made the first business card and first two websites of m+mi works in this way. And have been surprised when professionals had anything nice to say about them. What a relief, when I hired a graphic designer/typographer to work on the current website.

Yes, I still had to do all the interaction architecture work for the website (of course) and the close cooperation takes effort. But getting a typographical system, color system, page designs, logo, patterns and illustrations delivered competently was worth every penny.

In short, I’m not a graphic designer, nor a typographer.

what about you?

I meet quite a few people whose job is interaction designer, interface designer, screen designer, (G)UI designer, user experience designer, web designer, et cetera. And on those occasions there is always something in the air: that we work in the same ballpark, cover the same bases.

Sooner or later this turns out to be not exactly true, more often than not. Over the years I have developed an acid test to see where somebody stands:

‘if you feel that photoshop or GIMP is a vital tool for your design work, then you are not in interaction design, you are in graphic design’

the ps acid test

You don’t agree?

flip that

First of all if you were in user interaction then you would know it is all about structure and pixel‐based applications are simply not conductive towards radical changes of the proportions and order of an interface. It should take five minutes max to do that, not at least half an hour.

You would not dream of using photoshop or GIMP if you had to do actual interaction design with any reasonable efficiency. Makes me wonder about these job ads for the types of designers mentioned above, that not only list a full suite of usability skills, but also full proficiency with the whole CS3 suite.

Between all that usability surveying and graphic design, is there going to be any time left to get some actual interaction design work done?

party like it’s…

Second, if you were in my ballpark, you would know that next‐generation user interaction can be fully created and painstakingly specified using the technology that architects used in 1908. Paper, pencil, a typewriter and gaslight is all it takes. No electricity required.

This is because the most important work of interaction architects is done with our eyes closed—or in my case, staring into infinity.

Realising the product vision with a bold interaction vision; seeing how everything is connected; moulding the flow of a series of activities; taking the point of view of a million users; reducing complexity; reducing clutter: none of that is done in front of a computer screen.

once removed

Not a line I draw ends up on an end‑user screen. Not a word I write is compiled into code. Not a sentence I say instructs users. I draw, write and talk to enable the specialists I work with to excel at what they do and realise inspiring software for my clients.

I’m not a graphic designer, I am an interaction architect.

Labels: architects, fundamental, product vision

—ps

3 comments, link‐ins, forward this posting:

radio interview + openPrinting

January 18, 2008, 11:06

Last Saturday I was at the comfortable—but no less professional—podcasting studio of Chaosradio (host Tim Pritlove’s home). The discussion was easy‐flowing and the result was a podcast of almost two hours (in German) about usability and interaction design.

It was great to do the podcast together with usability consultant Ellen Reitmayr. Not only have Ellen and I been working together for years, on projects like GIMP, openPrinting and openusability, and had a complete story to tell about that. Also we have been discussing and exploring for years the central theme of the podcast: the way usability and interaction architecture integrate and complement each other.

In a similar way Ellen and I were able to integrate and complement our stories from our own profession’s point of view during the podcast. The fact that we have contrasting opinions and diagnoses of mainstream topics like ‘how good is the UI of windows/office/mac OS‐X?’ spiced up the conversation.

last chance saloon

As mentioned at the end of the podcast: the application period of the season of usability openPrinting associate interaction architect opening lapsed on January 10th. But I am giving it a couple more days, so if you are a finishing student/starting professional and want to work with me on a cool, challenging and high profile interaction design project: apply this weekend…

Labels: architects, fundamental, openPrinting

—ps

0 comments, link‐ins, forward this posting:

10 reasons why you can’t morph a mobile into an iPhone

November 14, 2007, 18:29

Last thursday was world usability day. The local event was a big hit, the auditorium was packed. At some point, there was standing room available only . Apart from helping with the organisation and presenting the morning session, I also lectured in the afternoon:

why one cannot morph a mobile into an iPhone (also not with usability)

ps’s lecture at the berliner wud 07

Along with two spicy controversies in the title, I had chosen this topic to be able to share my analysis and hands‑on experience in this market segment. It was pure coincidence (I swear) that the following day the iPhone was launched in Germany…

You can have a look at the slides (pdf, 3.3 MB). But they contain big pictures, a couple of big words and no narative—like a good presentation should. So read on if you want to get the story…

161.000.000

That was last wednesday’s number of results for the word ‘iPhone’ in google. Today it is millions more. And that for something that was unknown on the first of January, 2007. How can it be that everybody writes and talks about the iPhone, even queues around the block for ‘a mobile’?

I will show now ten reasons why you can’t morph a mobile into an iPhone:

10. hardware

The most important piece of hardware of the iPhone is Steve Jobs. I am not trying to polish his already shiny ego. Instead, I am talking about his instinctive understanding that once a piece of software leaves the engineering department, user experience is everything.

To be able to produce inspired software, the top boss has to believe in great user experience and kick everybody’s ass to get it done. In huge companies a VP will do, but management below that level will be sidelined when trying to implement proper interaction architecture and usability processes.

leadership or bust

The upshot for interaction and usability specialist is that if you notice that your top boss is not actively supporting you, you might as well quit. Your work will be destined for somebody’s desk drawer for ever. Managers who totally believe in great user experience: you will have to rise to the top before you will get your way.

As for the top bosses: no general usability guidelines or usability testing of your current software will produce any greatness. If you do not feel how bad things are right now and are not prepared to kick ass, then forget about producing something as inspired as the iPhone.

9. product vision

When analysing an iPhone you will notice the conscience decision not to compete with blackberry & co. It is part of a clear product vision and this enabled Apple to take with confidence the decision to ditch the keyboard and go for touch screen. We will see that this was rewarded with plenty of room for joy in the UI.

Choosing what your software is not is one of the most difficult things for a development team to do. Avoiding tough decisions, ‘does everything, for everyone, with universal value’ is the usual outcome.

no vision, no product

I do not work on projects where the key people are not able to formulate a vision, with my help, within the first two days. There is then simply no basis for great interaction design. Without a vision, usability testing will yield trivial incremental improvement, nothing inspired.

8. (really) hardware

On the iPhone, the single hardware button that takes you to the home screen and the seventeen software icons on that screen that take you into applets, are an integrated system. That may sound normal, but too many times I have been asked to create new interaction architectures for hardware platforms that were already a fait accompli.

It is difficult to tailor UI for hardware that has a one button too many, or is missing one. If the hardware and software concept is not developed in tandem, the result will be and feel patchy.

software + hardware = one

From experience I can tell you that the hardware proximity sensor and accelerometer of the iPhone are simply vital for creating great software interaction with such a big touch screen. The iPhone is different from mobiles in that hardware and software form one single concept.

7. features

The iPhone has one third the number of features of a normal high‐end mobile phone. And that is not because they did not have the time at Apple to include the other ²⁄₃. Instead, they made the necessary choices.

When I started working in the mobile phone industry, my colleagues told me that because of the immature market, competitiveness simply meant more features. Ten years later and the industry still has not grown up.

mature on features

This circle of dependancy is diabolic. Users and features are like children and candy. They never say no, even if stomach pains will surely follow. For developers, it is the easiest thing hand out. New features are a commodity. If you have no clue how to improve your software, you can always add new features.

One cannot achieve iPhone greatness if one is not prepared to make tough choices on which features really matter. This counts for any kind of software.

6. joy of use

I am not talking about gimmicks here, although the iPhone has a couple of them, like the big shutter when you take a photo. I am talking about traits of the UI that in two years time will still put a smile on your face. One of these is the screen–to–screen navigation, which fluently slides the new screen in and the old one out in one movement.

Not only does this improve usability by creating a connection between the two screens and using the directions to code forward, back, up/down a level type of navigation. It is also fast enough and has such elegant movement curves that it creates the experience of handling a smooth little machine, with great fit and finish. It has the quality of handling a Leica camera.

functionalism is not enough

Like traditional architecture, interaction architecture has gone through its functional phase where productivity was everything. And there is nothing wrong with bulldozing the time wasting interaction of big, ugly software that tends to be used in offices.

In this post‐modernist world, joy of use counts. Forgoing gimmicks and getting it right lends a quality feel to a software product.

5. display

Comparing the size of an iPhone screen to that of the original macintosh, we see that it is not that much smaller, 480×320 versus 512×384:

an overlay of the iPhone and mac screens

The original mac is where the desktop publishing revolution took place, people made posters and newspapers on those screens.

ambiguous device

A suspicion rises: is this a tablet computer or a mobile? The iPhone covers the middle ground in this regard. We will see the consequences.

4. paradigm shift

When designing applications for the iPhone you could try the mobile phone approach with grids, lists and all the actions in option menus. However, from experience I can tell you that is a dead end. The applications on the iPhone break away from the mobile paradigm.

A case in point is the web browser, where they ignored the mobile WAP browser and used the big screen to put a normal web browser, using the random access touch input for zooming and panning. A great experience, instead of a damp squib.

full use of full‑screen

‘Avoid mobile look + feel like the plague and use the whole screen’ is what I can recommend anyone developing for the iPhone. Only in that way one can achieve the required inspired interaction.

3. telephone?

Phone is one of seventeen icons on the home screen of the iPhone. It shares the ‘top shelf’ with iPod, email and web browsing. This illustrates that making call does not have absolute first priority.

We could go further and ask ourselves why is it called an iPhone? iWhatchamacallit would be more appropriate.

don’t call it a…

The iPhone is a Trojan horse. At Apple they sidestepped the question of creating a better mobile by creating a modern communication device that happens to make calls and send SMS’s, then stuck the phone label on it to get it adopted.

2. holistic

Although it is a fuzzy, vague term, holistic does apply to the iPhone. In the eight preceding points, we have seen how everything fits together. Sure, dozens of persons worked on the iPhone, but the result feels as though it was created by a single hand.

simply holistic

This holistic user experience is the key to simplicity. ‘Don’t make me think’ is achieved via seamless continuity starting with leadership, product vision, via hardware, ¹⁄₃ of features, ending in paradigm shift and joy of use.

1. jump factor

Below we see every mobile ever made cluster together on the left and the iPhone as a lonely star on the right:

Incrementally improving a mobile so that it leaves the cluster and approaches the iPhone is impossible. It is actually easier to join the iPhone’s position from above, below or the right. The only way to get there, is to jump.

conceptual innovation

The jump factor needed is innovation, which is by nature a conceptual undertaking. Given the right leadership, product vision and ¹⁄₃ of features, interaction architects are able to make that jump and deliver a great user experience.

Usability is by nature empirical. This works great to obtain the input that interaction architects need: facts on the table, I always say. Also user testing is useful to validate interaction concepts. Interaction architecture and usability are two complementary disciplines that can deliver the validated innovation needed for iPhone greatness, under the right circumstances.

Labels: architects, fundamental, product vision

—ps

1 comments, link‐ins, forward this posting:

cross‑platform is bunk

October 11, 2007, 17:49

Picture this: m+mi works opens two more offices, in addition to our Berlin ‘headquarters.’ One for functionalist architects (sense and simplicity) in Amsterdam and a cool Mediterranean design studio in Barcelona.

Our company is then operating in three countries. All have a lot of EU law in common and quite similar culture, traditions and mores. It should be relatively straightforward to come up with a common management policy and house rules for all three offices.

holiday cramp

Let’s start with holidays, when our offices are closed. For all the common Christian holidays between the three countries, there are plenty of days where only one or two countries have a day off.

Of course I do not like the overhead of implementing and documenting different holiday schedules for the three offices. And I fear that co‑workers and customers in Holland will be confused when trying to reach our Barcelona office on a Catalan holiday.

not the only fruit

So let’s look at ways to arrive at a single, consistent holiday policy for all three countries:

preferred native solution: It is my company and I am Dutch, so I tend to see the holidays in Holland as natural. So we take those: my co‑workers and customers in Germany and Spain suffer.
grand compromise: also known as roll your own, if there are holidays on the eighth, eleventh and seventeenth, then we will have one on the twelfth: mass confusion among co‑workers and customers.
lowest common denominator: Only the holidays all three countries have in common are company holidays: too sparse a set of holidays, will really upset my co‑workers everywhere.
union of all: If it is a holiday somewhere, it is a company holiday in all three countries: now we got holiday bloat, co‑workers can’t get any work done, customers think we are always chatting in the café.

The lesson from all this is that there is no other choice then to grit our teeth, comply with the law, traditions and mores in each country and focus on doing the right thing for co‑workers and customers within the context of each country.

back at the ranch…

So what has this got to do with user interaction? Well, just like m+mi works operating in three countries, a lot of applications operate in up to four ‘countries.’ They are the macintosh, windows, KDE and gnome desktop platforms.

All four have a lot of UI guidelines in common and quite similar look + feel, traditions and mores, thanks to the Xerox PARC–macintosh bloodline. It should be relatively straightforward to come up with a common UI design for all four platforms.

cross‑platform cramp

But for all the commonality between the four platforms, there are plenty of interface guidelines where one or two or all are different.

In the fourteen years that I have worked on cross‑platform projects, the engineers have never liked the overhead of implementing and documenting different UI for the different platforms. And they fear that windows users will be confused when trying to use the same application on linux.

weasel out

So they look at ways to arrive at a single, consistent UI for all desktop platforms. And so in my career I have seen all variations of the bunker‑thinking above:

forcing the original UI design upon all platforms; especially applications that started out on windows have this tendency: preferred native solution;
roll your own look + feel, the Java route: grand compromise;
use only UI elements that are available on all platforms; makes it impossible to create usable UI on any of the platforms: lowest common denominator;
making everything available on all platforms; means re‑implementing something specific for one platform on all others: union of all.

All of these are as dissatisfying, confusing, infuriating, and user productivity wasting as the m+mi works holiday solutions. It takes a lot of convincing from my side to get the engineers out of their bunker and look at the matter from the users’ point of view.

The lesson from all this is that there is no other choice then to grit your teeth, comply with the law (UI guidelines), traditions and mores of each desktop platform and focus on doing the right thing for users within the context of each platform.

Labels: fundamental, practical

—ps

0 comments, link‐ins, forward this posting:

economic outlook

June 16, 2007, 01:02

two interesting articles in this week’s The Economist. First one is the leader article that accompanies the cover:

think apple. apple and the art of innovation

Some of my favourite snippets:

‘…Apple illustrates the importance of designing new products around the needs of the user, not the demands of the technology. Too many technology firms think that clever innards are enough to sell their products, resulting in gizmos designed by engineers for engineers.’

‘But too few technology firms see “ease of use” as an end in itself.’

‘Listening to customers is generally a good idea, but it is not the whole story. For all the talk of “user‐centric innovation” and allowing feedback from customers to dictate new product designs, a third lesson from Apple is that smart companies should sometimes ignore what the market says it wants today.’

The Economist, Lessons from Apple, June 7th, 2007

economic brain scan

Second, there is the portrait of Mark Shuttleworth of ubuntu. More snippets:

‘A successful South African entrepreneur during the dotcom era, he wants open‐source zealots to lose their religion and concentrate on ease‐of‐use instead.’

‘…open‐source software lags behind in many areas too, Mr Shuttleworth admits. “The community tends to build for functionality, not for comfort,” he complains. “We have to inspire the free‐software world to make the user environment attractive. This takes an order of magnitude more work.”’

The Economist, Bringing free software down to earth, June 7th, 2007

business 101

The Economist sets the agenda for business leaders and other decision makers. The more remarkable then that innovation in user experience is in effect their front‐page story. The snippets above resonate with my everyday business.

‘by engineers for engineers’

This is the norm in software today. Remarkable are the few—and I mean just a few—pieces of software in the world that actually have a functioning user interface. I say it is remarkable that the world puts up with this situation.

One of the things I have to accomplish in each of my projects is to get accepted that UI decisions can no longer be based on the technical structure of the code, nor on the personal user preferences of the developers. They can only be based on solid interaction architecture.

‘an end in itself’

A decent UI is seen as a ‘nice enhancement,’ something we can work on ‘after we have shipped this important version.’ Somehow unusable, off‑putting or productivity‐wasting interfaces are not a serious bug.

The companies I work with are the ones who have realised that in any piece of software that has a UI, the value is created by users, and user interaction can make or break this.

‘ignore what the market says’

Software innovation is not born by listening to markets, and UI improvement does not result from listening to users. Both follow from a keen understanding of what markets or users need.

It is exactly this keen understanding of what users need that companies seek when they approach m+mi works. It is the essence of what we deliver.

‘concentrate on ease‐of‐use’

Usability of open‐source software is generally bad, but that of commercial software is only a fraction better. I see the factors of literally being made ‘by engineers for engineers’ and too much development at the whim of users contributing to the worse position of open‐source software.

The methods that I introduce in the projects that I work on have the same effect in the commercial and the open‐source world: a new awareness that we are not making the software for us, and that value and innovation is created within the project team, if we underpin the UI with a solid concept.

‘an order of magnitude more work’

Yes, it takes work to replace the unusable user interfaces of today with something that actually functions. We are not talking a slight tweak here. But that does not mean doubling the number of GUI developers, and therewith quadrupling the amount of discussion in the project team.

The companies I work with get the specialist in, to do the heavy UI concept work. This stops the discussions in the project team, and lets the developers concentrate on what they do best: engineering of user interfaces.

Labels: fundamental, practical

—ps

1 comments, link‐ins, forward this posting:

teaching interaction

June 06, 2007, 00:43

Mid‐May I was for a week at the FH Vorarlberg, Austria, to teach interaction design. I had arranged for the students to work in project teams: to create a concept for real‐world software, under real time pressure, with a real presentation at the end of the week.

I had asked the students to prepare by reading specific articles about activity based design and my own methods. However, they not know what software they would be designing for. Let’s jump in like they did.

monday morning, 9:00

After getting acquainted, I introduced the software we would be working for: ksysguard, performance monitoring for KDE. Showing processor; memory; network or disk usage, et cetera.

design brief

When I first put my eyes on ksysguard, I thought ‘this application needs an overview,’ a summary that shows the essential. So I set the goal to design a cool object for the desktop, that at a glance informs about the performance and stability of the local or a remote machine.

Oh, and anything that looked like the same old graphs that have been around for twenty years was forbidden.

first things first

While preparing for the course, I had interviewed our customer, the developer of ksysguard, for several hours via irc. It was a typical interview to find out the product vision of the software: what it is; who should be using it and what value does it deliver.

I went with the students through the complete interview, then we discussed and wrote down a product vision:

ksysguard allows to monitor different soft‐ and hardware parameters that influence the performance and stability of a local or remote computer system.

It allows tech‐knowledgeable users, or admins of a few computers, to detect and go to the bottom of (rising) problems, and do something about them.

product vision of ksysguard

The product vision was then approved by the developer.

User scenarios could be skipped for this project. I realised that there is not a wide variety of use that needs to be reduced to the essential. We spent the rest of the day sorting out the functionality that should go into our desktop overview, according to the product vision.

tuesday…

…concept day. I divided the students into two teams and sent them on their explorations. They had to solve the problem of mapping these machine parameters (processor, memory, et cetera) to different display dimensions.

The display dimensions include space, 2‑D or 3‑D; color; transparency; time; texture and animation.

vision driven

Being the part‐time team leader of both teams, I maintained the overview for both teams and ensured that they were solving the right problems. I encouraged the good concepts they came up with, and steered them towards alternatives for the not‐so‑good.

Time and time again, I made a team check the product vision, to focus on the ultimate goal. Aspects like ‘monitor’; ‘performance’; ‘stability’; ‘detect and go to the bottom’ had to be realised by us.

wednesday

The concepts where gelling, we moved from pencil + paper to mouse + screen to prepare for the presentation. An A0 poster and a short animation film had to be produced.

I focussed both teams on producing the minimum of concept visualisation that would have a maximum of impact. One should not have too much blood, sweat and tears invested in a concept, to be able to ditch it when a better solution crystallises.

The teams moved out of our classroom. Christian and Andrea (team 2) worked in parallel at the mac‑pool…

Christian and Andrea working harmoniously next to each other

…while in their atelier, Katharina and Verena (team 1) worked on opposite ends of the project:

Katharina and Verena working at different ends of the room

thursday

Crunch time. In the morning I had both teams sketch out a quick script/storyboard for their film. This way they could keep track of what they really needed to produce and I knew they would not lose the plot.

I showed the teams how to structure their poster. Instead of just showing all the cool stuff, it is better to show first that it was not divine intervention that produced the design, but methodical work.

friday

Usability day at the FH Vorarlberg. Theme: ‘inform with computer animation.’ It was no coincidence that my course was tacked before the uDay, it gave us a real deadline and a real venue for presentation.

I had selected ksysguard from the list of projects at openusability.org because of the animation angle. Animation comes natural when handling real‐time data.

showtime

Bleary‐eyed from finishing the film and poster the night before, we exhibited throughout the uDay to usability and animation professionals:

posters and animations being presented in the hall

I made that into a crash course in engaging people at exhibitions or trade fairs. And an introduction to the number of interesting conversations one can expect during such a day.

Visible in the photo above are the posters:

Watch out, those pdfs (1, 2) are 3.3 MB large. Now, let’s have a look at the individual concepts.

team 1

Disco mirror ball; Saturn ring; lava lamp; the meatball in the pea soup. It was fun discussing concepts with Verena and Katharina. But as usual, these far‑out discussions delivered results.

See the film on youTube.

I am impressed with how they use two dimensions of the ring to display on. On the side of the ring is the instantaneous value of load and cpu usage, and on the top of the ring is the five‐minute history of both:

They did have to take the hard choice to not go into multi‐processor details here, but that choice paid off handily.

I also like a lot how they used animation to display a parameter. When a disk partition starts running out of space, the green fluid starts bubbling, lava lamp style:

The more critical the free space situation gets, the more hectic the animation becomes: cool metaphor.

For more details, check out the poster.

The work of team 1 is licensed under a Creative Commons Attribution‐Share Alike 3.0 License. The authors are: Verena Mayer, Katharina Seidowski and peter sikking.

team 2

‘Circles must be in fashion this year’ I thought when I saw the lyrical sketches from Andrea and Christian. On that Tuesday team 1 was also ‘going in circles,’ and I feared we were going to end up with very similar concepts.

See the film on youTube.

I am impressed with how they worked hard to keep the ‘nothing to worry about,’ everyday look of the desktop object very clean by employing several strategies:

First, they introduced a level of drill‐down in the desktop object, displaying details in ‘pods’ around the central ring. This way details for up to 16 processors cores; disk partitions or memory hogging applications can be shown:

I like how this enables users to monitor details of one parameter for a while.

Second, when an certain parameter needs user attention, then the ring that represents it not only gets an opaque centre, it also grows in size:

This is a clever use of screen space. Whenever users’ attention is needed or users focus on details, most of the overall circle is used for that.

For more details, check out the poster.

The work of team 2 is licensed under a Creative Commons Attribution‐Share Alike 3.0 License. The authors are: Andrea Thum, Christian Haudum and peter sikking.

looking back…

I had a great time teaching at the FH. I would like to thank Philipp von Hellberg for cooking this up with me, and the FH staff for making everything run smoothly.

And thanks to Katharina, Christian, Verena and Andrea for working so hard with me on this project.

Labels: fundamental, practical, product vision

—ps

0 comments, link‐ins, forward this posting:

potsdam conference

April 24, 2007, 00:31

About two weeks ago I visited the two‐day innovationsforum interaktionsdesign conference. It was—very well—organised by the fh potdam, enthusiastically and without any schmalzy commercial overtones. Good job.

presentation style

Over the two days, two factions in presentation style emerged.

classic powerpoint…

Really… plainly… powerpoint. Bullet points containing sentences that were read out loud by the presenter. The smell and fabric of powerpoint was all too clear.

The guys from IBM topped the bill here. They started off with some genuine powerpoint slides from hell. Think 30 bullet points in three columns, or 30 boxes connected by 60 lines to show an integrated process.

Later their slides lightened up a bit, and it became clear to me that those first slides came courtesy of the business consultancy side of IBM. A study in not communicating.

…contra minimalism

Three huge white words on a black background.

A single photographed artefact against a solid white background.

You had to listen to the presenter. You had to make the connection between what you saw and heard yourself. You could not tell which software had been used to produce these presentations.

Some of this went overboard: text either so large, or pressed into a geometric shape, that one had trouble reading it. But in general this was a superior presentation approach.

arts and crafts movement

What a brilliant moment it was when Gillian Crampton Smith explained the audience that interaction design is a craft, mastered through many years of experience. I say it also takes talent to begin with, else you do not make it through the 15 years to become a master. Which talent exactly?

No amount of usability testing can substitute this craft. Gillian went one further and warned against using too many usability methods in a project: it will just squeeze all life out of it. The guys from IBM later proved this, showing a sizeable website redesign project where they applied plenty of market research and usability testing, and came up with zero interaction solutions for their customer.

intuitively, my dear Watson

I met Carsten Mohs at the conference, and during our S‑bahn trip back to berlin we discussed his PhD topic: intuitive. In five‐seconds‐flat we agreed that intuitive user interfaces do not exist. All interaction is learned.

When innocent bystanders talk about intuitive UI, they mean that one of the 3E’s is supposed to be pretty good: ease of use; ease of learning; or ease of remembering.

Carsten is aiming to prove this, but after painstakingly defining intuitive UI, runs in to the problem that it involves the subconscious. Good luck measuring that…

second time lucky

The process of creating interaction solutions however, relies on intuition. The siena blog entry, which is intertwined with this one, contains three examples of this.

The three major solution models described there came intuitively. Yes we sat down to create solutions. Yes, I asked some provoking questions that got us looking in a certain direction. But there was nothing linear and orderly about the way we arrived at the final results.

Even the provoking questions came to me intuitively. Carsten called it ‘intuition of the second kind.’

close encounters of…

The third kind of intuition is the one that makes you realise that a particular solution is the solution. Again it cannot be explained, but suddenly all the dots are connected and you have something elegant that fits the problem exactly. This means one can move on to tackle the next challenge.

For our project partners (developers, managers, graphic designers) this can be perplexing. It is usually only the usability folks who ‘see’ what we mean straight away. We then have to backtrack to construct fully logical arguments to convince the other people we work with.

For interaction architects both forms of intuition are a vital talent. With experience come more ‘dots’ to connect with. And we learn to trust it. Whatever project we get involved with, just use our methods to get involved with the project domain, and our intuition will take over to deliver the solutions.

Labels: fundamental

—ps

0 comments, link‐ins, forward this posting: