our blogpotsdam conference
24 April 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
printing in siena
10 April 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: design stage, internship, openPrinting, practical, product vision
If you like to ask Peter one burning question and talk about it for ten minutes, then check out his available officehours.
Peter Sikking is an
experienced
interaction architect. He unabashedly puts
shipping great products at the centre of his design practice. He is known for
his work for Google, Nokia, the
Metapolator &
GIMP
open source projects,
and startups.
What is Peter up to? See his /now page.
- info@mmiworks.net
- +49 (0)30 345 06 197
- imprint
