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’ll be giving a short presentation about my Diary Study experience (same one I gave at UXCampLondon) at London IA in a Pub on October 14. There’ll be other presenters there as well, and it’s going to be a casual night of drinks and listening to some good talks. Space is limited to 50, so act fast.

boon :: Oct.04.2009 :: events :: 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 »

This isn’t technically a food review, since it was part of a London IA “Field Trip” excursion organized by @AliceNWondrlnd. The main attraction of the restaurant was the interactive tables from which you could order your meal from. There are no waiters coming to take your order. They sit you down at a table, and each table has a “session”, during which you can order drinks, desserts, food, play games, change the table “wallpapers”, spy at the kitchen, track your order amount, and some other interesting stuff.

Interactive Tables

The tables are given an immersive environment via overhead projectors and a trackpad on the bottom right corner of the table. Despite the excitement, the table was not a touch sensitive surface – we had to use the trackpad just as you would a mouse to navigate the “hand cursor” to interact with the system. I actually think it would be hard to design a system like Microsoft Surface, as we were resting our palms and arms on the surface of the table and not wanting the computer to pick those gestures up as interactions.

A small menu slides out, showing icons that indicate “drinks”, “food”, “table”, “entertainment” and “service” (I’m assuming all this, because the icons were not annotated with text or mouseover help). Each item leads to other sub-menu items, and they’re fairly easy to navigate.

Making an Order (Remotely)

When you make an order, you select an item from the menu and it appears on your order list. When you’re done with the order list, you hit confirm and wait for the food to be served by a waiter – it sort of just comes “automatically”. There is no interaction between you or waiters between any of the orders unless you specifically call for them.

This is quite a novel experience, but some people were afraid that they might have submitted the wrong order. A waiter assured us that it is possible to revert an order even after it has been confirmed, which is a good thing – but I think the interface could’ve been improved to cater for this – a waiter actually confirmed that this problem happens very frequently.

Placing an order was way too easy, which meant that the bill just kept going up. It was a bit like Amazon’s 1-click system – and it wasn’t obvious at first how to remove items from your order list (you needed to hit the minus sign next to your item in the order list).

Interactive Tables

In between waiting for the food to arrive, the table “entertains” you by giving you the option of playing one of two games (battleship and those picture puzzles where you have to move blocks around). You can also change the “tablecloth”, which was quite a nice touch as that made the whole experience so immersive. You could also view the live “kitchen cam”, and see what the chefs are up to. I didn’t find the “entertainment” options too distracting that I ended up not talking to the others. And to be honest, our discussions weren’t always focused on the experience of the interactions, despite being user experience geeks and all.

Overall experience

Interestingly, the waiters didn’t take long when we used the interface to “call” them. Service was fairly prompt and cheerful, so no complaints there. My only rant was that my set meal was a bit small – I ordered the cod set meal, and it was not enough for my large appetite. Despite this, the food tasted really good but you really end up paying for the overall experience, really.

The table “session” stops once you hit the “call for bill” button. Once that’s pressed, you can no longer order anymore items (unless you call the waiter), nor can you check the total of your order – which was a shame because we had wanted to pay separately. Thankfully, they were able to provide us with a seat-by-seat breakdown of the damages.

The trackpad was okay except when I accidentally placed a small bowl of miso soup on it, and the undersides of the bowl had some sauce so it make my trackpad sticky. One person mentioned her left-handed accessibility issue.

It’s not the only restaurant in the world to integrate interactive order systems. I’ve frequented Sakae Sushi when I used to live in Kuala Lumpur, and they use a more conventional mouse and screen setup. But obviously Inamo wins hands down for sheer experience, food and otherwise.

boon :: Sep.11.2009 :: events, fun/weird, user experience :: No Comments »

Visual Thinking for Design (Morgan Kaufmann Series in Interactive Technologies)

I was one of the lucky winners of this book from Morgan Kaufmann after I donated some money to the IxDA fundraising initiative. After turning in my MSc Project dissertation, I finally had some time to catch a breath. You’d think that reading a book on Visual Thinking would be the last thing on my mind after losing weeks of sleep to writing… I’m surprised myself.

Anyway, at a glance, this book is about understanding how we as humans interpret and interact with objects and environments visually. It’s written mostly from a psychologist’s perspective, and provides useful references to the theory and science of visual perception, cognition, attention, etc.

Colin starts off talking about how the eye and brain processes and perceives visual stimuli, and each chapter concludes with a set of design recommendations. He gradually works upwards the abstraction layer, dealing with topics like color and shapes, the relationship between visual and verbal processing, the process of “seeing” or “thinking” by sketching, leading up towards how we perceive meaning in a visual world.

