publications

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

1 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:

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:

     

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…

…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 instan­taneous 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:

     

lgm 07, top‑10 GIMP user requests

May 22, 2007, 01:12

After my project overview at the lgm conference, Kamila Giedrojć entered the stage to present with me the top‑10 user requests, and our solutions models for them.

Now let me say first here, that a solutions model shows the way forward, based on analysis of the user interaction aspects. It is not a finished solution. It takes quite a bit of work to solve and design all the details, and we are not in that phase yet.

It is both the direction of the solutions models and ensuring that the details do not undermine the concept behind a solution, that are the greatest contributions of an interaction architect to a project. Now without further ado:

10. better printing support

Starting with the product vision we see that it mentions high-end photo + original art. It is a matter of course that part of this work will end up on paper, for sale or exhibition.

It is important to realise that printing is fully part of the workflow, not an afterthought. Placing the image on the page is a creative step towards the final result.

Compare bog standard printing…

…to creative placement:

Our conclusion is that printing should be integral to GIMP, not an extra plug‑in. Furthermore we conclude that the place­ment of an image on paper is a creative, hands‑on affair.

This is done best by preparing the print in the main window, placing the image there on a virtual piece of paper with a tool similar to the new selection/crop tools. This should be supported by a handful of interrelated number fields for margins, image size and printing resolution.

9. painting with ‘natural brushes’

Returning to the discussion of the product vision, we see that GIMP is an application for working with existing images, not for painting from scratch.

Furthermore, nowhere during the whole expert evaluation did painting with ‘natural brushes’ rise as a secondary requirement for performing an essential task.

Our conclusion is that natural brushes should not be part of core GIMP, nor of the standard distribution. The beauty of the plug‑in system is that when somebody out there still feels the need for painting with ‘natural brushes’ they can write and distribute the plug‑in themselves.

8. improve the text tool

typography, along paths, geometric distortion

During the expert evaluation we observed:

• text being used in both original art + web graphics, both creatively and functional;
• no requirements for page layout functionality;
• at some point users have to make a choice: is this text pixel or vector based;
• requirements for text styling + typographical control, e.g. kerning and baseline shift, to be able to produce the professional results mandated by the product vision;
• the current ‘one text per layer’ doctrine is not practical. Producing ten buttons on a single canvas for a website, ten layers are needed to label them.

Our solution is to allow multiple text blocks within one text layer. Because they can overlap, they will have their own stacking order.

With the introduction of GEGL, users need no longer be concerned with the ‘pixel or vector’ question. And that can only be a good thing. Text will be editable until the end of time. It will be very natural to apply geometric distortion or pixel effects to texts.

7. save for web

Production of web graphics is part of the product vision. The user scenarios reflect this and the scenario for web images speaks of ‘export parts in optimised web format.’

kilobytes

It is important that web images are as small as possible. The ‘customer’ who commissioned the graphics is also picking up the bill for the network traffic they generate.

Combine all of the above with the fact that there are only a handful of web formats compared to more than a hundred in general. We conclude that save for web is a separate workflow where one compares the few web formats to solve the size versus quality question.

before + after

Does the quality of a jpeg compressed image needs to be compared side by side with the original? On the final website there is only the jpeg, and it either looks ‘professional’ or not. It is up to the GIMP user’s internal value system to judge what is good enough in each case.

Our solution is to reuse the main window for the save for web workflow, plenty of room to inspect the image quality. Standard zoom tools can be used to work at a level of detail where one is comfortable. GIMP can help with checking feasibility (gif) and doing the size calculations to recommend the optimal file format and ‘best’ default settings.

6. organise brushes, palettes, gradients in categories

Resources accumulate, and users ask for categories to break down their collections. The problem is that a resource (here a palette) can only be associated with one category:

This means that there is only a single way to find back the palette: via this one category. This is similar to files and folders: there are a lot of unfindable files hiding on your hard disk.

