CHI 2008ย โ€“ย April 5-10, 2008, Florence, Italy

CHI 2008 logoEarlier this month, I had the chance to go to Florence to attend the 2008 CHI conference. I had been looking forward to CHI for several reasons: After being disappointed by HCII last year, I was hoping for a more practitioner-oriented conference; I knew that a lot of people I knew would be going; I had been involved in the review process; and I wanted to (finally) go to Italy. Speaking of Italy: I've still got that "Florence, Idddallly" sound in my ears, and it'll take a while to wear off.

Saturday, April 5

My colleague Jonah and I chose to take the night train from Zürich to Florence instead of flying – a 9 hours journey on an Italian train that felt like the 70s on rails ๐Ÿ™‚ Definitely an interesting experience, setting the scene for the conference. Think I had expected something more like the German railway sleeper trains. D'oh.

Sunday, April 6

Attended the full-day workshop #17: "Now let's do it in practice: User experience evaluation methods in product development". It had not been easy to get into this workshop, even though I had acted as a reviewer for four of its papers. The workshop turned out to be good and valuable, but I was amazed (again) at the disconnect between what academia did and what "the industry" needed. This surfaced most obviously in the breakout sessions in the afternoon, when mixed groups discussed their approaches and assumptions. Defining even what "user experience" means turned out to be a major challenge. Sneaked into course 1: "Mobile interaction design patterns" (which was good), but had to leave early b/c of hunger. I was starving by then. Speaking of which: food was extremely hard to come by, and most food I had in Florence was a total disappointment (with one notable exception). I have been told that the food quality increased dramatically once the conference was over. Met with the Hamburg UPA chapter for dinner.

 

Monday, April 7

Attended the opening plenary but was severely unimpressed by the speaker, Irene McAra-McWilliam. Took course 4: "Mobile interaction design practice", which was delightful. Great instructors, great real-life insights, very nicely done. Hung around the Google booth during the late afternoon / evening.

Tuesday, April 8

Attended the panel "Media spaces: Past visions, current realities, future promise", which was good (panelists: Ron Baecker, Steve Harrison, Bill Buxton, Steven Poltrock, Elizabeth Churchill). A nice introduction into the history of CSCW and video conferencing. I also attended the panel "What would you do with a 1 million dollar UX marketing budget", even though the title was slightly misleading (panelists: Luke Kowalski, Carola Thompson, Tom Chi, Darren McCormick, Omar Vasnaik, Peter Heller). Got so angry at Ms Thompson saying that UX was a relatively new field within SAP that I had to leave. She said that UX had only been around for three years – remember: I left SAP three years ago after four years of UX work, and there were UX colleagues who had spent 10 and 15 years there. What a disservice. Spent the afternoon and the evening calming down at the booth, helping during the job fair etc.

Wednesday, April 9

Attended the hospitality events (Google's and Microsoft's) in the evening. Guess which one was better! ๐Ÿ™‚

Thursday, April 10

Took course 20: "Key issues in planning and making sense of international field research" by Susan Dray. This was the second course I attended with Mrs Dray (first one was at HCII 2007), but I was rather unimpressed this time. She didn't manage to create a rapport with the audience, and her having an somewhat unpleasant and embarrassing fight with her husband in front of the class didn't help. Also attended course 24: "Designing location-based experiences", which was interesting – the instructors had set up some information points on the conference grounds, and participants could explore those with a GPS-enabled iPaq PDA. Unfortunately it felt as if it was a scripted audio guide rather than an interactive experience. In the late afternoon, I attended the closing plenary "From the materialistic to the experiential – A changing perspective on design", delivered by Bill Buxton, which for me certainly was the highlight of the conference. In a delighting and inspiring talk, Mr Buxton reflected on the design profession and where it was headed. Later took the night train back to Zürich (10 hours :-)).

Overall impression

This was my third CHI (after 2002 in Minneapolis and 2004 in Vienna). I think CHI has been moving in the right direction, taking practitioners' needs more into consideration. Still, I found the disconnect between academia and practice a bit disconcerting. It was an interesting but somewhat time-consuming additional honor to act as a reviewer for CHI papers (for the #17 workshop and one or two additional papers). I was glad to see that my critique of most of the papers was reflected by the other reviewers' impressions.

I chose to mainly attend the panels because papers can always be re-read in a different setting, while panels tend to create dynamics of their own. Most courses I took were well worthwhile, too. In addition, CHI is always a great opportunity to create and refresh professional relationships (citing Jonah: "Stop knowing everyone!" :-)).

Of course I made some pictures of Florence during my stay there.

How overly “intelligent” software can embarrass you

Yesterday I got an email telling me that I was invited to an acquaintance's birthday party, together with some 30-odd people, most of which I didn't know. The email contained an .ics invitation as an attachment, one of these little files created by, for example, MS Outlook or Apple iCal. The .ics file carries information on a calendar entry in it, like time, location, sender, attendees etc.