I felt that I understood the subject matter a little better because I learned about cognitive science during the HCI course, so readers who are new to psychology may initially find it slightly alienating. I also feel that designers who are looking for design ideas may not find this book as an inspirational resource. I see this as reference material – something you pull out to make sure you’re doing things right, like getting more substantial evidence to support design ideas in problem solving.

It’s also a fairly easy book to read. Despite references to psychology terms like V1, V2 and top-down/bottom-up, the author succeeds in explaining things in simple language, and provides good examples of how the science of visual perception is linked to visual design.

The best parts of the book lie towards the end, and I think that the early chapters act as building blocks that support the overall perspective summarized in the last few chapters. The gist of it is that our mind, eye and body works together to look for patterns in the world, and that understanding how this takes place can aid designers in helping users to make sense of things more clearly and easily.

The implications on p. 172 are a key takeaway:

1. to support the pattern-finding capability of the brain; that is, to turn information structures into patterns
2. to optimize the cognitive process as a nested set of activities
3. to take the economics of cognition into account, considering the cost of learning new tools and ways of seeing
4. to think about attention at many levels and design for the cognitive thread.

(The word ‘cognition’ refers to the “process of thought”, i.e. thinking.)

In summary, this book is worth an investment. It’s one of those resources I will occasionally refer to for clear, evidence-based recommendations for visual design.

boon :: Sep.04.2009 :: books, cognition, design :: No Comments »

UXCampLondon has been the best UX event I’ve attended so far. Maybe because it was because I helped organize it, or that it was all of us presenting such amazing stuff, or that the team was so fantastic, or that the sponsors were so awesome or that Addlestones provided cider perks for the barcampers at the end of the day – a perfect treat out next to the Thames. No, it was a combination of all of the above, and more.

Presentations

Because I was half keeping an eye on the food order, I didn’t get to see all the presentations I wanted. But those I attended were really insightful:

Stuart Cruickshank’s UX for Search presentation provided insightful thoughts about better search interfaces because seriously, we’ve been stuck with old pagination paradigms for ages.

Angela Arnold made some insightful propositions for the use of images as internal tools to effectively communicate user needs to stakeholders – which I will definitely attempt to apply in my existing projects.

Alex gave a good talk about personalization – a tricky thing to design for, but no less compelling. A key takeaway – do users tend only to personalize things that they are familiar with, that they know they can’t mess up? E.g. sorting a sock drawer < theme-ing a Windows XP desktop < pimping an automobile.

I had a lot of fun at Darren’s session playing team-building games, a nice break and bit of variety from all the other presentations.

Cennydd and Dees’s discussion panel about location was really engaging – a lot of people sharing their thoughts and perspectives on what we really mean when we say “location” – x/y coordinates are not used in the same context as “in the pub with me mates”.

My own presentation on Diary Studies went fairly well. I was really nervous, but I think based on comments and questions from people showed they got good things out of it, and I was delightfully surprised to hear some perspectives about Diary Studies from other people as well – particularly how Diary Studies can be used to explore the entire user journey of a person.

Organizing UXCampLondon

Working with the team was absolutely brilliant. I got to know some really great people, and seeing it all come together and how everything sort of fell into place was just fantastic. I volunteered to help sort out the food order for the day and that was well received, so despite all the madness of ordering Indian food (waiters passing the buck, failed promises on call returns, GPS-less cab delivery) it all went well in the end. Suffice to say, you’d be better off ordering from somewhere else other than Dawat from Tooting. Mark my words.

The Awesome UX Community

I really love being a part of the UX community here. It’s small enough that you do meet some familiar faces fairly often, but big enough that you meet new people who are genuinely interested in building better experiences. It’s also amazing to meet ex-UCLIC students who are now established in the industry, like David Whittle and Whan Kim, and even more amazing to learn crazy stories like how I almost bought a used copy of Bodyspace a year ago from David and realizing that it got sold at the last minute this another guy who turned out to be Fabien.

Perks

• Meeting Jesse James Garrett and Kate Rutter from Adaptive Path a day before the event
• Free flow of cider from Addlestones at the end, and drinks on tab courtesy of Saros
• Hanging out after the event in front of the Thames
• Free FOOD – esp. sushi from Matsuba om nom nom nom – thanks to Amberlight and Vodafone
• eBay/Gumtree offices FTW

Best Posts on Twitter about #uxcamplondon