Tagging allows to attach multiple concepts to a resource:

For instance customer name; project name; that it is a warm palette; a retro palette. This means that the palette can be found back via any of these concepts.

For this to be successful, we need to create UI that makes it incredibly easy to tag resources with existing and new tags, whenever users feel like it, in an incremental fashion.

next…

That was to bottom‑5 of the top‑10. Read all about the top‑5 next time…

Labels: GIMP, practical, product vision

—ps

3 comments, link‐ins, forward this posting:

     

lgm 07, GIMP project overview

May 16, 2007, 19:53

A week or so ago, I delivered a presentation at the lgm conference together with Kamila Giedrojć, my associate on the GIMP redesign project. Instead of dumping the keynote slides in a pdf and making you guess what we said, I will recount the presentation here in three episodes.

I started the presentation with a project overview:

in the beginning…

It all started at the lgm 06. Or actually, two weeks before it. We were discussing at the openUsability meeting, when I asked GIMP maintainer Sven Neumann: ‘so, what is GIMP actually?’ Sven replied: ‘good question.’

Sven invited me on the spot to the lgm 06 and to work with the GIMP team to develop a product vision. That took two hours, the first hour consisting of me explaining the team why we actually needed one. During the second hour we created the product vision.

Here is what it looks like on paper:

Nice and short, it contains only the essential. And by being so concise, we are able to use it as a tool.

definitely not

At the same time we also discussed what GIMP is not:

not photoshop

this means that there is no obligation for GIMP to do things the photoshop way; there is not point to work on a project just to provide a free and open version of some commercial software;

also not painter

the focus for GIMP is to work with ‘found’ images;

not the only linux‐pixel‐oriented‐application on earth

in the old days, GIMP had to save the day for everyone who wanted to change some pixels on linux; today, GIMP has been released of that obligation, and its team can focus on high‑end use.

not a web page mock‑up application

I brought up web mock‑ups, but we realised that seriously supporting this would mean introducing a ton of functionality; it is better done in a specialised application.

real‑life balance

For interaction architects there is no such thing as intuitive interaction. However, we can talk about the 3E’s:

The triangle shows the relationship between them; the dot represents the real‐life situation that you cannot have it all. The trade‐off for GIMP is shown here: user efficiency (ease of use) is everything, with a nod towards ease of learning.

This can be derived directly from the product vision, which speaks about high‐end use and production of graphics.

This explains for GIMP users why it took considerable effort to learn to use the software. We cannot increase ease of learning, or we would lose out on ease of use. All we can do is make it a more gradual, incremental learning experience.

out of tune or auto‑tune

I like to compare this to learning to play the violin. For quite a while the results will be not pretty. But if you put in enough hours, the results can be beautiful, for both amateurs and professionals.

For developers this shows that hard choices have to be made in the UI design, in order to nail the right balance for the 3E’s.

getting involved

I would not have gotten more involved with GIMP if the team would not have managed to agree on a product vision. Without it any interaction architecture or usability effort is doomed.

Also the commitment of Sven to really change things for the better in the UI and the planned introduction of GEGL convinced me to get on board. We started with some ad hoc work on the selection/crop tools that will come out in version 2.4.

blastoff

Fast forward to August last year. In berlin openUsabilty, GIMP and m+mi works bundle forces to create the ‘season of usability’ pilot project. The news spread like wildfire around the world, and I selected Kamila to work with me on the GIMP project.

With Kamila working 20+ hours, and us having two–five meetings a week for the project, we really picked up some speed. To start with, my team needed an overview of all GIMP functionality. We need to know what we are talking about and I had set the target that it was going to fit on twelve pages.

Again I aimed to be as brief as possible, in order to create a tool instead of sprawling documentation. Two and a half months later we had it on eleven pages. And we knew GIMP.

plotting success

Meanwhile we held our scenario weekend, on which I reported here in detail. The result looks like this on paper:

Again, concise and essential enough to be used as a tool.

this year

At the start of 2007, we commenced with the expert evaluation. Taking the user scenarios as the guide to essential use, we took an architectural look at the current interaction of GIMP.

By the end of February we were through…

Notice the contrast between the user scenarios—short and essential—and the expert evaluation: deep, structural and architectural.

the road ahead

At the moment of writing we are working on the analysis. And with all the work done up to now the solutions models are coming easy. These show us the way forward for GIMP UI.

next…

At this point in the presentation Kamila entered the stage to present with me the top‑10 user requests that are UI‑related, and our solution models for those. Read all about it next time…

Labels: GIMP, practical, product vision

—ps

5 comments, link‐ins, forward this posting:

     

printing in siena

April 10, 2007, 13:18

last week, part of the openPrinting interaction architecture and usability team met in Siena, Italy. I am leading that effort and had arranged this two‐day meeting for reviewing the work done up to now, and to brainstorm solutions for the design phase, in an inspiring atmosphere.

realising the vision

Right on the first morning, I led the discussion into the direction of ‘what if we do not need a print dialog at all?’ And from there we actually arrived at the concept of ‘just print’, which implements the openPrinting project vision:

‘…how to make printing with free software easier and better, so that it “just works”.’

Till Kamppeter, openPrinting organiser

Remember that printing does not exist as a task for users? ‘Just print’ will get the job done for them. Choose this new command from the File menu (it needs a better title) and the application and printing system will handle the rest. No dialogs are shown.

get fresh

To enable this, applications and the printing system need to clean up their act:

• the application needs to use its full domain knowledge to get the transformation right: the act of getting the data formatted for paper media. This goes beyond just using the defaults, it means analysing the data and taking some smart choices, taking previous user choices into account. This includes selecting the right available printer and the right paper.
• both need to put some effort into the handover: the act where the application hands the formatted pages to the printing system and both negotiate the application’s wishes. We want to see the both of them working together, instead of autistically against each other, as they currently do.
• apart from listening to the application, the printing system can also have a good look at the actual print data from the application. Number of pages; aspect ratio; bitmapped, screened, line art, or text data; color or black & white? Make some smart choices based on it, again beyond the defaults and based on past user choices. This also safeguards against old skool apps that do not implement the first two points.

This all may look terribly complicated, but forty lines of code per application and printer driver can make a world of difference here. All this smartening up is also a precondition for the advanced dialog stuff as discussed below.

parallel port

From my point of view we have now circumvented the paradox of providing ‘one‐click’ operation and making 40–80 printing parameters available through the same UI. We have simply built ourselves an optimised UI in parallel for 95% of users, 95% of the time: ‘just print.’

dealing with 5,000,000 use‐cases

So after feeling very smug about eliminating the print dialog, we spent the rest of our two days redefining it, for that sliver of users—or occasions—where it is called for. It will be still available via the normal Print… menu item.

Again I led the discussion into the direction of ‘can we get rid of the print dialog as we know it?’ Somehow we tripped over hyperbolic browsing. Although it offered no solution, the graphs used to illustrate this principle did give me the following idea:

What if we let users put together their own personal print dialog?

an uncategorisable mess

The problem with print dialogs today is that 40–80 printing parameters are categorised into six or more ‘tabs’, to cut down the shear mass of them for presentation. Putting them all on one panel would be a horrible mess.

This has a couple of side effects, which were bothering me on an architectural level:

lost overview

one has to traverse the tabs to piece together the big picture;

broken relationships

printing parameters that are very much related in the mind of the user for a particular print, end up on different tabs, because the categorisation is general, thus rational;

misplaced children

just like with files and folders, a printing parameter can only be assigned to one category (tab); I was already dreading an undecided outcome of card sorting tests, telling us that 50% of the users will never easily find a parameter, regardless of on which tab we placed it;

wasted time

no matter how brilliantly one categorises the parameters, with six tabs there is a 83% chance that one has to change tab to adjust only one parameter, 56% for changing tabs twice for changing only two parameters and 28% for 3 parameters over 3 tabs. Because all these tab changes are context switches, they are much more costly in time for users than a single click.

So let’s give users a more fine‐grained control over which parameters they can see together in one dialog. For instance by providing twelve instead of six categories, which users switch on or off to build their own dialog. And the printing system remembers these configurations for each application–printer pair.

• no, this will not lead to monster print dialogs with every parameter visible; I am confident that apart from the always‐visible trivial parameters, only one or two extra categories will be made visible for a particular application; it is just that for every user in the world these will be a different combination;
• no, this will not lead to a monster database with thousands of application–printer configurations on the user’s hard disk; I am confident that each user has use for a dozen applications to print on maybe half a dozen printers; it is just that for every user in the world these will be different;
• no, this will not lead to linux geeks being able to put together their own Frankenstein dialog by hacking an xml file; still a lot of interaction architecture is involved with enabling all the combinations to make sense when combined, and that is not going to be left to innocent bystanders.

So I was quite pleased that with this concept we have solved almost all of the problems of tabbed print dialogs. We have given the print dialog the ability to morph to the needs of individual users and thus, be able to handle the five million use‐cases that plague the printing design challenge. But on leaving Siena, I also knew that misplaced children could still occur.

tags, not tabs

The day after returning from Siena, I was at the innovationsforum interaktionsdesign. Bernard Kerr (del.icio.us) was presenting some past work on tag orbitals, when it hit me:

Instead of sorting printing parameters into categories, we could apply tags to each parameter and have users select some tags to build their own dialog.

feeling fuzzy?

Contrary to the rigid nature of belonging that comes with the one–to–many (folder and files, category and printing parameters) relationship, that of the many–to–many (tags and printing parameters) relationship is a bit fuzzy. And that is a good thing, here.

Tags circumvent the misplaced children conundrum. It is very similar to why hierarchical content organisation is going out of fashion on websites, as will folders on hard disks. And beyond that, they literally open up new dimensions for talking about printing parameters. Here are some tags off the top of my head:

• need speed?
• paper saving
• security
• precision
• paper orientation
• hand‐out
• impress yourself

The sky is the limit. We are exploring the possibilities as I write this.

Labels: openPrinting, practical, product vision

—ps

1 comments, link‐ins, forward this posting:

     

is the iPhone really that special?

January 18, 2007, 11:22

Last week Apple introduced the iPhone. A day later, at the CES in Las Vegas—worlds largest consumer electronics show, where Apple is conspicuously absent—everybody is talking about only one topic: the iPhone.

Meanwhile on the iXda mailing list there is a thread of 120+ (!) emails, where a faction argues that there is nothing revolutionary about the iPhone. Just regular evolution in mobile phones, reached through UI ingredients that some of us prototyped a decade ago.

iPhone: bombshell or pure hype, who is right?

‘but… you have seen all this before, no?’

True, nine years ago I was part of a mobile phone manufacturer’s UI team that was dabbling with touch‐screen input for a production prototype.

And being the interaction architect of a sprawling family of mobile phone applications, factory‐installed on about 400 million Nokia phones, some of them dealing with music and email, I have worked on just about the whole spectrum that the iPhone covers.

Yet as I followed Steve’s keynote live, via the usual suspect channels, I had to ask myself why I, like most people, was so exited by the iPhone.

‘so tell us what you really think’

First of all, they had the guts to go ahead with no‐button, all‐touch‐screen interaction hardware. The hi‐res display (in pixels: 78% of the original Macintosh display) and the state of the art touch‐screen are an integrated part of this strategy.

There are risks involved in getting rid of nearly all hardware buttons. But after unceremoniously getting rid of the qwerty keyboard, the dial pad and the click wheel (!), the interaction folks at Apple really make use of all that screen real‐estate and the opportunity to interact hands‐on everywhere.

