Interaction

Everyone’s hyped up about getting a Google Wave invite. I have one and I don’t see what the fuss is about. Yes, I’ve seen the YouTube video, and yes I’ve watched the Developer Preview video too. It looks great and all, but seriously folks – it’s one complicated thing… next to email.

And this is why Google Wave isn’t about email. The same way computers aren’t (just) about calculators.

What it is is real-time collaborative messaging with historical playback. Which, granted, is very good for real-time anything. Except that real-time in human terms is highly contextual.

Because people have better things to do besides sit in front of their computers all day long, they are much better off carrying Blackberries and having push email rather than collaborative messaging. In my opinion, push email works just as well – because you don’t need to be in front of a computer to communicate with your colleagues.

Wave is also a tool. Meaning that the interface itself is not the message. In order for users to synthesize information, they have to make sense of it in a collaborative sort of way, which means paying attention to whatever is happening in that messaging window, which takes up at most 1/2 of the screen. It looks and feels like, a video player – but for messages. Think of IM on steroids, not email.

Email works because it’s mind-dumbingly easy. And because of that, nobody needs to take 3 week lessons on how to use email – and that includes your grandpa. And because it’s so atomic, it can easily be transported as a message to any other atomic messaging forms – SMS, blog post, forum post, IM chat, whatever.

Waves, on the other hand, are almost asynchronous streams – anyone can start writing content at anytime into a wave, and hope that it doesn’t make a mess of the conversation. Last I checked, people still pay attention to body language and subliminal messages, both of which are devoid in Wave but affects the way people communicate collaboratively and socially together – i.e. turn-taking and all that jazz.

Which part of a wave is atomic? You have to spend effort to calculate and decide. Then you have to find a way of “clipping” that message – and how do you make it portable? Can you cut and paste portions of your wave onto your blog? SMS? can you print it out?

Like email, most of what is published gets fixed in time. But a Wave, is a collection of content played out over time. Just like how photographs put together over time become videos. But with the added complexity of multiple sources of photographs, it becomes more and more difficult to separate and organize content in a Wave.

And that’s why Google Wave is not about email.

Sites and Articles Relevant to this Post:

• It’s Just Fancy Talk
• EasierToUnderstandThanWave

boon :: Oct.13.2009 :: interaction design, technology, tools, web :: No Comments »

I’m currently in a team of 3 people working on a redesign of a website. To me, this feels like my first “real” design project, one where I’ve initiated without any requirements for software implementation. Instead, we began to ask ourselves who are our users, and what exactly are we trying to communicate to them?

User-Centred Design – Using What Works For Me

I felt that a lot of “formal” usability methods didn’t help me much, here. I felt somewhat trapped by procedure and process, thinking about best practices for wireframes, personas, user journeys, etc. Having been exposed to too much user experience jargon, I realized that user-centered design isn’t necessarily synonymous with visual design. In fact, each stakeholder seems to have a different understanding of who the user is, even if the differences are slight.

What ended up working for me was to put down the questions I felt the users would ask (while using the interface/application) onto little bits of post-its, and looked for patterns like organizing those questions into related categories. I organized this in several ways:

“User Journey”-type Things and “Site Map”-type Things

One way of visualizing the questions was to list them out in the style of a “user journey”, which were lists of questions laid out in a temporal fashion (e.g. question A leading to question B as a user traversed deeper into the application). This helped me understand which questions to address first, and which to address later. It helped me prioritize my workflow, and make decisions on which interfaces to work on first. It was already obvious that we needed to focus on designing the homepage, but there were other pages that weren’t immediately obvious, such as a page to help users to “learn more” about the product – that page only came about after looking at the questions from the user journeys.

Another way was to group the questions that were related to one another, and label them as categories. That helped me to visualize the overall site layout, because I absolutely hate building software in the dark – and that includes building on software requirements without understanding the whys to the point I’m convinced of its business and user needs.