• mahemoff: “please don’t take a photo of the wifi key and put it on flickr” #uxcamplondon
• proactivepaul: being unqualified is the best qualification for ux @cdewsnip #uxcamplondon
• bash: This representation of Twitter search results makes me very happy. http://twitpic.com/eu4iq #uxcamplondon
• sjjh: @DominicTravers finds out what happens when you’re late for a talk at #uxcamplondon http://twitpic.com/eu4rs
• andybudd: Sometimes I worry that UX people over think and over complicate problems a lot of the time! #uxcamplondon
• mahemoff: Just realised eBay owns gumtree, that’s why they’re in the same building #uxcamplondon #duhMoments
• Cennydd: “Methodologies… I think we did all of them.” #uxcamplondon
• adrianh: Wait… what was my talk title again? (wanders off to the board to check…) #uxcamplondon
• Cennydd: “In the beginning… was the command line” – @joelanman in ‘The Power of Text Interfaces’ #uxcamplondon
• eyetie: “the best way to make people passionate about your business is to make them better at what they’re already passionate about.” #uxcamplondon
• andybudd: @Cennydd’s online game avatar is acute girl with pigtails! #uxcamplondon
• twhume: OH: “the hardcore market is male dominated” #uxcamplondon
• cyberdees: Addlestones and The Thames #uxcamplondon http://twitpic.com/eviwo
• dominictravers: To me, this slide represents my worst UI nightmare #uxcamplondon – http://mobypicture.com/?633l5g

I’m looking forward to the next one!

boon :: Aug.23.2009 :: events, user experience :: 2 Comments »

What I like about A/B Testing using Google Website Optimizer:

• It helps provide real, direct data (as opposed to sheer guesses, or “eye-balling” secondary sources of data)
• It helps you build strong skills in testing
• It’s fairly straightforward to setup
• It’s fairly flexible – allows for HTML markup, etc.

See how 37 Signals puts A/B testing to the works here.

See Carsonified’s blog post about doing A/B Testing with Google Website Optimizer on Wordpress here.

For a quick overview, watch the video from Carsonified below:

How to do A/B Testing with WordPress

boon :: Aug.03.2009 :: evaluation, resource, tools, web, websites :: No Comments »

So, I just posted a few days about stumbling upon UX taking 6 months.
That process can be cut short by reading one of those really awesome articles about what UX is all about.

This one by Whitney Hess is superb:

http://whitneyhess.com/blog/2009/06/so-you-wanna-be-a-user-experience-designer-step-1-resources/

boon :: Jul.03.2009 :: resource, user experience, websites :: 1 Comment »

I’m employing a diary study for my MSc dissertation on image search, and I realized I was doing it all wrong today when I met with my supervisor and project sponsors. Well, okay I wasn’t entirely clueless but I did make some pretty bad assumptions about diary studies, and these were the lessons I learnt.

1. Don’t assume people remember what they noted in their diaries

I started off telling my participants that all they needed to do was fill in their diaries with descriptions detailed enough so that they would be able to recall the activities. I told them the study would last two weeks, based on some ballpark figures I discussed with my supervisor, and I told them that I might give them a call every now and then to “see how they were doing”. In a recent meeting my project sponsors and supervisor suggested that I should call them daily, because there’s a high chance that the participants would forget a lot of the rich detail that you want to get in a diary study interview.

I had to correct my slip by contacting every one of my participants to ask them permission to call them on a regular basis, and thankfully the ones who have gotten back to me so far have been totally cool with that because they were acquaintances or friends. But it was just bad foresight on my part.

2. Be as specific about your population as possible

When I sent the word out that I needed participants, I had a lot of friends were willing to participate because they had they time and they didn’t mind doing it (plus there was a £40 incentive). I didn’t think too much about the demographics of the population and I let in two participants who were edge-cases – a photographer and a graphic designer. In my study about domestic image search behavior, they’d stand out in a crowd. Thankfully I had other participants who were more “normal”, but I would’ve saved myself the embarrassment had I spent a bit more time thinking about who I should’ve been recruiting.

3. Research requires testing too

I assumed that people would quickly understand how to fill in the diary forms, because they were relatively straightforward. I was promptly advised to call in and check with my participants so that I could get a quick “feel” for the differences in behavior and data, and adjust the study process accordingly. Some participants, for example, may be more active internet users than others, for example – so they would need less “checking up” since they would have a lot more stuff to report after a few days of diary-filling. I initially thought that calling them they day after I had spoken to them was too soon, but there are ways to inform the participant of how often you need to get in touch with them.

4. Don’t believe everything you read in books

I guess it’s not all method-driven and form-filling. There’s a bit of an art to this, so I guess it takes a bit of practice to get a hang of it. My supervisor/project sponsors were forgiving and kind enough to guide me in the right direction, but I could’ve saved myself by asking more questions, talking to the right people, and not just basing my ideas off books.

update: I’m still looking for a few more participants, preferrably male aged 40 to 65. If you’re interested, please email me at boon [dot] chew [at] gmail [dot] com. For more info, click here.

boon :: Jun.25.2009 :: tools, user experience :: No Comments »