on interaction architecture

publications

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

—ps

2 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: , ,

—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: , ,

—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: ,

—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 2⁄3. 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.

a mesmerising cloud of features

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.

a most simple circle

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, 1⁄3 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:

the iPhone escapes all mobiles

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 1⁄3 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: , ,

—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: , ,

—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: , , ,

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

green jungle

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

chainsaw

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:

6 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: , ,

—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: , , ,

—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: , ,

—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: , ,

—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’
ps

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’
ps

users will adapt

Actually, users suffer in silence, when using software. This leads to the ‘we did not get any complaints’ phenom­enon. 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: , , ,

—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: , , ,

—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: , , ,

—ps

0 comments, link‐ins, forward this posting: