on interaction architecture

GIMP’s new free‑poly tool

2008-06-21T13:42:00.000+02:00

Recently there was a heartwarming post on the graphics planet:

‘Another exciting thing that will be in 2.6 (and the next 2.5 release) is the hybrid polygon/free select tool! It is truly a thing of beauty…’

David Gowers, featured on meetthegimp.org

The story of how the the free‐polygon tool came about is one of developer–interaction architect cooperation.

going poly…

The initiative came from Martin Nordholts. He had built a proof‐of‐concept polygon selection tool and was asking me to write UI specification for it. First I asked my self if GIMP really needed this tool. Is it not replicating what can be done with the path tool?

After I convinced myself that it was a good idea to have a polygon select tool, I had to deal with yet‐another‐tool in the GIMP toolbox. One of my goals is to end up with less tools than now, not more.

magic combination

So following my intuition I asked Martin on the irc: ‘is there any way that this polygon tool can be integrated with the rectangle selection tool?’ Martin answered along the lines of: no, but what about the free selection tool?

Brilliant. Not only did I instantly know this was a great idea, I also instantly knew what it was going to feel like to use this tool. Martin and other developers on the irc could not imagine how free and polygon segments could be represented on screen and created by users in an elegant way. I knew within minutes how this was going to work.

small is beautiful

Fuelled by enthusiasm, I wrote the initial UI specification in an hour and a half. It was really a straightforward merge of two simple tools: like before, clicking was going to create polygon segment, dragging free segments. My trick was to place a polygon point at both ends of each free segment, enabling the connection between both types of segment.

I was determined to keep it simple. Concise, straightforward tools like this fill me with more satisfaction than more complex ones—although necessarily so—like the rectangle selection tool (13 pages of specification). In a similar fashion I am more proud of the simple but super elegant applications I have designed for Nokia, e.g. the Translator, than of the complex ones, e.g. the email client.

tit for tat

The refinement of the tool after development commenced is a further example of our cooperation. Martin contributed the 15 degree constraints (using the control key) as seen on other tools and better modification of free segments—rotate and resize—when grabbing one of their handles.

I saw that these were indeed improvements in user interaction and integrated them in the UI spec. Martin relied on me for UI solutions for corner cases he encountered.

One was the issue of whether the polygon points should be always visible—quick to grab, but high visual noise—or only on mouse‐over—clean but slower. I kept in mind the activity of tracing existing images where you want the points to be invisible to inspect if the trace is correct to the last pixel and quick to grab, to adjust a point to the last pixel. I squared that circle by making points visible when the mouse is nearby and figuring out how far away nearby is.

Another issue was that polygon points are really in the way when you want to create another one close or on top of it. This also affects continuing with a free segment exactly from where the last segment ended. My solution: the shift key suppresses existing points, clearing the way to create new segments anywhere.

With all these UI changes, I guarded the conceptual integrity and ensured that we were not introducing bloat, getting in the way of the core value of this new tool.

closing credits

What we have seen here, I see in general in the projects I do. Developers drive innovation on a technology and feature level. Interaction architects create the UI that actually works. UI that is integrated in the overall concept and that supports the activities that users undertake.

In the middle is cooperation between us, where ideas are brainstormed, solutions are cooked up. And where each side determines if this is the right way forward. Developers for the technological aspects and interaction architects for the user interaction.

test drive

Go on, try out the new free‑poly tool of GIMP 2.5. We had a ball creating it for you. You will find it under the trusty lasso icon of the old free selection tool. That is, until we tackle the update of that…

I’m not a graphic designer

2008-03-26T13:35:00.001+01:00

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.

GIMP redux: intro

2008-03-12T11:39:00.001+01:00

Lately, a couple of things have started to orbit each other:

