publications

to Istanbul via Tokyo

July 18, 2008, 14:09

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

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

the 8 rules of printing interaction

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

1st rule of printing: printing does not exist

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

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

2nd rule of printing: printing does not exist

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

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

3 levels of printing

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

level 1

Printing that just works. Users know for 90% of the printing they do that ‘it will be OK’ when done like last time. As the first—and probably most important—innovation in this project, we complement today’s Print… command with ‘Just Print’, which shows no dialog and prints using defaults and last used settings.

level 2

A basics level of involvement: what printer; maybe set a quick preset; check the preview; done:

level 3

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

4th. wysiwyg is overrated

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

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

5 million use cases

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

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

• personal laser
• workgroup laser
• high volume printers
• general inkjet
• photo printers
• wide format
• impact printers

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

6th. unknown: good printing dialog

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

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

7th. tabs considered harmful

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

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

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

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

8th. tags not tabs

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

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

printing rules, OK?

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

Labels: fundamental, openPrinting, practical

—ps

0 comments, link‐ins, forward this posting:

     

I’m not a graphic designer

March 26, 2008, 13:35

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

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

at the interface

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

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

however…

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

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

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

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

what about you?

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

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

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

the ps acid test

You don’t agree?

flip that

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

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

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

party like it’s…

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

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

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

once removed

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

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

Labels: architects, fundamental, product vision

—ps

0 comments, link‐ins, forward this posting:

     

radio interview + openPrinting

January 18, 2008, 11:06

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

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

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

last chance saloon

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

Labels: architects, fundamental, openPrinting

—ps

0 comments, link‐ins, forward this posting:

     

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

November 14, 2007, 18:29

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

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

ps’s lecture at the berliner wud 07

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

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

161.000.000

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

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

10. hardware

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

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

leadership or bust

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

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

9. product vision

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

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

no vision, no product

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

8. (really) hardware

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

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

software + hardware = one

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

7. features

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

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

mature on features

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

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

6. joy of use

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

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

functionalism is not enough

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

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

5. display

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

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

ambiguous device

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

4. paradigm shift

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

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

full use of full‑screen

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

3. telephone?

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

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

don’t call it a…

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

2. holistic

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

simply holistic

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

1. jump factor

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

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

conceptual innovation

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

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

Labels: architects, fundamental, product vision

—ps

1 comments, link‐ins, forward this posting:

     

cross‑platform is bunk

October 11, 2007, 17:49

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

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

holiday cramp

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

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

not the only fruit

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

preferred native solution

It is my company and I am Dutch, so I tend to see the holidays in Holland as natural. So we take those: my co‑workers and customers in Germany and Spain suffer.

grand compromise

also known as roll your own, if there are holidays on the eighth, eleventh and seventeenth, then we will have one on the twelfth: mass confusion among co‑workers and customers.

lowest common denominator

Only the holidays all three countries have in common are company holidays: too sparse a set of holidays, will really upset my co‑workers everywhere.

union of all

If it is a holiday somewhere, it is a company holiday in all three countries: now we got holiday bloat, co‑workers can’t get any work done, customers think we are always chatting in the café.

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

back at the ranch…

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

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

cross‑platform cramp

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

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

weasel out

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

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

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

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

Labels: fundamental, practical

—ps

0 comments, link‐ins, forward this posting:

     

economic outlook

June 16, 2007, 01:02

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

Some of my favourite snippets:

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

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

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

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

economic brain scan

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

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

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

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

business 101

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

‘by engineers for engineers’

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

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

‘an end in itself’

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

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

‘ignore what the market says’

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

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

‘concentrate on ease‐of‐use’

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

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

‘an order of magnitude more work’

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

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

Labels: fundamental, practical

—ps

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

     

potsdam conference

April 24, 2007, 00:31

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

presentation style

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

classic powerpoint…

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

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

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

…contra minimalism

Three huge white words on a black background.

A single photographed artefact against a solid white background.

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

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

arts and crafts movement

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

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

intuitively, my dear Watson

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

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

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

second time lucky

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

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

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

close encounters of…

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

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

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

Labels: fundamental

—ps

0 comments, link‐ins, forward this posting:

     

printing, design, students

February 07, 2007, 15:38

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

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

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

printing is not sexy

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

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

windows

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

mac os‐x

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

gnome

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

kde

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

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

method overload

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

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

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

the design gap

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

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

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

Labels: fundamental, openPrinting, ucd

—ps

0 comments, link‐ins, forward this posting:

     

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:

     

users, vision + architects /4

November 29, 2006, 23:32

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

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

Don Norman

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

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

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

meanwhile, upstream…

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

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

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

don’t call me a…

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

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

next…

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

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

—ps

0 comments, link‐ins, forward this posting:

     

the wud and the chainsaw

November 23, 2006, 14:09

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

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

unified lecture

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

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

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

the central section

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

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

gentlemen, start your engines

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

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

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

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

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

wrapping up

Jan wrapped up the session by observing:

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

Labels: architects, fundamental, ucd

—ps

0 comments, link‐ins, forward this posting:

     

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:

     

users, vision + architects /3

September 28, 2006, 00:23

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

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

Don Norman

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

emphasising learning

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

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

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

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

discrete and limited

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

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

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

sprawling software

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

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

instead…

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

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

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

next…

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

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

—ps

0 comments, link‐ins, forward this posting:

     

selecting an associate for the GIMP

September 22, 2006, 12:26

I have just finished the selection procedure for the openUsability sponsored student project: GIMP. This is a project where I work with an associate interaction architect on revamping the GIMP. This project is also the pilot for the season of usability initiative.

From the jump in the server statistics for mmiworks.net I can see that the news of the student project spread around the net infectiously on August 11th. This caused a first wavelet of applications. We closed the application period a month later, the announcement of which triggered a second wavelet.

• fourteen people applied for the position;
• quite an international showing, with applications coming from Europe, USA, Russia and India;
• a significantly high number of applicants (5) were born in the countries formerly of the Warsaw pact, although only one was still living and studying in that part of the world;
• I selected three applicants for phone interviews, and all turned out to be from the Warsaw pact faction, maybe it is just something in the water…

criteria

So how does one identify an up‐and‐coming interaction architect? In the requirements section of the advertisement you can already see what I was looking for, but I will elaborate on those words here.

‘Interaction architects need to see from the user point of view, know what makes user interfaces tick, have a mathematical eye for the beauty of the simplest solution, a sense for clean layouts and know what can be developed in practice’

ps, in the original advertisement

multi‐disciplined

There are five disciplines in the quote above and I was really looking for evidence of all of them in the CVs I reviewed. And I was looking for balance. A straightforward university education in usability, graphic/product/interaction design, software engineering, mathematics or psychology can give you a background in at most 1½ of these disciplines.

This skews a CV and needs compensation by evidence that the applicant went out before or in parallel to the current studies to obtain a background in the other disciplines. No need for a handful of university diplomas, just any kind of experience that can give me a vibe of the particular discipline will do.

determination

Another vibe I look for in a CV is an absolute determination to make it in interaction architecture. This is still absolutely necessary in the software and web industry of today.

When graduates do not stick to their guns, the industry they enter will fob them off on jobs like UI or web developer, web graphic designer, functional analyst, requirements specifier, product marketing person or the token usability tester. All of these jobs leave zero opportunity to take charge and introduce solid concepts for interaction.

So absolute determination is needed for aspiring interaction architects in order break the vicious circle of no awareness in the industry of how strategic interaction is to their bottom line, and few jobs for interaction architects.

to be, or not to be…

A final point I want to touch upon here is the topic of owning ‘it.’ I reviewed several CVs of applicants who are totally fascinated by interaction, and are really determined to make it their profession. But they are still looking at it from the outside, looking forward to enter the field.

To get the job of associate interaction architect one’s to be one, no matter how little experience one’s got. It is a state of mind.

the result

After the phone interviews it was clear to me that Kamila Giedrojć is the applicant who meets the requirements above most successfully. I look forward to kicking off the project with her.

Labels: architects, fundamental, GIMP

—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.<