At this point, I hadn’t used any formal methods I had learnt from a class, website, or book. It was good that I understood who I was designing for, and I wouldn’t have been able to do this without classes, websites and books – but the formal methods were pretty useless. I just used what worked for me.

We Used Fireworks, but I can’t Recommend it to You

It’s important to note that two of us jumped onto paper and pencil and did wireframe sketches, and then designed a hi-def visual of the homepage on Fireworks (which I now really love) – only because we were three people and we couldn’t quite picture the outcome in our minds. At the same time, we needed our boss to make a decision and he has a lot of emotional attachment to the look and feel of the site, being the founder and all. So it was important to get those designs out.

I don’t think I can recommend the same process to other designers – it really depends what you’re designing for. Those fireworks designs took up several days and a lot of it was thrown out of the window as we iterated from one design to another. But I think that’s necessary in design, sometimes – because the interface is what users will end up seeing and using, again and again.

Sometimes I read articles from other designers and it all sounds really cool and makes you feel that there’s some kind of order or process in the design of an interface. But I find these things hard to use because it’s the designer that makes a difference, not the method. It’s about knowing what you know that works – a process or method can’t save you. They’re just tools.

boon :: Oct.04.2009 :: interaction design, tools, user experience :: No Comments »

I love this idea: http://www.somebits.com/weblog/tech/good/webapps-with-json.html

boon :: Sep.21.2009 :: interaction design, web :: No Comments »

I’m at the start of a new phase of our development, and we’re at the point where we need to generate ideas for our interfaces. I’ve observed that wireframes aren’t always well-received by people who don’t understand them – clients who think they need more color, developers who want to code over it, etc. If the only resolution we have to this problem is educating the public, I think we’re in for a very long ride.

This might be because wireframes aren’t obvious enough to people.

You heard that right – if people are misunderstanding your wireframes for a finished product, or your sketches for a placeholder for a WYSIWYG dev tool like Visual Basic – there’s clearly something inappropriate about the tool’s use.

I believe some of us take wireframes for granted, such that we see no other way of implementing a product. While wireframes work well for some designers, I sometimes think they take up time and that there might be better, faster, more efficient ways to build software.

Also, wireframes aren’t great for super-dynamic AJAX-heavy interactions. And they aren’t great if you want to break out of the 2D mode, and work with more dimensions (how do wireframe a keypress, or an animation, or audio?).

I remember the first time I used tons of wireframes on a project, and ended up realizing that we wasted all that time building hi-fidelity prototypes just because I felt it was the right way to design an application. Time was wasted testing the prototype because we didn’t get THAT much insight out of it, simply because it was so blatantly obvious – we should have just tried it on ourselves before testing it on other users.

I’m probably stepping on some UX no-go zones – aren’t we supposed to test apps on real users, and not ourselves? Well, I think there are some things which are so blatantly obvious you needn’t waste the users’ time to fix or test. Testing via paper prototypes a la Carolyn Snyder isn’t always going to save you time. There are much faster ways to get it done, if you think through it a little.

I’m not advocating against wireframes. I’m just advocating against getting locked down on a specific method – against “methoditis” – you know, when you start believing that one method is better than another just because.

Basically, you might want to re-think wireframes if they:

• confuse the people you’re communicating to
• take up time when something else can be so much faster
• cut down too many trees

Here are some examples or ideas of doing without wireframes:

• http://gettingreal.37signals.com/ch11_Dont_Do_Dead_Documents.php
• http://code.new-bamboo.co.uk/polypage/ (a tool developed by Clearleft and New Bamboo)
• method-acting (see Bill Buxton’s Sketching User Experiences for an example a designer “being” the device)
• plasticine? feel free to add your own examples.

boon :: Sep.21.2009 :: interaction design, tools :: No Comments »

Because I have been doing a lot of PHP plumbing lately, I’ve been thinking a lot about implementing a web interaction framework that would make my life easier as a web developer cum interaction designer. One of things that got me thinking is the amount of complexity that’s involved in provide the right kind of feedback at the right time to the user.