So for instance while in call, the options for hold and conference handling are big, visible and directly accessible on the screen. That is a big enabler for getting features actually used.

There are a couple of other things that really stand out:

• showing SMS as conversations, like gmail. When is this coming to an email application?
• seeing an overview of your voicemail messages, and random access to them;
• the device knows whether it is held portrait or landscape, and acts accordingly;
• a mobile web browser that does not look handicapped: normal size web pages, zoom in to read the text.

‘any complaints?’

There is a nagging lack of integration. Voice, sms and email messages are all accessed through different departments. In the on‐stage demo, the email address of Phil Schiller had to be fetched from the address book, although he was identified as being currently in‐call with Steve.

The iPhone does not know where it is, geographically. No GPS, or base station triangulation. That is a shame, after all the work to include google maps.

revolution!

At the end, the real shocker is:

• that the iPhone is an exceptional product;
• that everybody and his dog was looking forward for the last two years what would happen if Apple made a mobile phone;
• that against all reasoning of developers, managers, users and other innocent bystanders to ‘not change what the user is used to’, innovation in interaction is delivered in the form of solid new concepts, solving decade old mobile interaction problems;
• that it is exceptional that the top boss demands excellence in interaction, and structures the software development process accordingly, putting the interaction architects in charge;
• that it is exceptional that software appears on the market that oozes strong and clear product vision.

The iXda faction almost got it right, the iPhone should not be an exceptional product. A revolution is needed to stop developers, managers, users and other innocent bystanders from preventing excellence and innovation in user interaction.

Top software managers should start making the product vision the foundation for software development, and work with interaction architects on realising this vision in UI.

Labels: architects, fundamental, product vision

—ps

0 comments, link‐ins, forward this posting:

     

creating user scenarios with the GIMP team

November 12, 2006, 04:09

I spend last weekend in the linux hotel in Essen, Germany, together with six members of the GIMP project team, Kamila Giedrojć and Ellen Reitmayr.

The goal was to create a set of user scenarios, a most vital tool in the further expert evaluation and upcoming redesign of GIMP. In a nutshell, user scenarios describe the essential usage of a piece of software. These are expressed in user goals, avoiding descriptions in terms of functionality or current UI behaviour.

preparation through observation

In the five days before this weekend, Ellen and Kamila had been gathering vital raw material by performing workplace observation. Half a dozen professionals in the field of photography and graphic design were interviewed and observed on the job. These participants had been selected based on the GIMP product vision.

The three of us analysed the results of the workplace observation together. This is an important aspect of a usability–interaction architecture co‐operation: streamlined discussions, and the ability to analyse interaction and usability together.

weekend kick‐off

Saturday morning, Ellen and Kamila kicked off the meeting with their report from the workplace observation. This already contained some eye‐openers for the GIMP team. I encouraged further discussion based on the findings and this lasted to well after lunch.

product vision driven

To develop the user scenarios I started with the product vision, to identify the scenario categories we should cover:

• high‐end photography;
• creating original art, from ‘found images;’
• icon editing;
• create web graphics;
• automate repetitive tasks.

For each category, we then filled in an essential scenario with the results from the workplace observation and the ensuing discussion. We then probed if further essential scenarios could be found for the category. That turned out to be either one or none.

So I was very pleased that by Sunday afternoon, we had eight user scenarios that capture the essential use of GIMP, in a powerful way.

direct results

Along the way some hard choices had to be made by the team about what workflow to support, and what to leave to other applications. Moreover, essential functionality has been identified during the weekend and implementation of some of it started right there and then.

Soon Kamila and I will release the GIMP functionality catalogue, and the user scenarios document. We will then move on to an expert evaluation of the current GIMP, and of GEGL, that is so much a part of the future of GIMP.

…on rails

On the train back to Berlin, Ellen and Kamila were dozing off after all the hard work during the weekend. Sven Neumann and I spent the time implementing my concept for rectangle + oval selections, in extreme programming style.

While Sven was writing and refactoring code, I worked on drawings and algorithms for the next step. I went through three algorithms for the corner handle size in as many hours: the concept was clear, but the algorithm needed refinement, until I nailed it.

This all in the shortest concept–implementation loop possible. As Ellen said: extreme usability.

Labels: GIMP, practical, product vision

—ps

1 comments, link‐ins, forward this posting:

     

interview

November 07, 2006, 23:33

Christoph Evers—masters student of HCI in Lund, Sweden— interviewed me for a class assignment. The result was this essay, and it makes for an interesting read.

clearly

Now that you have read it, I feel that there are two things I should have said a bit clearer in the original interview.

the Zen‐moment

The Zen‐moment is not when you have found just any old solution for a particular problem, it is when you have found the solution. This moment comes as a revelation, everything is suddenly very clear. You simply know the solution you have found has an unbeatable intrinsic elegance, similar to that of e=mc².

product vision

It may seem from the interview that the product vision—that I formulate together with the management and development team of my customer—in some way contains my ideas about what needs to be achieved in the project.

The opposite is true. The vision formulated here is solely my customer’s. I am simply a catalyst in getting it down on paper. The value I create with this method is by:

• getting it formulated at all; for most of my customers it is a revelation to see the essence of what they are trying to achieve;
• using it as the ultimate foundation for any further UI decision in the project, and in this way ensuring I am achieving the ultimate goals of my customer.

Labels: fundamental, product vision

—ps

0 comments, link‐ins, forward this posting:

     

back from the m+c 06

September 14, 2006, 15:50

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

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

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

so, how did it go?

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

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

any revelations?

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

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

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

other sessions

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

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

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

Labels: fundamental, product vision, ucd

—ps

0 comments, link‐ins, forward this posting:

     

working on the GIMP

July 06, 2006, 20:33

After a tentative start, I am getting seriously involved with the GIMP project. Long term, this is a very hot project for an interaction architect to work on. But for now Sven asked me to do some solutions consulting for the upcoming 2.4 release. So we met up on a warm summer’s evening, Mitch also joined. He has been working for a long time on solutions for the issue‐at‐hand.

shortcut shortage

The topic was building up a selection mask in the GIMP from simple shapes (rectangle, ellipse), combining them with not‐so‐simple shapes. There are a couple of categories of control over this process:

drawing constraints

constrain the bounding box of the simple shape to a square; draw from centre.

addition mode

operarator used to add a fresh selection part to the existing selection mask: replace / add / remove / ‘logical and.’

minute adjustment

move or resize the fresh selection part before commiting the result.

The questions from the GIMP team were:

• how to control all of these option categories from the keyboard, when the only two available keys seem to be shift and control;
• also the interaction of the third category (minute adjustment) was only part‐done, they were looking for ways to integrate it into the overall workflow.

deal with a problem: ignore it

The first thing I did was looking for ways to avoid conflict, to stop the three categories competing for the same keyboard keys. I lifted the third category (minute adjustment) out of the whole conflict, using interaction ingredients already present in the GIMP:

• eight resize handles, instead of four on the corner;
• I made the handles double the size (quadruples the area), and solid (instead of a one‐pixel outline) to speed up the interaction;
• a move handle in the centre of the shape.

With these simple rules, the resulting interaction is visible, direct, and on‐the‐spot. No keyboard required. I like that.

Further attempts to separate the other two categories (drawing constraints, addition mode) failed, so it was time for some hard choices.

fundamentals

Luckily, I had worked with the GIMP team before on defining a product vision, so we had a foundation to base decisions on. It all came together:

‘you know, these professionals spend most of their days building up complex selections’

Mitch, GIMP developer