GIMP UI analysis: This is the current phase of our redesign project. And although a consensus has formed among my team about the gist of it, not having it written down as a coherent system means that no coherent improvement can be made to the GIMP UI. Only with a finished analysis can I drive the roadmap that stops GIMP going the way of the dinosaur.
what’s up?: People have been writing me—thanks btw.—asking when they are going to see the results of the redesign project. Renovating a big application is going to take time. In the meantime, it is a good idea to show where we are going. Our project wiki is a place to see us work, but it is not a great narrative to read.
libre graphics meeting 2008: I was already asked for the topic of this year’s lecture. What could I cover that would advance the deployment of interaction architecture in ‘pro’ graphics applications? And for that matter, advance ‘pro’ graphics applications in general?
the big picture: Last and foremost, a nagging feeling that the long list of meso‐level issues in our rough outline are part of a bigger issue, which has to be addressed first. Not seeing the wood for the trees, I need to helicopter out.

bird’s eye view

So I have set myself a challenge with the title of my libre graphics lecture: ‘GIMP: a new simple interface for a complex application.’ That is the big picture. The GIMP product vision mandates it to be a deep, feature rich application that takes commitment to master.

But at the same time there is plenty of scope to radically cut down the visual noise in the interface, improve user efficiency and increase the room for creativity. Only big steps in these departments will ensure that there is a future for GIMP.

live and let…

I have got two months to prepare for lgm and I will do that right here. In a series of ‘GIMP redux’ articles I will go top‐down through the UI. These blog entries will at the same time pop up in the wiki as chapter seeds. There they will evolve, building up the analysis.

There is room for review and feedback, here in the comments, over on the developer list, or via the brainstorm. That will drive the refinement of the analysis chapters.

So there you go: the big picture of what is going to happen to the GIMP UI will be developed in the next months, in time for the lgm 08. And you will read all about it here.

radio interview + openPrinting

2008-01-18T11:06:00.000+01:00

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…

GIMP lecture, berlin

2007-12-09T14:54:00.000+01:00

This Wednesday (12‑12‑7) I will be presenting at the newthinking store in berlin. It’s berlin‐usability‐stammtisch‐Wednesday and I will do a lecture on GIMP, open source and interaction architecture.

Apart from the announced focus on the run of the GIMP redesign project thus far and our professional approach to the top‑10 most requested features, I will also elaborate on the—partially novel—methods developed during the project.

If you are in or around berlin this Wednesday, I hope to see you there. Tucholskystraße 48 10117 Berlin, it starts around 19:30.

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

2007-11-14T18:29:00.001+01:00

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:

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.

next‑generation printing dialogs /4

2007-10-23T15:12:00.000+02:00

At the end of September the openPrinting summit was held in Montreal, Canada. I presented there an overview of eleven months of work on printing dialogs. A number of the summaries I made really drove the message home, so let’s have a look at them.

voodoo child

Everybody loved the motto ‘printing does not exist.’ As we found out during early usability testing, between the moment users think they want to see it on paper and the moment it rolls out of the printer, there is just one big blank. From users’ point of view, nothing worthwhile or productive happens in between.

My favourite equivalent is streetlights: infrastructure that no one notices, until one stops working. One implication of this is that we spend the most time working on dialogs with dozens of parameters that almost nobody uses.

Another is that it is not seen as a glamourous job to work on printing, by interaction folks or developers. Practically speaking, no developer is working to improve the rather dreadful linux printing interaction at the moment. And no one is queuing up to get started.

gold, silver, bronze

I also summarised the three levels of printing we support:

level one: An awful lot of printing is done where users know from the start that the print will be OK. All those emails that get printed. The second, third or umpteenth time that office document gets printed. An estimated 80–90% of printing is like this.
level two: Users need to check that the print will be OK. Or quickly check/set which printer is used. Or that this photo should be printed either swiftly or at super quality.
level three: Fine‐tuning of individual printing parameters. We are talking here about the last 1–2% of printing…

We will support level one printing with just print: an optional bypass of the print dialog. In the file menu—right after the normal ‘Print…’ item—there will be the option to ‘Just print’ (working title): it will skip the dialog, showing subtle feedback that the print is formatting–queuing–printing.

just in time assembly

When you get to level three, what does a good printing dialog look like? As I explained in my presentation: here we see the revenge of the five million use cases. Printing is a generic infrastructure service and I can only say: it depends.

It depends on the actual goals of that user. It depends on the context of the actual application where that user prints from. It depends on the actual printer. And only at the moment where the actual user + application + printer meet, I can answer that question.

That particular moment is when the printing dialog is opened. And that is why we are enabling users to effortlessly configure the printing dialog that is just right, for their goals, that application and that printer. And we will persist this configuration for exactly that user + application + printer combination.

version 0.4

Inspired by the discussions following my presentation at the Montreal summit and knowing the nagging problems that still needed to be solved, I did another round of redesign of the printing dialog. So again first our…

disclaimer: this is a pre‐release version of the design; there are for sure some things missing and small issues to solve; enjoy nonetheless…

First of all, I optimised the default appearance of the dialog for level two printing, concentrating on printer, preset & preview:

Gone are the tags at this level. Also gone are the orientation controls, because the checking of orientation is handled via the preview. A year ago I had identified ‘number of copies’ as the only universal printing parameter that makes sense for all types of printers.

Somewhere along the line I must have confused that with must be universally available. But it is useful only in particular situations, like making handouts. So it was also removed from this level. After all that pruning, it was logical to enlarge the preview area, to harmonise the design.

Let’s open up ‘Control printing aspects’ (animated gif)…

…and then we are at level three.

tags enter the matrix

A nagging problem that was still lingering was the appearance of the tags that configure the dialog. I just knew there are current‐generation UI controls that could serve as a model for this. I found them in Apple’s Garageband:

These have the function of checkboxes—used to build up a list of selection criteria—but are more compact and neat, with less visual noise. Taking that as a starting point, it turned out that for us something even more compact, neat, with way less visual noise was required:

Call it a configuration matrix. It can be implemented with a table widget, but forget about just taking the default table widget. An exercise in toning down is needed to ensure that it stays in the background compared to more important elements in the dialog:

Note that the columns in the matrix have a variable width to optimise the space for the tag labels. The shortest sit next to the longest inside a 200‑pixel column. The mid‑sized tags sit together in their own 200‑pixel column.

To show the configuration matrix in action, here are all the combinations of three of the tags (animated gif):

More full‐size dialogs: first, second, third, fourth, fifth, sixth, seventh, last

summit sumarum

The Montreal openPrinting summit got everybody in the printing community connected again. There is a sense of urgency that this is the chance in the next five years to get printing on linux sorted out.

Folks from both gtk and KDE were there and that gave them a jolt of inspiration to get ready to work on implementing these dialogs. I look forward to working with them.

cross‑platform is bunk

2007-10-11T17:49:00.000+02:00

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.

the making of: GIMP UI brainstorm

2007-09-22T20:02:00.000+02:00

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.

whistling in the dark

2007-09-19T23:24:00.000+02:00

Recently I worked on a project about which I can tell you—typical for my industry—nothing more than that it involves a hand‐held touch screen device. Exiting stuff, no?

Anyway. More interesting was that on our multi‐disciplinary team we had a dedicated sound designer: Aaron Day from Receive‐Transmit.

vroom

First of all his scope is not just sound, but the whole user experience. That made working with Aaron one of those rare occasions where I am able to communicate at native level and work together at amazing speed.

Not having to explain all the time how user interaction actually ticks really helps. This usually only happens when working with usability folks.

bleep

Now I must admit that for the last ten years, I had always thought of sound as something that users turn off. Working with Aaron changed all that.

He promotes the concept of ‘sound that is more felt than heard.’ This involves precisely controlling the vibrator in a hand‐held device, using it like an infrasonic synthesiser.

Then combine that with a bit of audible sound on top for some sharpness. Forget about the boring buzz from your current mobile phone. Instead, think of the click you feel when pressing a key on your mobile.

click

When Aaron asked me to select from a list of ‘sound opportunities’ the ones that really mattered, I said: ‘in those places where we lost the keys.’