No plugins allowed

It’s not as easy as hooking up messages to specific URLs, which get displayed when an action is performed. Interaction is complex, some involving multiple conditions and terms. And you can never design for everybody in mind, because there’s always an issue of context that you have to deal with. So, then what you’re actually trying to build is based on an assumption of the kind of context that is most appropriate for the task at hand.

For example, take the simple case of a password reminder. Although it’s relatively straightforward to implement a mechanism to send off a password via email, how the user  has arrived at that task is another thing altogether. A password reminder system for an online banking application would look a lot different than a social networking site. Do you send the password along with the email? Do you send a link with that takes the user to a page to reset the password? What should the messages say? How often do these password reminder tasks occur with the existing user base? How did they know how to find help?

With such a basic task, there’s already so much to consider. What more a task that involves collaboration, scheduling, persuasion, trading, payment, and communication.

The bare necessities

This is when I started to take a step back and ask myself – what are the most essential things that I need to build an effective interaction framework?

1. I mentioned feedback, so I think notification is one of them – a way to inform the user regarding the state of the application or system.
2. Then, I think there’s the element of context I mentioned earlier - technology can help with helping us understand more about what is appropriate, and also helping us in designing for what is appropriate.
3. Also, I don’t think we can ignore the interface itself - all the buttons, fields, and little components that are used to interact with the system. I think this is the main part in what we usually consider as interaction design.
4. Somewhat related to the issue of context, but I feel deserves its own section, is testing - or, evaluation. This is so that we can identify potential areas of improvement by understanding the patterns of existing user behavior.
5. Finally, because all interaction is both a function of time and space, I feel that there needs to be an element of process – some kind of journey, or set of occurences that take place one after another. Much like how stories are expressed using specific narratives, interaction is also played out between the system and user through various sequences.

There may well be more, but these have been on my mind lately – ways in which I think a framework could help in solving interaction design problems.

Design patterns and human predictability

While I think design patterns like the ones from Tidwell’s ‘Designing Interfaces’ or Welie’s pattern library are extremely useful resources for solving interaction problems, they are also somewhat limited as they don’t propose more high-level strategies for interaction design. This is simply because many of these patterns are extremely tangible, and are essentially a collection of existing interactive solutions that have been known to solve common problems in interfaces (e.g. accordions, tooltips, tag clouds, wizards, breadcrumbs, etc.)

This is where I think an interaction framework can help – by providing the necessary “glue” and language by which these patterns can coexist and integrate in a flexible, scalable, managable way.

My inspiration comes not from the hubris of Steve Jobs, nor the empathic anecdotes of Don Norman. Neither is it from the pragmatism of Cooper’s Goal-Directed Design methodology, to which I owe great thanks in sparking my journey toward interaction design. Instead, I was inspired by J2EE design patterns from my early days as a Java developer.

This is an important distinction is because all of these design patterns come to play in a systematic, structural whole. Whereas, many of the existing interaction design patterns we know of now are sort of separate and somewhat distinct from each other.

	System Architecture	Interaction Architecture
Transform, Manipulate, Guide, Communicate, Create, Translate, etc.	Bits, Bytes, Strings, Numbers, Objects, Packets, Records, Emails, Documents, Interfaces, etc.	Emotion, Feeling, Mood, Action, Behavior, Values, Words, Drawings, Opinions, Stories, Decisions, etc.

In a way, I am envisioning an interaction architect structuring an interactive system the way a system architect designs an application’s infrastructure. The system architect defines the language in which data (or manifestations of it) is transformed, manipulated, sent/received, created, etc. The interaction architect defines the language in which human attention, behavior or actions are transformed, manipulated, communicated, guided, persuaded, etc.

Some comparisons

Bill Verplank proposed an interaction framework that looks really interesting. It’s set up mostly to assist teams in designing interaction and interfaces, and has little to do with the actual nuts and bolts of a particular interaction technology. This is all fine, because as an interaction designer you don’t necessarily want to lock yourself down to any particular technology. In the same way, Cooper’s Goal-Directed Design also proposes a methodology that provides a practical framework for understanding who the target users are and designing for them. GDD also takes the approach of being technology agnostic, although Cooper mostly refers to software interfaces like desktop applications, mobile phones and websites.

However, I think there’s a growing need for a technology-focussed framework – one that sits just between the sort of team-focussed, process-driven, project methodology – and the tangible, collective, distinct set of pattern libraries I talked about earlier. I am probably thinking about web applications, but this can apply to any other technology (Air Traffic Control systems, for example).

The J2EE design pattern specification exists for Java architects to build enterprise Java applications in scalable, managable, flexible ways. In a similar vein, interation designers can establish similar frameworks for their own interactive systems – that sits between the system and the project, that can be expressed in terms that are more closely linked to the systems themselves (like interaction design patterns are), rather than wireframes, storyboards, sitemaps, affinity diagrams – stuff that’s more commonly used for communicating between people rather than communicating between systems.

boon :: Jun.17.2009 :: interaction design :: No Comments »

I’m currently through my second and final week of the Design Experience module – where we get into groups and use all the HCI skills we’ve learnt to good use. Our job this year is to come up with a navigational device for tourists. Our group has decided to focus on museums, and we’ve gone through user observation, interviews, personas, paper prototyping, etc. – and even though we’ve  we still have debates over whether we’re doing the right thing, sometimes.

Is this the experience of design?

I sometimes think about what’s essential past the logical reasoning for the way we design interfaces. One thing we don’t get very much in a HCI course like UCLIC’s is studio work. Unlike many design schools that function like apprenticeship workshops, we only get hands-on work during project days – hardly a chance to overcome our shyness of doing fieldwork and working with real users.

Last weekend, when I was interviewing some tourists at the British Museum, I found it really hard to come up with the right questions and help people feel at ease. I got better with each try, but it wasn’t easy. I learnt a bit of how fieldwork is done from books like “Tricks of the Trade” by Howard S. Becker, and from papers on design ethnography – hardly a core part of conventional HCI courses.

I also observed that our groups tended to talk more than sketch, prototype, wireframe, or interview. We have lengthy discussions about definitions, the usefulness and appropriateness of methods, whether certain methods were applied properly, or whether they should be used at all. Our modules constantly focus on the value of ‘reflection’, and I’m now wondering if there’s such a thing as ‘over-reflection’ vs. just-get-the-damn-thing-done… just my way of saying talk after doing rather than before.

It’s hard to learn everything in a year, but I’m getting the feeling that all this learning is preparation for even more learning – of the hands-on kind.

Already, I’m applying this as a programmer with a small startup company I’m doing some part-time work for. We hold one-day sessions where we sit around a kitchen table and get stuff done. If we need to draw references from books or methods, we do it. Otherwise, whatever works gets applied. It doesn’t have to be perfect, but it needs to function first. We’re applying design as we produce our work, not before.

Side-rant:

Recently, there’s been some debate over what interaction design is (or isn’t). Does it really matter? Is this a concern because we’re trying to establish an industry, and that we need to formalize our reputation with our clients? Maybe we still call ourselves programmers, or graphic artists, or project managers – but we do a good job of it,  because we understand more about the way things work the way others can’t. The terms, ‘usability’, ‘user experience’, ‘information architect’ and the like seem to be transitional. Who knows what businesses might call UX practitioners in 5 years time?

I do hope that in due time, more people are aware of practitioners who apply user-centered solutions for interactive systems. But it involves us going out, interacting with industry and users, and solving their problems – rather than poring over books and figures.

boon :: Mar.24.2009 :: books, design, interaction design, mobile, user experience :: No Comments »

I’ve just spent the last 10 or so hours mucking over Kohana, Doctrine ORM and jQuery – all of which I really enjoy and think are great, but I’m starting to doubt my own ability to code. Do Javascript programmers spend more time building functionality and interaction, or mangling the libraries and fussing over browser compatibility? While I think jQuery is a brilliant API, I’m always wary of the quality of plugins that people write. Same goes for Wordpress plugins. I guess free does come with a price (like the price of not using Java).

Which leads me to think – can there be a lone UX expert who also does web development? I’m sure there are folks out there who make a living doing this, but the literature treats the fields so separately it’s hard to see how these experts manage the line between the two.

Even with a team of two people – a UX designer and a web developer. How do they interact? Does the UX designer have a head start to come up with all the wireframes and storyboards, who then hands it over the programmer to make it functional? Do they work together in an agile fashion?

I think that as most technical work goes – there’s less and less breathing space for UX designers and web developers to work in very small, efficient teams, unless they are very, very good. I’m not saying that everyone else just sucks, but building websites can take a lot more time than you think it does, and unless you’re designing mom and pop websites all the time, it’s going to be hard to guarantee how much time is required to build good sites.

While plugins and APIs can be useful in increasing speed, they also can lock down the interaction and degrade the user experience if not planned well. Maybe established sites understand this all too well, and take a phased approach. Maybe this is why Flickr only launches a new (but exciting) feature only once every few months.

I used to think that as technology improved, so would our ability to build products. But I find that this isn’t always that simple. In fact, despite all the effort being put in to build so many plugins, APIs, platforms, patterns, components, etc – it still takes a lot of effort to put things together properly.

Thus, all software is bespoke, and are not exactly a lego-like mashup of neatly interfacing components that we tend to think it does.

My only question is, if we are to get better, how? Apart from being willing to devote ourselves to our tools and simply, get our hands dirty.

update: I found this presentation from Leah Buley from Adaptive Path, which she gave at SXSW’09. It comes quite close to what I was talking about. I’m not quite sure it always works out so simply, but I like the idea.

boon :: Mar.14.2009 :: development, interaction design, user experience, web :: No Comments »

ACM publishes a fantastic journal on human-computer interaction. They’ve made the Jan/Feb ‘09 edition publicly available online.

Interesting article titles I skimmed from the “Contents” page:

• Social Network Sites and Society: Current Trends and Future Possibilities
• 90 Mobiles in 90 Days: A Celebration of Ideas for Mobile User Experience
• The Washing Machine That Ate My Sari—Mistakes in Cross-Cultural Design
• Design Versus Innovation: The Cranbrook / IIT Debate
• Can “Wow” Be a Design Goal?
• The Value of Visual Design in Software Development
• What is Interaction? Are There Different Types?

Link source from experientia.

boon :: Jan.29.2009 :: books, innovation, interaction design, mobile :: No Comments »

I bought this multi-functional clock from Muji which features a fantastic gravity-operated design. You simply rotate the device the “Feature”-way-up to activate that mode. As you can see, it’s currently on Calendar mode. I rotate clockwise to get to the “Alarm” mode.

Very simple operation. A “beep” signals that the mode has changed. The settings are done via two buttons, located behind the device.

It’s price? £6.80.

With batteries included.

It did, however, spell “calendar” wrongly. A “calender” apparently means something else.

boon :: Jan.27.2009 :: innovation, interaction design, usability :: No Comments »

…many students from HCI programs don’t emerge well trained in experimental design, statistics, methods for consumer research, content analysis, or ethnography. These gaps in their research skills limit them when it comes to opportunities in other influential business roles, including promotions beyond the usability function.

- Lynn Cherny, Interactions 2007

This just scares me.

This quote, the final paragraph of the article, is the proper frame of context:

We can’t just talk about the importance of good design. If we don’t create good design, user experience and product innovation won’t be coming from us, but from someone on the engineering team. And we’ll be lucky to be asked to evaluate it.

- Lynn Cherny, Interactions 2007

boon :: Jan.13.2009 :: interaction design :: 2 Comments »