I wanted to add the event to my Apple iCal calender, so I clicked on its underlined name. The event got added alright, but to the wrong calendar – one of my deprecated work calendars. So I deleted the entry from the calendar and tried something different: This time I dragged the .ics file from the Apple Mail email body right onto my private calendar in iCal. The event appeared in the right color, indicating that it had been added to the correct calendar, but … I noticed some interesting activity in my Apple Mail client! iCal had started to send out updated invitations to all the original party invitees – in my name! I quickly deleted the event from my calendar, only to be asked if I wanted to send out some explanation to the invitees. Confirmed that (I was a bit nervous by that time) and had to close ~30 draft emails; nevertheless, my email client kept sending out message after message until I finally disconnected the WiFi network to make it stop. By that time, at least 16 invitations and updated invitations had been sent out.

The shame of it! I had spammed a number of people, most of which I didn't even know, with updates to a party I had only indirectly been invited to, and that happened to me, who I consider to be sufficiently tech-savvy, with one my favorite tools, Apple Mail, on my favorite OS, Mac OS X 10.5. I sent out an apologizing email to the party organizer and later today another one to all the invitees. My apps' misbehavior had caused shame for me and irritation in my social network, and in the end the blame would land squarely on me.

Someone at Apple obviously had tried to make something super-simple but somehow got it wrong. Why am I made the owner of an event when I drag it to my calendar, and how can my email app start sending out messages without asking me first? This reminds me too strongly of Plaxo, a contact management tool that makes it super-easy to stay up-to-date with your contacts' address data, because it syncs all the changes in the background, but that can also result in your sending out messages to all the entries in your address book. The infamous AOL client had a similar functionality that I invoked at least once accidentally while working at AOL.

Brings to mind Asimov's Three Laws of Robotics (1942), and right at number one, they read:

A robot may not injure a human being or, through inaction, allow a human being to come to harm.

Please, keep this in mind when designing applications – protect people from overly clever actions of applications, and think about possible negative consequences of your apps' behavior.

Attending CHI 2008 in Florence!

This year's CHI (Computer-Human Interaction) conference will take place from 5 to 10 April 08 in Florence, Italy. They are expecting ~2000 attendees from 38 countries. I've always enjoyed going to CHI conferences – they offer a unique blend of current research and topics that are more geared towards practitioners. You can still get the early bird rate if you sign up before Feb 10! For me, there was one big disappointment with this year's CHI, even before the conference started: I was asked to be on the program committee for a workshop: "Now Let's Do it in Practice: User Experience Evaluation Methods in Product Development". I reviewed four papers in my spare time. Now it turns out that the CHI organizers assigned so small a room to the workshop that a maximum of two authors per paper can attend – and the reviewers cannot take part in the workshop. Quite frustrating. ๐Ÿ™

World Usability Day 2007: Making It Easy!

World Usability Day 2007 logo
November 8 saw this year's worldwide No. 1 usability event – the World Usability Day, conceived by the international Usability Professionals Association (UPA) and carried out in 23 countries by local UPA chapters or other interested parties. I took part in the event in Hamburg, Germany, which attracted over 300 people from industry, administration, and academia. My invited talk on Google User Experience was the final element of this great and well organized event and was very well-received by the approximately 150 people in the audience. Exciting!

Business Week: Design vs. Design Thinking, and what’s “Design Thinking” anyway?

In his article, "Design Vs. Design Thinking", Business Week's Bruce Nussbaum offers some great insight into the current struggle between business schools, design schools, designers and business people around who actually defines "design thinking" and what "design thinking" actually is supposed to mean:

My own current thinking is that designers must play a critical role in the creation of this new field of design thinking. The whole core culture of design is essential to design thinking. In fact, I would argue that the rise of Web 2.0 and social networking reinforces the traditional design focus on empathy and integration – human factors, the user interface, culture. Web 2.0 technology is behind the boost to design in the corner office as businesses delve more deeply into the lives of their customers–who are demanding to be part of the process of creating and designing stuff. Social media reinforce their desire to participate.

But design thinking is such a new field that it's not clear whether design schools or business schools will develop the formal concepts and methodologies that turn it into a broad, deep and powerful tool of organizational change.

The fact is that design thinking (or whatever we wind up calling this new field) is being created at the borders of design, business, engineering and even marketing. And I don't know which institutions will take the lead in promoting it.

Read the full posting on Business Week

Hunting for the optimal prototyping tool

This is a summary of my experiences with different tools for and approaches to prototyping. Prototyping is, eventually, a central area of work for interaction designers, information architects and people with other roles in the software development process.

Why prototyping?

Why bother? The aim of prototyping is to simulate the behavior of digital artifacts before any real development effort has had to be invested. This is driven from the insight that changes get more expensive the later in the development process they are realized – and anyone who has worked in software development knows that changes are inevitable. Change requests surface whenever you walk your project team through a design (no matter on which level of development you are right then). Requirements for an optimal prototype can be derived from this insight: Prototypes musts be

  • fast to create (with little effort)
  • easy to change
  • close to what will actually be built later
  • good to communicate (i.e. in a file format that can at least be viewed by the project team members, better even annotated)

With interactive products à la Web2.0 a new approach to prototyping becomes necessary – thinking in static pages doesn't help anymore as pages or elements thereof can look totally different based on system state (e.g., user unknown / known, but not authenticated / authenticated) or on user action (user has finished an action successfully / an error has occurred). It makes sense to introduce modular design into the prototype already – it'll be the basis for the technological realization anyway. This way, the interaction designers have vast degrees of freedom to have modules react onto events in other modules or to have them ignore other events. Based on this, another requirements becomes clear: the tool must support a modular approach to prototyping.

Prototyping techniques

Based on the goal you want to achieve, you can differentiate horizontal and vertical prototypes (assuming you've got limited time). Horizontal prototypes illustrate a website or an application in its whole width, but offer little or no functionality once you start drilling down. Vertical prototypes in most cases show only very rough illustrations of wide areas of a site or an application, but in limited areas, they provide a very deep and detailed view into the site's or app's depths.

If you're about to create a prototype for a usability test of a specific function, in most cases you'll want to build a vertical prototype illustrating this function in depth – and all the surrounding areas only very sketchy. If you'd like to explore the navigational behavior across a whole site, you'd rather build a horizontal prototype with very limited deep functionality.

You can create electronic or paper prototypes. Paper prototypes have got a number of advantages – they're fast to create, can be changed right in interview sessions with test participants, and because they are intentionally not finished, they invite people to playfully interact with them. They can be extremely helpful in very early project phases, because usually that's when the last requirements are being negotiated. The big drawback of paper prototypes is that you'll have to create recurring modules as often as they occur. Also it's difficult to hand them on or to document them.

Electronic prototypes usually have a more polished appearance about them. This can be a disadvantage when it keeps test participants from voicing change requests – because they could think the solution is already near completion. In addition, the participants cannot directly interact with elements of the prototype. On the other hand, a modular approach can (more or less) be realized, and you can hand on designs to the project team. Documentation is a breeze too.

HTML is quite well suited for creating interactive prototypes – if you're savvy enough and / or got the right tools. A nice example is Adobe Golive. Golive allows you to work with objects and recurring elements that can be defined outside the page. It's relatively close to development and the target system, which can become a drawback as well – when the prototype is used as the starting point for developing the actual system. You should by no means fall into that trap; otherwise Alan Cooper's scar tissue will be created: Code that has been adapted over and over again, that is not elegant anymore, and that's by no means easy to maintain.

Of course you can create HTML prototypes without using tools such as Adobe Golive (or Dreamweaver) – it's just more effort. In that case you'd need an environment that can handle modules (and you find yourself deep in the actual development process), or you start creating ugly solutions based on frames within frames to let appear single pages as modules. Both approaches are suboptimal for accelerated prototyping.

I'll exclusively cover electronic prototyping tools in the following chapters.

Prototyping using electronic tools

Microsoft PowerPoint

Microsoft PowerPoint is probably the most widely used prototyping tool. As it is installed on nearly every office PC, it's got the unbeatable advantage that everyone can view a prototype created with it – and can perform edits. This leads to another question, the question of ownership. A prototype must belong to one person, and only this one person is allowed to carry out changes to the prototype. Even if this sounds like lots of work for this one person – this is the only way to ensure that the prototype is consistent within itself and reflects the current state of the discussion. (There may be exceptions to this rule if there are very strict design guide lines that are known to everyone involved in the project and if there is a top-down mechanism in place ensuring that people follow these rules.)

PowerPoint allows for fast putting together and a very rough initial arrangement of elements. Elements can be linked to simulate interactivity to a certain degree. Later, once you've been talking to engineering with a finished PowerPoint-based prototype and you've got a first glimpse onto a possible end result, you'll realize why PowerPoint is actually quite ill-suited for building prototypes: Measurements don't fit at all. You'll fit lots more onto an actual 1024×768 web page or screen than what can be displayed (and read and edited) on a PowerPoint slide. In addition, PowerPoint's scaling functions can tempt users to make elements fit on the screen that would otherwise never fit – which, unfortunately, results in  screens that cannot be built like that anymore.

Another really severe drawback of PowerPoint is that it cannot deal with modules. PowerPoint only works with copy&paste – and once you've distributed an element on 40 slides and need to go at it and change every single instance of it over and over again, you'll realize that something important has been forgotten and / or PowerPoint just isn't the tool of choice. To summarize: Not suited except for very rough idea visualization.

Denim

Denim is an innovative tool for early phases of the definition process. You can create pages and their links on different levels of detail, even simulate a certain interactivity. It uses gestures, if available also using a graphics tablet. Circular contextual menus speed up usage quite a bit. The tool, which is written entirely in Java, is available for Mac OS X, other *nix systems and Windows. Unfortunately it's got one major drawback: it's not really stable. In addition, it starts eating system resources like crazy once files become big, and the built-in HTML export functionality only works partially and produces code that, strangely, runs only on Internet Explorer. It's nearly impossible to export to PDF or just to print properly. So: promises to become an extraordinary, very innovative tool, but isn't ready yet.

Apple Interface Builder

Anyone who's got the Mac OS X developer tools (on original Mac OS X system disks or downloadable from apple.com) can use Interface Builder to create really extraordinary simulations of Mac OS X user interfaces. Simulations? No – these are actual UIs, just without logic and data structure. Guides appear automatically when you start placing elements on the pane, ensuring that the placement is in sync with the latest version of the Apple Human Interface Guidelines. Amazing! Drawbacks: it's only well-suited for application design (and only support app design really well), runs only on Macs, and saves only to the proprietary .nib file format.

Microsoft Visio

Microsoft Visio is actually a tool for creating diagrams of all kinds. It's well suited for this task, and that's what I used to use it for quite a lot. It's also used a lot to create screen design concepts. It's got the big advantage over PowerPoint that the presentation is much closer to reality; you can actually get an impression of how much content to fit onto a screen. Working with modules is possible since Visio 2003 by placing files in files (see this very helpful article over at BoxesAndArrows). Stencils can be used for recurring elements, too. Unfortunately, Visio uses a proprietary file format; it can export into a multitude of different other file and image formats, but none of them is really good. (The same applied to OmniGraffle, by OmniGroup. Unfortunately, GomniGraffle cannot place OmniGraffle files. It's available for the Mac only; Visio is Windows-only.)

Adobe Photoshop

The queen of all image processing tools is used for prototyping purposes as well. As you can combine elements in layers (and layers in folders …), you can simulate a certain degree of modularity. The great possibilities in Photoshop tend to tempt designers to create a much higher-fidelity design of the prototype that what would actually be necessary (or desirable) at a given project stage. At the end there's a rather polished design that cannot be changed as quickly. High-polished designs, in addition, can impress participants in usability tests and keep them from voicing their opinions because everything looks so "finished" already. Photoshop can export to a number of file formats. A drawback lies in the huge data files, which can hinder data exchange. If you want to rather use jpgs or pngs – to reduce the file size –, you again need a tool like PowerPoint to ensure things are viewed in sequence (e.g., in a scenario), or you'll have to create and maintain a naming convention for file names. That's why I feel Photoshop is only partially suited for creating prototypes.

Adobe Illustrator

The BoxesAndArrows article shows that Adobe Illustrator and Visio are the only two graphics tools that support modular prototyping. You create elements in files you place (as PDFs, on Windows, native Illustrator files are supported as well) in other files. If you change anything in the elements, these changes are reflected nearly instantly in the main files as well. Finished versions can be exported to PDF; you can assume that the Adobe Reader is pre-installed on nearly all systems. If – in addition – you've got Adobe Acrobat, you can create coherent presentations and, if you've got enough time, even put in links to simulate a certain degree of interactivity. A drawback of Illustrator (even in the CS3 version) is that it still cannot deal with multi-page documents (even though Freehand had this feature for so many years ago – d'oh.). This can be smoothed out using the PlugIn MultiPage (by HotDoor). Thus, you can combine complete sets of view in one file, source out and maintain individually modules and optimize the resulting exports in Acrobat. Should you also have got InDesign, you can place the finished views (or the modules) in InDesign and create design comments directly there – supporting the life cycle from prototyping to design documentation. One big disadvantage of Illustrator is the steep learning curve you encounter when getting in touch with a complex vector graphics package like this.

Axure RP

Axure RP Pro promises to be a very interesting tool – including integration into Word and HTML export. The demo I've seen recently looked impressive, but it also comes with an impressive price tag.

Conclusion 

Personally, in terms of prototypes, I'm currently most productive in Adobe Illustrator, possibly combining it with Acrobat: fast; close enough to the final result, but not too close; modular, that is it supports fast changes; exports files to a commonly readable format (PDF) that can even be annotated with the appropriate tools (e.g. Acrobat Elements). As licenses to Illustrator are normally not available with every office PC the question of ownership of the prototype is solved as well: It rests with a small number of people who stay in control of the prototype.

(This is the translation of a post for my now inactive German-language blog from June 2006 – I've updated some small things wherever necessary.)