By returning in this way the tactile feedback back to touch screen controls, you are able then to really enjoy the benefits: complete freedom to optimise the controls and their layout for every situation.

…

Another great concept promoted by Aaron is three overall sound levels:

hearing and feeling sounds: say today’s key tones;
‘silent’ but you can still feel it: audible sound is still played, but soft enough to be drowned out by ambient noise;
really turned off: and now you miss the tactile feedback from level two.

Instead of the usual « I am really funny, listen to me » approach to sound, this set‑up will ensure that sound will really be a useful part of the user experience.

next‑generation printing dialogs /3

2007-07-23T20:05:00.000+02:00

Another round of working on the openPrinting dialog. As it turned out, it was an exercise in detailed design solving general issues.

The first issue I wanted to tackle was the (not so pretty) vacant space in the dialog when no tag has been selected. So I took the scissors to the dialog:

The idea I wanted to try out was a fluid layout for the tags and a dialog that would be sized smaller in the ‘no tag selected’ case. I cut the tags section in even smaller pieces and shuffled around until the idea worked. Here is a sketch:

rinse and repeat

Also I wanted to address the perceived complexity of the dialog, the gist of the feedback I had received. For this I had to practice what I preach:

‘the most important aspect is that you are able to throw everything out and start again from scratch’

ps, whenever prototypes or mock‑ups are discussed

You have to stay agile as long as possible in a project. Else your hand is forced by existing drawings when trying to solve interaction issues. I ditched the visio files, visio itself, and the windows template. Moved on to omnigraffle, started with a clean canvas.

beyond the frame

I dealt with another issue at this point. Up to now I had been taking the window frame of the dialog into account. On linux the window frame can be any shape, graphic design and color.

To solve that, I literally took the window frame out of the picture. I deducted 30 pixels at the top and 4 for all other sides from the 640×480 maximum size we are working with and set my canvas size accordingly.

narrow down

I started with designing the smaller dialog for when no tags are selected. Before I show how that worked out, first our:

disclaimer: this is a quick‐and‐dirty lash‑up to show you what we mean; there are for sure some things missing and lots of small issues to solve; enjoy nonetheless…

It has also been a while that I have reminded us all that the design shown here is for general inkjet only. The other printer clusters will have at least a different set of tags—mapped to a different set of printing parameters—if not more fundamental optimisations of the dialog itself. Remember that one size does not fit all.

Here are some of the solutions I have put in:

a slightly bolder appearance for the quick presets list, as it has a higher priority than all the tag and parameter stuff;
sized the quick presets list items like I always intended: 1½ times the height of a normal list item, for a single line of label text; multiple label lines: normal size;
shrunk the right column in the dialog to the size of the quick presets list (minus the scrollbar);
flowed the printer + tags section into the right column;
toned down the tags, which turns out to be quite tricky; it is easy to make them look disabled or not clickable at all;
the return of the dogcow, to trace back our heritage.

This all sits inside the actual window frame. Before someone trips over the shadow: that is just a bit of ‘special sauce,’ to make it all come alive:

building up

Next, what happens when a tag is selected? The dialog grows so that the right column gets the same width as the middle one. The tags move up—elegantly—to make room for parameters. The gradient under the tags is not decoration: it forms the connection between the tags and the parameter area:

When more tags are selected, the dialog will need to grow vertically at some point to accommodate them. Before that happens, the tags can still move up a bit to make some more room:

Here are all the combinations of three of the tags, in all‑jerky, all‑dithered animated gif glory:

More full‐size dialogs: first, second, third, fourth, fifth

design on a toilet roll

If most users select up to three tags per application and with eleven tags as shown here, how many configurations are possible? Answer: two hundred and twenty.

How does the interaction architect that designs the dialog for a certain printer model stay in control of good UI, without being at the mercy of an algorithm or of the developer? Here is how it works:

take the complete list of printing parameters, say for general inkjet;
segment the parameters into logical sections, that make sense to users, as opposed to those that make sense to printer manufacturers;
design the UI for each section, on a canvas with the width of the right column in the dialog;
sequence the sections in a logical order, again a decision on a user interaction level; now you have designed a long column of printing UI;
decide on the tags using usability research and map them to all the printing parameters;
finished.

max headroom

Reviewing the list above I notice how similar the first four steps are to designing a contemporary printing dialog with tabs. I also notice an additional problem with tabs: you have to make a variable number of controls fit in an area of fixed width and height.

The problem is not having to fit a lot into a fixed area, you can always split it in two. The problem is having to fill out a fixed area with almost nothing. I can distinctly remember evaluating dialogs where desperate measures have been taken to make one or two checkboxes ‘fill’ a tab.

Our sections do not have this problem: at least their height adopts to any number of controls. A section with a single checkbox is perfectly OK.

gluing it all together

The following aspects make the steps above work:

the interaction architect has absolute control over the contents: what is displayed and in what order; this includes the type of UI control: if a pop‑up list is the best solution, then a pop‑up list will be displayed; this situation is quite similar to content with HTML mark‑up;
the dialog has absolute control over the presentation, it implements the UI style (KDE, gnome) and the UI theme; this includes all the margins between the items within a section and between sections; this situation is quite similar to a CSS style‐sheet determining the look of a website;
when in the sequencing two sections need to be adjacent, this does not necessarily mean one above the other; they can also be placed side by side in two columns;
not everything will fit the width of the right column, for instance when we get to work on the high volume printers, the booklet making section is going to be ‘interesting’ to design; the left column in the dialogs shown here is 128 pixels wide, the other two 200, so widths of 328, 400 and 528 are also available for exceptional interaction.

the parameter section is build up as follows:

the user‐selected tags determine the parameters that shall be displayed;
these parameters determine the sections that shall be displayed;
within these sections only the parameters that shall be displayed are laid out in specified order;
the sections are distributed—serpentine style—in specified order over the column(s) of the dialog:

wrapping up

‘It was an exercise in detailed design solving general issues,’ as I reported before. My intuition tells me that we can go one step further with simplifying the ‘no tag selected’ dialog, but that will have to wait for printing dialogs, round four.

next‑generation printing dialogs /2

2007-07-08T21:35:00.000+02:00

For the openPrinting Meeting on the linux foundation summit in Mountain View, I prepared a presentation. I updated our mock‑ups of the printing dialog for the occasion.

As discussed last time, the usability team had some constructive critique for the first mock‑ups:

printer selection pop‑up at the bottom? from looking at the task logic it needs to be at the top of the dialog;
there can be confusion over what a quick preset does (change the printer settings, not any dialog parameter display) and what a tag does (change the parameter display in the dialog, not any printer settings); the dialog could do more to avoid this confusion;
there needs to be a stronger relationship between the tags and the the parameters shown; a stronger showing of cause and effect.

starting at the top

I started with the first point, printer selection to the top. I noticed that choosing a printer configures the actual dialog: which quick presets are available, and which tags. Also, the tags purely configure the dialog itself.

Combining this led me to take printer selection and tags out of the content of the dialog and make them part of the frame of the dialog. This addresses in part the second point of critique.

Before I show how that works out in practice, first our:

disclaimer: this is a quick‐and‐dirty lash‑up to show you what we mean; there are for sure some things missing and lots of small issues to solve; enjoy nonetheless…

Keeping that in mind, here is the dialog in default appearance: no tag selected:

Note that I lightened up the quick presets list on the left, but the items are still nice and big for quick access. Also I wanted the tags to form a cloud with a loose structure. This whole top printer + tags section has much more a ‘written sentences’ feel than ‘controls on a grid.’

I have used color and position here to make the top section part of the dialog frame, to show the principle. However, on linux the dialog frame is set by the window manager, which can give it any shape and color. So later a different solution will be needed for KDE or GNOME and I will work with the developers of the Qt and gtk toolkits on this.

Also there is the ‘written sentences’ aspect, which becomes interesting with internationalisation for right‐to‐left languages. But nothing that can’t be solved.

pretty vacant

Here are some tags in action:

More full‐size dialogs: first, second, third, fourth

The big wide open space at the right of the dialog—when zero or one tag are selected—is not very satisfying. The dialog can be more compact in that case. However, keeping the quick preset list nice and big, and the overall dialog make‑up relatively stable, will require some fluidity in the printer + tags section. To be continued…

blink

To address the third point of critique I introduced animation when a tag is switched on or off, to show the connection between parameters and tags. I could have gone for the matching parameter widgets to fly in and out of the tag. Instead, I settled for a color highlight of the labels of said parameters:

coming up

Jan mühlig of Relevantive talked to me about a couple of quick rounds of usability testing. With both of us analysing the test results together and me refining the dialog concept in between every round, that makes a nearly ideal design set‑up.

I am looking forward to that and to report about it in printing dialogs, round three.

economic outlook

2007-06-16T01:02:00.000+02:00

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

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.

linuxTag, printingTag

2007-06-10T19:32:00.000+02:00

Last week the linuxTag expo and conference was held here in berlin. It was also the site for the openPrinting in‑between UI summit. I had set for this occasion the goals of showing mock‑ups of what we thus far had only been talking about and to start getting the linux UI platforms (KDE, gnome) involved.

from thoughts to paper

To prepare, I spent a day sketching the printing dialog, together with Andrea Alessandrini—my associate on this project. We had set ourselves the target of ‘fits on a 640×480 screen.’ Dialogs need a modest size, and this way it can still be used on mini‐sub‑notebooks.

In this dialog we have to show the sections that form the core of our solution:

quick presets: aka printing defaults; with one click, the printer is set up for what one wants to do: print a high‐quality photo, a document, some internet images; these presets ship with the printer for instant success, and users can make their own; quick presets need to be directly clickable, not in a pop‑up menu, else they are not ‘quick’ enough.
preview: a square area (shows portrait + landscape) where one can preview if the print is correctly transformed to paper; shows also staples, punched holes, duplex, watermark; includes controls for flipping through the pages; the preview needs to be big enough to be reliable, but no need to be able to read text on the page either.
tags: these stand for the aspects of printing that can interest users; by selecting one or more tags users configure their own dialog; using the tags should be effortless, users should not even notice that they are configuring their dialog.
printing parameters: these really control the printing in detail; the number of parameters that need to be displayed varies and depends on the tags selected.

Most of the day saw us probing where to put the tags, and how to cope with this seriously varying number of printing parameters:

from paper to screen

The weekend before the linuxTag was spent making mock‑ups of the dialog for general inkjet printers. Yes, they are in windows look + feel, but that happens to be a neutral position in the great KDE vs. gnome stand‑off. Andrea used visio, which comes with a windows l+f template, so we did not need to reinvent the wheel. But first:

disclaimer: this is a quick‐and‐dirty lash‑up to show you what we mean; there are for sure some things missing and lots of small issues to solve; enjoy nonetheless…

Keeping that in mind, here is the dialog in default appearance: no tag selected:

The quick presets are in the left column, with two buttons to add and delete presets. Tags are shown in the centre column, with the preview below them. The preview has a semi‐transparent heads‑up display for page navigation. In the right column are the printing parameters, showing here only the absolutely essential.

many–to–many

The tags shown are just examples to demonstrate that they do not only cover technical aspects of printing, but also user experience aspects. Here is the relationship between three of the tags (left) and their seven parameters:

Note how each tag is connected to a low number of parameters. And how two of the parameters (N‑up, Print quality) each belong to two tags. The parameter section builds up according to the tags selected:

Full size dialogs: 1 tag, 2 tags, 3 tags. Which tags were selected will be persisted on a user + printer + application basis. This means that users optimise the dialog for each application they print from.

When even more tags are selected, The dialog will grow vertically to accommodate the extra printing parameters. The centre and right column have the same width, so parameters can be placed in both.

design decisions

The actual tags, parameters and their mapping come straight ‘from the printer,’ e.g. the driver or the PPD. It is ultimately the interaction designer that works for the printer manufacturer who decides what makes sense for a particular printer model.

Our team will set the standard here by designing tags and mappings for the seven printer clusters that we are working on. Usability surveys and test will be used to fundamentally answer the question ‘what aspects of printing do actually interest users?’

think different

For manufacturers, the tags are an excellent way of differentiating themselves. Not by introducing a tag ‘manufacturer xyz’ and associating some proprietary parameters with it. Instead, by representing unique benefits with a tag:

Say a manufacturer has a line of office printers of which the unique selling point is that these make your meetings 33% shorter (cool). Then introducing the tag ‘Shorter meetings’ and associating the parameters that enable that is the way to go.

expert evaluation

At the linuxTag, the openPrinting interaction architecture and usability team met, together with project organiser Till Kamppeter. The usability and interaction experts present (Celeste Lyn Paul, Jan Mühlig and me) discussed the dialog mock‑ups.

We found the concept in general really promising. It can be a definite improvement over the current printing dialogs of any desktop platform. But:

printer selection pop‑up at the bottom? from looking at the task logic it needs to be at the top of the dialog;
there can be confusion over what a quick preset does (change the printer settings, not any dialog parameter display) and what a tag does (change the parameter display in the dialog, not any printer settings); the dialog could do more to avoid this confusion;
there needs to be a stronger relationship between the tags and the the parameters shown; a stronger showing of cause and effect.

These combined would probably cause this dialog to fail a usability test. The good news is that for us it is straightforward to sit down and solve these points. We are working on it.

automatic for the people

I was anxious to hear what Josef Spillner, our resident guru on auto‐configuring dialogs, had to say about the feasibility of our concept. The fact that parameters can belong to multiple tags makes for tricky grouping of parameters. This is not your fathers’ dialog with tabs:

Full size dialogs: first, second, third

Josef thinks that he and his team can crack this puzzle. We discussed the additional challenges of keeping parameters grouped in a logical way and giving the interaction designer that works for the printer manufacturer the means to override the auto‐configuration in exceptional cases.

all aboard

The first contact with folks from KDE and gnome and their respective UI toolkits, Qt and gtk, was very encouraging. My demo with the mock‑ups created a lot of enthusiasm, and the tag system was perceived uniformly as ‘very cool.’

LinuxTag was the first step on the road to cooperation. In the next weeks more steps will be taken, together with both the gtk community and Trolltech.

teaching interaction

2007-06-06T00:43:00.000+02:00

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…

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

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:

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.

on interaction architecture

GIMP’s new free‑poly tool

going poly…

magic combination

small is beautiful

tit for tat

closing credits

test drive

I’m not a graphic designer

at the interface

however…

what about you?

flip that

party like it’s…

once removed

GIMP redux: intro

bird’s eye view

live and let…

radio interview + openPrinting

last chance saloon

GIMP lecture, berlin

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

161.000.000

10. hardware

leadership or bust

9. product vision

no vision, no product

8. (really) hardware

software + hardware = one

7. features

mature on features

6. joy of use

functionalism is not enough

5. display

ambiguous device

4. paradigm shift

full use of full‑screen

3. telephone?

don’t call it a…

2. holistic

simply holistic

1. jump factor

conceptual innovation

next‑generation printing dialogs /4

voodoo child

gold, silver, bronze

just in time assembly

version 0.4

tags enter the matrix

more solutions

the gray zone

blink revisited

summit sumarum

cross‑platform is bunk

holiday cramp

not the only fruit

back at the ranch…

cross‑platform cramp

weasel out

the making of: GIMP UI brainstorm

trigger happy

get off

happy, clappy

tech crunch

…two weeks later

sifting through

whistling in the dark

vroom

bleep

click

…

next‑generation printing dialogs /3

rinse and repeat

beyond the frame

narrow down

building up

design on a toilet roll

max headroom

gluing it all together

wrapping up