That was what I needed. Because the GIMP product vision is to be a high‐end tool, the observation above puts the priority on controlling the addition mode. So I assigned the combinations of shift and control to that. I also discussed with Sven and Mitch how visual feedback could—and should—still be given, to indicate the current addition mode.

So what about the remaining category, the drawing constraints? Well, we noticed that the current addition mode is only significant up to the moment the mouse button goes down for drawing a fresh selection. From then on it is fixed until the resulting selection has been commited.

So I said: ‘can we detect whether the shift and/or control key go down after the mouse‐down, to apply the drawing constraints?’ Yes, we could. Problem solved, then.

in short…

A fundamental issue that has been a skeleton in the closet for years. To the developers it looks like an unwieldy mess that cannot be solved elegantly.

Two hours of working with an interaction architect, and with some easy to implement measures, the problem has disappeared. Afterwards, everybody looked relieved and bemused: ‘was that all there was to it?’

Labels: GIMP, practical, product vision

—ps

0 comments, link‐ins, forward this posting:

     

uDay IV

June 22, 2006, 19:10

A week ago I was in dornbirn (austria), to teach a workshop in user interaction architecture methods at the usability day IV. This conference had been organised by the research centre for user‐oriented technology of the fh vorarlberg. Guido Kempter and Philipp von Hellberg turned out to be excellent hosts, making the contributers feel right at home.

practicalities first

Dornbirn is a post‐(garment) industrial town, located close to lake constance. For a dutchman it is most impressive that the alps start in full force right on the edge of town. What an inspiring environment to work in. The fh itself is a wholly modern affair, prepared to start new—and close redundant—studies to adapt to the market. This reminded me of the original bauhaus: about every 2 years it reinvented itself completely.

Also the mensa deserves a special mention. It is run by a non‐profit company which buys all their ingredients directly from local organic farmers. Compare that to the mensa and canteens where I have eaten during my career…

the workshop

The purpose of my workshop was to make colleagues in related fields of work (usability people, development, product management) acquainted with the methods I use on a daily basis.

To have something hands‐on to work with, and exercise the methods, I needed an example project. I wanted my workshop to be anchored in the rest of the uDay, so I trawled the programme for a major topic. I came up with two: interactive television and mobile. So I set the topic to interactive television on mobiles…

In the workshop it was my task to provide the participants with the raw project material (intend, domain knowledge, functionality, technology) that normally comes from the product and development teams that I work with. The participants in turn had to take the role of interaction architect. A complete reversal of roles.

Through the cutting edge projects that m+mi works performs for Nokia, I am quite up to speed with mobile UI, but interactive television was new to me.

looking for a vision

I needed to get a feel for the product vision behind interactive television:

• why are companies investing in it?
• who is this for?
• what value should it deliver to these people?

So during my preparations I google for clues. During the uDay I attend the interactive television track and filter the presented material. I talk to the project manager of the interactive television project of telekom austria. Here is what I found:

triple play

every telecom company, internet provider and broadcaster needs to provide the triple of internet access, telephone and television. Because, … , the other ones are moving into their turf anyway.

a lean‐back experience becomes a leaning‐forward experience

seems to be a classic, this one. The workshop participants and I were doubtful about this character change for television (‘drug of a nation’). But it is not up to the interaction architect to question this. It is the product managers job to define and believe in this. We have to extract value for the end‐user. And I find it lacking in this department.

more features, crammed into your television

is what I personally got demonstrated when drilling further for user value.

This does not add up to a product vision. So during the workshop we had to define our own, to be able to get even started. I am actually sure a vision exists, distributed between the back of the minds of all the people working on interactive television at this moment. It is just that nobody has been able to put it in words yet.

It is my role as interaction architect to help to formulate the product vision, and then to implement a process that bases ultimately all decisions on it. Because without a product vision no amount of UI concepting, graphic design, technology or usability testing will get you anywhere. You simply have no goals to aim for.

Labels: fundamental, product vision

—ps

0 comments, link‐ins, forward this posting: