publications

teaching interaction /09

July 28, 2009, 14:40

At the end of May it was again my pleasure to teach interaction design at the FH Vorarlberg, Austria. I will discuss what was new and notable compared to last time, show which new GIMP functionality we worked on and then present the results.

full intent

Kicking off with ‘what’s different?’, I had fine‐tuned the goals of my course:

structure, structure, structure: If there is one thing I want my students to take away from this course it is a project structure that enables them to tackle any (interaction) design project. I took the structure and methods used in my daily practice and condensed them to a project survival guide. In a fine example of ‘the medium is the message,’ these structure and methods also form the programme of the course.
true interaction: Furthermore I want to introduce the students to what pure interaction design is and what it takes to do it professionally. I chose our design project such that no one could simply fudge their way through using visual design or information architecture skills. How the interaction flows in time is our focus.

The title, interaction design for the real world, reflected that once again the course was all about working on a real design project on real software. New this year was the increased ‘real world’ focus, where for many aspects I related to the students how these are ‘business as usual’ for interaction architects: to deal with certainty with the uncertainties of any given project.

time + space

The time set‑up was different this year, with three full days of working together at the FH and the students sending me their final work two weeks after that. Also different this year was that my course was fully booked, with sixteen students participating.

I divided the students into four design teams and used our three days together for intense and full‑time design work (hey, just like the real world…), using the structure: day 1: from 0–to–100 on the project, ending in an expert evaluation; day 2: brainstorming to create as many solution options as possible; day 3: narrow down to a single design concept.

Each team had to then deliver a design concept document two weeks later. Looking at what could be achieved in three days, I set the scope of this document to be a project‐internal briefing, for the principal interaction architect.

GIMP + vector

On to our design project. I want that the work produced during this course ends up contributing to the real word. So I chose GIMP as our ‘client’ to design for, because I can ensure there that interaction design is advanced towards implementation.

During LGM the GIMP team discussed readying last year’s SoC vector layers code for inclusion in GIMP v2.8. That was exactly the type and size of interaction design project I was looking for. I will now introduce the material my students started out with.

The proof‐of‐concept code allowed to take a path:

and convert it to a vector layer, receiving an outline stroke and/or a fill:

the shape of the vector can be changed for ever like any path, and when not edited display like this:

the fill and stroke parameters could be found and changed in one dialog:

and that was it.

spoiled for choice

The exact set of functionality (aka features) has a major impact on the interaction design and interaction architects have to rightsize this set before even starting to think about interaction. Usually this means fighting too many features, since anybody—developers; users; marketing folks; managers—can come up with more features.

In our design project, there was plainly not enough functionality to be useful/usable. So before the interaction designing started, each team sat down to brainstorm and then decide on their essential set of functionality. What struck me at the start of this phase was to hear talk of ‘window’, ‘click’, ‘button’, ‘slider’, et cetera.

That had to stop immediately. It took a couple of rounds of explanation—‘it is just a boring list of what functions it has’—to get the cold, analytical side out of my students. But then they were on top of the functionality, as it should be. As we will see next, functionality like vector layer management, managing and combining shapes and working with simple shapes (rectangle, ellipse, etc.) was integrated.

four team results

Now the grand finale, the results of the four teams. First let me make clear that the work of all four teams is available under GNU Free Documentation License 1.2. I present them in team order.

team one

members: Andrea Chavez, Christoph Bischof, Julian Tomaselli + Tamara Christina Blumer
design concept document (pdf, 2.7 MB, limited pdf viewer compatibility)

Team one was the one with the hottest debates. That may sound a bit inharmonious, but it was good to see the whole team so worked up about making good interaction.

The main theme every team fundamentally had to deal with was the integration of the new vector functionality with the existing interaction, like that for paths and geometry transformation. This team solved it by introducing a shape tool in the toolbox and using the path tool for advanced vector manipulation.

Team one was the fist of several teams to arrive at the solution to use a library dialog for selection and management of a large set of user‐defined vector shapes. This works analogue to how brushes are selected and managed.

Apart from a doing a good job overall of keeping all the aspects of the interaction together, I especially liked their use of the modern GIMP sizing handles for the simple shapes.

team two

members: Sara Geller, Laura Ramirez, Jakob Tripolt + Florian Wenger
design concept document (pdf, 9 MB)

Team two shows us that all it takes to deliver a detailed design concept is pencil and paper. Funny enough this team, that did the most note‐taking, also resisted for the longest time to use the pinboards that I strongly recommended for gathering the results of the brainstorm phase. At the end, they did.

Team two integrated shapes and vectors into the path tool, giving the path tool different modes.

Overall they went deepest into a lot of interaction issues and solutions. I really liked their serious workflow analysis.

team three

members: Mona Seiffert, Giselle Anahi Salinas, Markus Angerlehner + Anna Weiss
design concept document (pdf, 732 KB)

Team three shows that it does not take a long document to get the core concept across. To my surprise this team dived into making pixel‐perfect mock‑ups of their ideas quite early in our design process. That was another thing that had to stop immediately.

In our high‐pressure environment where the teams had just enough time to arrive to a solid concept, the focus has to be on staying agile and creative. While all the time the scope of the design gets wider and the big picture becomes clearer, any part‐solution needs to be hot‐swappable for a better one until the very end. You can do that when solutions are pencil sketched, not so easy when they are visually designed with considerable effort.

‘Keep it brief’ is what I asked for the design concept document. But vector layers turned out to be a design project that was more multifaceted than the humble introduction would let one believe. So apart from the core concept, a lot of peripheral interaction issues needed addressing, as the other teams did.

team four

members: Daniel Corn, Katherina Donner, Marko Heijnen + Lena Seeberger
design concept document (pdf, 528 KB)

Team four introduced not one, but two new tools in their design concept. And for good reasons, like addressing smooth workflow, or an appreciation of the elegance of the free‑poly selection tool. So they introduced a freehand tool besides a shape tool, the former converts freely drawn shapes to stroked/filled vector shapes.

Also this team did a a good job overall of keeping all the aspects of the interaction together and I am quite taken in by their clean and effective little storyboards.

after the project is before the project

From the moment I selected vector layers as our design project down to the moment I am writing this, I have kept out of actively designing this feature, by simply not starting to. This in order to stay as objective as possible, while working with the students; while grading their work; even while describing it here.

But now it is time for me to get started. I will take the concepts of all four teams as the starting point for my interaction design of vector layers for GIMP. I’ll keep you up to date on that here.

Finally, I would like to thank the students for their hard work during the three intense days that we spent together. It was great to feel the vibe and I had a great time.

Labels: architects, fundamental, GIMP, practical

—ps

3 comments, link‐ins, forward this posting:

GIMP’s new free‑poly tool

June 21, 2008, 13:42

Recently there was a heartwarming post on the graphics planet:

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

David Gowers, featured on meetthegimp.org

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

going poly…

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

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

magic combination

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

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

small is beautiful

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

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

tit for tat

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

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

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

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

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

closing credits

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

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

test drive

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

Labels: architects, GIMP, practical

—ps

3 comments, link‐ins, forward this posting:

I’m not a graphic designer

March 26, 2008, 13:35

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

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

at the interface

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

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

however…

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

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

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

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

what about you?

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

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

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

the ps acid test

You don’t agree?

flip that

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

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

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

party like it’s…

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

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

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

once removed

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

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

Labels: architects, fundamental, product vision

—ps

3 comments, link‐ins, forward this posting:

radio interview + openPrinting

January 18, 2008, 11:06

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

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

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

last chance saloon

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

Labels: architects, fundamental, openPrinting

—ps

0 comments, link‐ins, forward this posting:

GIMP lecture, berlin

December 09, 2007, 14:54

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

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

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

Labels: architects, GIMP

—ps

0 comments, link‐ins, forward this posting:

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

November 14, 2007, 18:29

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

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

ps’s lecture at the berliner wud 07

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

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

161.000.000

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

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

10. hardware

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

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

leadership or bust

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

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

9. product vision

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

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

no vision, no product

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

8. (really) hardware

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

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

software + hardware = one

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

7. features

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

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

mature on features

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

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

6. joy of use

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

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

functionalism is not enough

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

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

5. display

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

an overlay of the iPhone and mac screens

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

ambiguous device

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

4. paradigm shift

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

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

full use of full‑screen

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

3. telephone?

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

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

don’t call it a…

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

2. holistic

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

simply holistic

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

1. jump factor

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

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

conceptual innovation

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

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

Labels: architects, fundamental, product vision

—ps

1 comments, link‐ins, forward this posting:

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:

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:

team spirit

August 03, 2006, 10:45

Picture this:

An interaction architect is hired to lead a user centred design team on a very important project. First day on the job she discovers that some of the team are fine at UCD techniques (interviews, paper prototype testing, usability testing), but are completely missing the vital element in the middle—interaction design.

…or else…

She needs to take her team out of their comfort zone. If they don’t do the design, the business teams will do it, and we all know who we prefer to be designing interfaces…

So she posed the question if training techniques like peer critiquing could be used to get the team up to speed on interaction design.

thousand year old advice

Here is what I replied:

‘I propose that you steal from the thousand year old practice of architecture.

‘You are the principal architect. You were already contracted for that role, so no problem there. All major decisions have to be taken by you. You keep the model(s) pure and in one piece under the avalanche of input, feedback and usability test results.

‘You can multiply yourself by making whole UCD team associate architects. Either solo or in pairs you let them work on a certain sub‐system. They’ll have to do most of the legwork. In one or two meetings a week you work together with each person or pair. Here all decisions are taken and the design actually advances.

‘I don’t think you need a coordination meeting with all the associates. You coordinate in your work meetings, and if the UCD team sits together then they can cross‐pollinate there.

‘By working in this way they can learn a hell of a lot from you, and maybe one of them has got what it takes to be an interaction architect, and will float to the surface.’

Labels: architects, fundamental, ucd

—ps

0 comments, link‐ins, forward this posting:

users, vision + architects /2

July 29, 2006, 00:33

Let’s move on with the next two sections in the article by Don Norman, starting at ‘human‐centred versus activity‐centred…’

‘Successful devices are those that fit gracefully into the requirements of the underlying activity, supporting them in a manner understandable by people.’

Don Norman

‘Does this UI optimally support the activity’ is one of my key criteria when I perform an expert evaluation, or when selecting from different interaction design variants for my clients.

Supporting the activity is the difference between UI that ostensibly makes the functionality available to the user and UI that makes the activity a piece of cake, and the software a true joy to use.

‘only software that supports the activity adds user value, and is worth using’

Hitting the sweet spot where the UI optimally supports the activity is a great development team motivator. On every project I work on, the eyes of all involved start glowing when we have that Zen experience: we got it. You can see the developers calculating how with a little bit of effort they can put together this really cool piece of software.

‘only software that supports the activity adds company value, and is worth developing’

users will adapt

Actually, users suffer in silence, when using software. This leads to the ‘we did not get any complaints’ phenomenon. There is a backlash from this when it is time to innovate.

Remembering the last time they had to learn how to ‘work around’ the current UI, which does not support their activities, users fight change hand and tooth. Many parts of the software industry are stuck in the dark ages because of this.

The only way to break this loop is to hit the sweet spot. Show people UI that optimally supports their activity and they’ll want it, right now. They will have their Zen moment: this is the best thing since sliced bread.

highly efficient machines

It is the interaction architect who takes the responsibility to lead the development team to the sweet spot. To focus on the activity, take a collection of features, functions and technology and to shape them into a nifty, highly efficient machine that supports the activity.

next…

…stay tuned for the third article, dealing with user testing and ease of use.

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

—ps

0 comments, link‐ins, forward this posting:

users, vision + architects /1

July 18, 2006, 17:52

So let’s get started with the article by Don Norman at the top‐left corner, and work our way through the introduction, up to the musical instruments.

the paradox

Norman starts off by observing a paradox:

there is quite a bit of software in this world that, while produced according to human‐centred principles, is complex and confusing;
there are lots of tools and objects (not software), that have been made without any human‐centred design methods, but that are used successfully across the globe.

Norman goes on to explain that the latter may be the result from a deep understanding of the activity performed. He then defines activity as the big picture of what people do.

In the final part of this introduction, Don shows—with examples—that it is quite normal for people to adapt to rather artificial systems, simply in order to get things done.

living with the paradox

The 99.9% of functional analysts, GUI developers and multi‐media/web designers out there, who work on projects that involve no human‐centred design at all, may feel vindicated by all this. And by the way, all those projects that ‘ask users how they prefer their GUI’ are part of the 99.9% (an upcoming instalment will cover why).

We all have read the reports about how some of the top‑5 software companies in the world (in revenue) have impressive usability departments, and are adviced by the biggest names in my industry. But I have to say: where did all the effort go? Look at the market‐place indicators:

a cottage industry of training companies for this software (official slogan of one: ‘we are the aspirin for the headache of having to use xyz’);
project implementers for this software relaying to me their customer’s response: ‘oh please, not xyz’;
the wide‐spread reputation among users of this software.

stop smiling

It is my experience that those 99.9% of software/multi‐media/web projects are not achieving the second part of the paradox. Because the ‘deep understanding of the activity’ is missing.

As long as the project team keeps working at the level of features and functionality, it will not understand the activity. It is staying within the relative safety of supplying an addictive commodity (new features) and practising UI as a technical discipline.

Only when when the team can leave this level behind, and use methods to acquire this deep understanding, to get the big picture, then I say: ‘welcome to interaction architecture.’

next…

…stay tuned for the second article, dealing with highly efficient machines.

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

—ps

0 comments, link‐ins, forward this posting:

users, vision + architects /intro

July 14, 2006, 19:29

Two weeks ago a link was posted on the iXda mailing list to an article by Don Norman on what he calls activity‐centred design. I finally got around to reading it, and check out what that entails.

What Norman describes in the article greatly matches what I have experienced and learned myself in the past 13 years in this industry. This has resulted in the methods that I have developed and put into practice at m+mi works.

the series

By the time I finished reading the article the idea had been born to publish a series of blog articles, where I comment, expand upon and put into perspective the different themes in Don’s article.

So stay tuned for the first article, dealing with the paradox.

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

—ps

0 comments, link‐ins, forward this posting: