A few months ago we set up five Flickr groups around several UX topics. Every month we will try and make some sense of the uploaded material. This month we selected the UX Errors group and will look at examples of issues that arise when proper attention isn’t paid to two very important components of successful user interface design: Perceived Affordances and Designing for Task Flow.

Perceived Affordances

In The Design of Everyday Things Don Norman introduced many designers to the concept of affordances, which he would later clarify as “perceived affordances”, or the actions the user perceives as being possible based on how an object is presented. For example, if your design includes a “button” make that button look pushable.

Posted by Adam Connor

Push me. Wait… you can’t

The ATM example suffers from some misrepresentation. The labels for the physical buttons are styled with bevels, commonly used to represent buttons in GUIs. As a result, many users try to press them, only to realize after a few attempts that the buttons are actually to the right and left of each label. In this case, objects give off an inaccurate perceived affordance.

It’s not uncommon for ATMs to have physical buttons and digital label displays. In this situation, it looks like someone thought that adding a little visual “excitement” to the labels would be an improvement. If simple, plain text labels had been used, people would most likely have experienced less confusion.

Posted by Olivier Lorrain

Where’s the Button?

In the gas pump example people tended to press the octane number, as evidenced by the fingerprints around the “87″, when choosing a fuel. This happened despite the “Push to start” label on the actual button and the arrows pointing to them. In this case, there isn’t enough emphasis given to the real button in comparison to the large yellow square label. Which begs the question, why not just make the yellow square the button to begin with?

Posted by Andreas Popp

Which way is up?

In our last perceived affordances example, we have three components, all with a triangle/arrow pointing up, all beveled from the panel on which they are presented. Which one do you push to direct the elevator up?

The two arrows on the top are lights, which indicate the direction the elevator is traveling, while the lower button is the actual call button. Many users pressed the lights in order to call the elevator. Why? Most likely because the bevel caused people to perceive them as buttons. Also, the lights have a higher visual significance than the smaller triangle on the actual button. Had there simply been no bevel around the two lights, it’s likely there would be less confusion and more people would find the real button first. That’s not to say that the button itself couldn’t use a bit more visual prominence in it’s display too.

Designing for Task Flow

When I was in grade school there was an exercise we did where each student had to write instructions on how to construct a peanut butter and jelly sandwich. The teacher then attempted to construct the sandwich according to those instructions verbatim. If an instruction left something out, small details like removing a slice of bread from the bag containing the loaf, the teacher would stand there and act stumped until the student modified their instructions to be more specific.

The purpose of the exercise was to give students an appreciation of the fact that even simple tasks are comprised of a multitude of steps, and that finding the right level of detail and sequencing for those steps is critical to user’s success and satisfaction.

Posted by Eugenia Ortiz

Follow the Arrows

In the example to the right, there appears to be some attempt at sequencing in the digital display as well as from the large “2″ at the bottom of the device. In this case however, some considerate and/or frustrated individual(s) has taken it upon themselves to try to make up for the devices inadequacies by adding additional instructions and labels.

Posted by Frank Farm

Easy as 1, 2, 3

Our second example also uses numbers, in addition to a list of instructions, to provide guidance. Yet the arrangement of components and labels gives a perception of chaos that even a well written set of instructions can’t overcome.

Both of these interfaces exemplify that in user interface design, identifying a sequence of actions is not enough. Numbers and lists, while somewhat helpful, should be used in conjunction with a logical and sequential arrangement of controls and inputs.

Johnny Holland’s Flickr Groups

Observations are a critical tool in any designer’s tool set. They provide us with in-site on things we should do, shouldn’t do and could do better. Many of us photograph our observations to preserve them, to keep them as reminders, learning tools that won’t be lost in the background when our next big breakthrough comes along. We also share our observations so that we can learn from and educate others. So that we can build a stronger dialog and further conversation.

To that extent, Johnny Holland has established five Flickr groups, so that we can share, discuss and learn from eachother’s observations.

In addition to the UX Errors group, where we collect examples of design decisions that have a negative impact on individual’s interactions with a product and overall user experience, and from which this month’s examples were taken, we have:

• Daily UX: collecting pictures of everyday user experiences, good or bad.
• UX Sketches: collecting sketches of products, interfaces and ideas
• UX Patterns: collecting examples of interface and interaction patterns.
• UX Events: collecting photos from UX conferences and meet-ups around the world.

Like any collaborative effort, these groups are what we make of them. So please join, share your photos, comment and discuss. And if you have any ideas on how we can improve the groups or better utilize them, please let us know.

Style guides are a great way to ensure user experience consistency when developing an application and a way to communicate user experience standards across an organization. They can be application specific, platform specific, and may encompass enterprise-wide standards. A style guide can help make the development of user interfaces more efficient and help ensure good user interface design practices.

Types of Style Guides

Style guides for applications usually contain specific instructions on how to design and develop an application’s UI. In some instances, code snippets may also be provided to simplify development of the application.

Example of an application style guide specifying a web page template grid

Enterprise-wide style guides may include standards specific to an organization. These style guides may overlap with company branding style guides that are often defined by marketing departments. They can outline a variety of company-wide items such as standard colors, typography, logos and language.

Example of branding color definitions found in a corporate style guide

Platform specific guidelines are often tailored to a specific platform, such as desktop, web, or mobile. These style guides often give particular guidance on how to design for that platform, such as control and content guidelines.

Example of a link control definitions in a website style guide

The style guide you choose to create can be any combination of these three types. It’s up to you to figure out what makes the most sense for you.

Style Guides Are Not UI Specifications

Style guides are different from user interface specifications:

• A specification document details the functionality of a UI design for developers building an application. It is usually more descriptive and is often accompanied by wireframes that act as blueprints for the design. In contrast, a style guide is often a general outline of the elements of a UI design.
• Style guides have a longer shelf-life than specifications documents that are often tied to a project life-cycle. When an application is first created, some elements of the initial specification document might turn into the application style guide for long-term reference.
• Elements of a style guide may be referred to from a specification. For example, the functionality of a web application enhancement would be captured in a specifications document; but the operation of standard UI controls found throughout the website would be outlined in the website style guide and referred to by the specifications document.

How to be Successful

Over the years, I have had a chance to create a variety of style guides. The format and purpose of these style guides were variable and were suited to the task at hand: such as details of the grid layout, colors and typography used in a website and a general guidebook providing guidance on the use of website user interface controls and how to write web-based content. From these experiences, I’ve learned a lot about what makes a style guide a success and I’d like to share some of these tips with you.

1. Keep the audience in mind

Style guides can be written for numerous audiences (e.g. other user experience practitioners, developers, graphic designers, business analysts, etc.) and the content should be structured to match the audience. Graphic designers would benefit from knowing the colors used in a website elements and programmers may desire knowing the code used to create a control.

2. Plan for success

When planning a style guide, seriously consider what would make your style guide successful in your organization. Would it be ensuring your company understands how to better design usable applications? Or would it be ensuring the large-scale website you are creating has a consistent user experience? Or would it be something else?

3. Keep it alive

Documents produced in traditional document formats can become stale and quickly become outdated. Successful style guides are produced in a manner that supports easy maintenance and supports a living document.

4. Define a review process

Create a process that supports modification and review of the style guide to actively ensure style guide maintenance and buy-in. You may want to have a person or group of people responsible for periodically updating a style guide.

5. Think of the platform differences

Style guides can be platform specific or neutral. Design guidelines can be different depending on the platform (i.e. Windows vs. Mac, iPhone vs. Blackberry). Consider how you want to support communicating any platform differences when creating your style guide.

6. Socialize the document in your organization

The use of your style guide should be communicated throughout all levels of your organization to ensure everyone knows the existence of the guide, understands how to use the guide, and actively works to use and maintain the guide. The more people about your style guide, the more successful you and your style guide will be.

7. Clearly define mandatory and flexible standards

User interface design is part art and part science and user interface paradigms shift quickly. Ensure that your style guides support new platforms and creative ideas by specifying what standards are mandatory and what are flexible. For example, you may want to ensure certain usability rules are strictly adhered to throughout your applications (i.e. “Sans serif fonts must be used for text that will be read on a screen”), but be more flexible in other areas (i.e. “Radio buttons should be used when a user is asked to select one item from a list of items.”)

8. Make the style guide as scannable and searchable as possible

Style guides can be very dense and contain a lot of detailed information. Search and browsing capabilities will make it easier for people to find what they are looking for in your style guide. In addition, use as many visual examples as possible to support quick scanning of style guide elements.

9. Provide real world examples

Successful styles guides often show one or more examples from real applications for illustration. If you are writing a style guide for a specific application, use examples from that application to demonstrate your point. If you are writing a style guide for a large organization with many applications, ensure that your examples encompass all of the applications you are describing.

I hope you find these tips helpful when you are creating your own style guides. Do you have any additional tips you would like to share?

—–
Header image by nathanborror / /CC by 2.0

Design patterns are among the most underrated tools in the world of interaction designers. And that’s not because they are difficult to apply, but mainly due to the fact that designer are stubborn. We want to come up with all the solutions ourselves. But why? If you use patterns you save time and money, and you are more sure that your product will be understood by it’s users. Fortunately there are still believers, and they even wrote a book for us.

In 2005 Jenifer Tidwell published a book called Designing Interfaces, which can be considered as being the mother of the title I’m currently reviewing. The book gave us a solid overview of the most common design patterns around. It served as a superb handbook for any user interface designer. But as we all know, the digital world evolves in a very rapid way… new technologies aris and new solutions and patterns must be developed. So it isn’t strange that Bill Scott and Theresa Neil decided to publish a book full of great web patterns. And that’s the book we’re going to review now: Designing Web Interfaces.

Contents of the book

While Designing Interfaces had a very ‘physical’ structure (chapters with headers, navigation, footers and forms), Designing Web Interfaces has a different approach. It uses principles to structure the different patterns. With this method the authors learn us the main principles that are (in their mind) important to design web interfaces. So let’s take a look at the different principles and content of the book:

Make It Direct

In this chapter it’s all about making it clear for users when they can change something on a page. How do you make a page visually appealing and still make it very clear what can and can’t be edited?
Chapters: in-page editing, drag and drop, direct selection

Keep It Leightweight

Websites are becoming more like software by the day. With this principle you learn to keep actions simple: provide sufficient feedback, but also keep it simple.
Chapters: contextual tools

Stay on the Page

Not every click and action should result in loading a new page. Sometimes you only want to refresh part of a page (like with e-mail on Gmail) or you don’t want secondary information to cause users to leave a page (so you use overlays). This principle and the chapters give you great tips when and how to do that.
Chapters: overlays, inlays, virtual pages, process flow

Provide an Invitation

With websites becoming more complex you need every space you can use to provide good contextual information and support. In this principle you learn how to help visitors to discover the possibilities on a site, via inviations. For me this is one of the more interesting new ways of learning people how to use your site, by giving them a live tour through your site/page.
Chapters: static invitations, dynamic invitations

Use Transitions

In this chapter you get a series of patterns on how you can use transition to tell the right story, stay in a flow and get the correct attention.
Chapters: transitional patterns, purpose of transitions

React Immediately

You see it ever more often, getting suggestions in search boxes while you are typing. This, and other direct feedback, are becoming the standard. People expect nothing less from website than direct feedback. In two chapters the book shows us a series of lookup and feedback patterns that could help you fulfil many expectations.
Chapters: lookup patterns, feedback patterns

Conclusion

What I really liked about this book is the detailed, but interesting to read, way that the patterns are described… Instead of just showing us the best way to do it, the book manages to give good context. In some cases it shows different appliances of a certain pattern, describing the advantages and disadvantages in detail. This is really usable material for interaction designers, because it makes us aware of the necessary detail. A lot of designers will just design a page and describe the interaction in general, leaving it to the programmer to come up with the best solution. But it’s not just his responsibility, but (also) that of the interaction designer. We must understand how a user will respond, and patterns and facts (like: making something respond after dragging for 3 pixels makes something feel smoother than after 5+ pixels) help us do that.

So, in my opinion, every interaction designer should have a book (or online source) with design patterns within reach. It helps making decisions faster, and saves time for the real innovation.

Book details
Designing Web Interfaces
author: Bill Scott, Theresa Neil
published: O’Reilly, 2009
details: 296 pages, softcover

In the wake of the ever increasing popularity of gestural interfaces, Dan Saffer wrote his newest book: Designing Gestural Interfaces. In this publication by O’Reilly he tries to give us some valuable insights. But did he succeed?

Gestural interfaces are not new, but they are more popular than ever. Everywhere around us you see new ones popping up. And before everybody is coming up with their own interpretation and translation of what they should be and do, we must evaluate what has happened in the past and how we must deal with the future. Dan Saffer’s book is a great starting point for this exercise.

Let’s go through the book chapter by chapter.

The basics

The first chapter is an introduction to the subject. It gives a good and basic explanation. One interesting part of this chapter is ‘matching the gesture to the behavior’. This approach states that the best designs are those that ‘dissolve in behavior’. Here the product must become part of what the user is doing fluently. This is what good gestures should be, combining peoples natural behavior with a related action.

The human body

In the second chapter Saffer focuses on the human body, something a lot of designers often forget. The importance of understanding the mechanics of a human body is really fundamental in order to design good gestural interfaces. What is you body capable of doing? And what not? And we should not forget ergonomics. This is important even though there is no mouse. Saffer goes into this subject rather well, describing possible limitations and pointing us on some simple, but valuable facts (10% of adults are left-handed).

Patterns for touch, interactive & free form

After the first two chapters the book dives into possible patterns for gestural interfaces. It’s an important step Saffer tries to take here: trying to define an international set of patterns. Several companies are developing gestural interfaces and are creating their own patterns, independent of each other. Some, like Apple, are even trying to patent some patterns… so it’s really important to start describing a set that is recognized by users and freely usable by any company. It would be a great step if the patterns Saffer describes would be available online, open for discussion and growth.

Documenting gestural interfaces

Documenting static websites in the 90s was pretty straight forward. But with growing interactivity and gestural interfaces it is a challenge for designers to capture the way an environment or device interacts with a user. The fifth chapter of Designing Gestural Interfaces looks into different ways to document your project. The one I like the most is drawing storyboards, encapsulating not only the interface but also the context and how the user behaves in it. It’s a great way to test for yourself if the design works, but also a superb way of presenting the concept to clients.

Prototyping

When you’re done with the sketching you want to prototype an interface. In the sixth chapter of the book you get some low- and high-fidelity ways of prototyping. Amongst the low-fidelity is the creation of paper prototypes, which I really like. It’s an easy and really fast way of making a ‘working’ version of your product. You can give it to a colleague and let him play around with it. But even playing around with it yourself is really helpful, since you will ‘feel’ and see what it does. Of course paper prototyping is not always the best solution, since gestural interfaces can also be about bigger objects or even spaces. But these are also easily prototyped. Saffer gives some nice examples of these.

Communicating

For me chapter 7 “Communicating Interactive Gestures” was one of the more interesting ones. It learned me the true importance of communicating that there are interactive gestures or not. Imagine that there are some public spaces that have gestural interfaces, and some don’t… but it’s not communicated well. This will cause real stress, since people won’t know if, when, how and what they will trigger an event. It’s really important to be clear about this, stating when there is an interaction possible… what it triggers and how. But in order to achieve this we will have to find an international language, explaining this to us. It could be something as simple as an RSS icon, but it has to be something clear.

Future

In the last chapter Saffer tries to sketch his vision for the future. Unfortunately he plays on the safe side and only describes the main trends going on in the field. So when you follow the important sites in the IxD and UX field, you are covered and can skip this chapter.

Conclusion

Before I started reading this book I thought it would dive deep into the world of gestural interfaces. But I should have known better… Since this is the first serious attempt to capture the subject it is logical that it needs to introduce us to a lot of new things. And although only the first chapter is called ‘Introducing Interactive Gestures’ I have to say that the entire book is an introduction to the subject. This doesn’t mean it doesn’t give helpful information, but it never goes into the subject deep enough to totaly cover it. This makes Designing Gestural Interfaces a great book for people new to the subject, like students. Let’s take this book as the fundament and see some new ones building upon it, going more in-depth.

Book Details
Designing Gestural Interfaces
author: Dan Saffer
publisher: O’Reilly
details: 247 pages, paperback

Chris Harrison and Scott Hudson (Carnegie Mellon University) came up with a way to use any flat surface as a gesture based input device (Scratch input). An absolute breakthrough which makes extraordinary interactions, like for example controlling your television or music player with your wooden kitchen table, possible.

Scratch input is specifically designed to use augmented existing, passive surfaces as an input device. Using a simple sensor which is sticked on the surface, the sound-waves are captured. Due the fact that every movement produces a different sound-pattern, gestures can be recognized.

Interesting about it is that in a lot of cases this will make an interface redundant. And if you do need one, you can design one that looks and feels much more natural and organic.

I could go on explaining how it works but this video does a much better job at that:

What has been explained in the video, and a bit more, can also be found in the paper they published which can be downloaded here.

Chris Harrison, is a Ph.D. student in the Human-Computer Interaction Institute at Carnegie Mellon University. Scott Hudson is a professor at the same institute where he directs the HCII PhD program.

In an attempt to save the planet (and sell more cars in the proces) Ford is working on a new type of dashboard. The company came up with the idea that drivers will become eco-drivers when they are shown what the results of their driving style is. Unfortunately they completely missed the purpose of a dashboard in the process.

The dashboard they’ve been working on is called SmartGauge. It is actually a big LCD screen that can display all kinds of information. On the display they integrated EcoGuide. This EcoGuide translates your driving style into a plant: when you drive green it shows a full-grown vine with leaves, but when you start driving bad it starts to become brown and die. This way Ford is trying to make you more aware of your driving style. It’s actually the next generation Tamagotchi, which lives or dies depending on your care.

While this may sound like a good idea, the implementation seems to fail. In a demonstration of SmartGauge it becomes clear that technology is leading, at the cost of usability. Because of the LCD screen the engineers must have thought: ‘Hey, this is a great way to pack away a lot of useless information in this car!’ Now the driver will see different screens while driving and even needs a tutorial to explain all the functions. Why is this necessary?

I personally do like the idea of EcoGuide. Not all drivers will embrace this, because they like driving fast and in bursts. But more and more people will be proud to show of that they are indeed living green. This said: wouldn’t it be cool if you could take EcoGuide outside your car. Maybe the vines can be displayed on your carkey, so that people will know how green you really are.

It has been around since 2005, but is still interesting: the Nissan Pivo Concept Car. This weird looking vehicle owns some nifty technologies, changing the way we interact with the car. One of them is the ability to turn the cabin around in the direction you are driving, making parking a pleasure. And yes, the car can drive sideways. To make this driving experience work they integrated an ‘Around View Monitor’ which constantly generates a 360-degree view of the car’s surroundings on the dashboard.

But what makes it really interesting for Johnny is the way you interact with your navigation system, audio player and other technology. At Nissan they came up with the “Magic 4″ concept, which is a new type of interface. Your hardware isn’t physically controlable anymore, but integrated in the car. Through a central display screen they can be controlled, but this display doens’t have a touchscreen or physical buttons… You simply have to point your finger at the IR system, while keeping your hands on the steering wheel. Pointing one finger will activate the first feature, while pointing three fingers will activate… the third (how surprising). And when you want to make the music louder, you simply motion your finger upwards. The display on the first Pivo was integrated directly below your windscreen, into the dashboard. While on the Pivo 2 it is a special screen again.

The dashboards of the Pivo 2 and Pivo:

While using several of our senses in day-to-day life, we’re still limited by at-most one or two in our digital life… but behind the scenes researchers are working on the answer: multimodal interaction. Multimodal interaction gives user the liberty to interact with a system via more than a single human sense (touch, speech gesture etc). It is very much different from the traditional uni-modal interface where the interaction happens through one channel throughout. Multi-modal interaction has spread its wings to accommodate a wide gamut of users with a wide variety of profiles comprising of various ages. It has also addressed the issue of accessibility and universal use. The question now remains are how far have we come and where do we go now from here.

Introduction & need of Multimodal interfaces
Remember December 9, 1968 when Douglas C. Engelbart made a first public debut of a cubical shaped block of plastic and used it for pointing and clicking? It went on to be called a mouse. Much has changed since then by the inclusion of multiple buttons on that plastic block and a scroll wheel at the center. Lasers, Bluetooth, and wireless technology rule the domain instead of the traditional wheel dancing around and getting stuck every now and then. The revolution was brought upon by the need of different interaction techniques as progress was made in the technological arena and human beings had to convey and receive data to/from the machine in multiple ways.

In the last decade or so, the human-machine interaction has become more and more intricate. This is owed to the large amount of information coming along our way via multiple channels. The ever growing knowledge and the complexity of interaction have augmented the need for new ways of communication and interaction. The so called “information deluge” has been approached by researchers via integrating perceptual capabilities such as speech, vision, lip movement recognition etc. to the system. This type of interaction has been termed as Multi-modal interaction.

In multi-modal style of interaction the system processes more than one input mode – such as speech, pen based input, touch, gestural information – in a parallel processing approach. This has given birth to a new paradigm in the world of computing and has crossed the limits of the traditional WIMP interfaces ((WIMP: Windows, Icons, Menu, Pointing Devices. An interaction style developed by XEROX and now used in all major UIs)) It has not only divided the information across multiple channels but has also allowed the human being to interact with the system in a more naturalistic kind of approach, where voice, gesture, pen based form a big part. One of the very simplest examples of such kind of system is a mobile phone which can record and react to touch, voice and tactical class of inputs.

Comparison with WIMP style interaction
The traditional WIMP interfaces have the basic premise that the information can flow in and out of the system through a single channel or an event stream. This event stream can be in the form of input (mouse, keyboard etc) where the user enters data to the system and expects a feedback, or in the form of output (voice, visual etc) when the system responds. But the channel maintains its singularity and can process information one at a time. For example, in today’s interaction the computer ignores the typed information (through a keyboard), when a mouse button is depressed.

This is very much different from a multimodal interaction where the system has multiple event streams and channels and can process information coming through various input modes acting parallel, such as those described above. For e.g in an IVR system, a user can either type of speak to navigate through the menu.

Unimodal Interaction

Multimodal Interaction

The image on the left signifies a traditional unimodal system ((http://www.tribox.org/wp-content/uploads/2007/10/telephone-rotary.jpg)) whereas the one on the right ((http://www.stereoscopy.com/news/news-archive-8-2001.html)) denotes a multi-modal interaction.

Another noticeable difference lies in the fact that when traditional WIMP interfaces reside on a single machine, multimodal systems are generally spread across multiple networks and systems which all perform their specific action like speech processing, gesture recognition etc.

History & Recent advances in Multi-modal interaction
Richard A. Bolt (Architecture Machine Group, Massachusetts Institute of Technology) first introduced the concept of multi modal interaction in 1980. His research was called “Put that there” where he demonstrated a system which processed speech and touch pad pointing performing in a parallel way.One of the several examples which he demonstrated was by giving commands to “Create a blue square there”, with the intended location of “there” being pointed by a 2 dimensional cursor mark on the screen.

Since then, many advances have been done in the way systems have changed in the way they process input. Simple mouse based and pen based inputs have been replaced by a richer way of communication by incorporating semantic information. Systems have become more complicated internally and now process dual modes of input. Keyboard and mouse based interactions have been disposed off. They have given way to lip movement recognition, gestural recognition systems and speech recognition systems.

An example of a multimodal system has been developed at AT&T labs in the form of a navigation system. ((http://www.research.att.com/~johnston/))

Photo courtesy AT&T Labs

Uses of Multimodal system
The very nature of multimodal systems has expanded the world of computing by encompassing a more diverse spectrum of users and more unfavorable usage conditions. The introduction of this type of interaction has also given a choice to the users for which modality they want to use while interacting with a system. This proves to be very helpful as users have varied preferences while interacting with the system as to how do they wish to communicate. Apart from interaction preferences, multimodal interaction has also addressed a wide variety of individual differences such as different age groups, skill sets, mother tongue, cognitive styles, sensory impairments and so on.

Example: A visually impaired person could use speech to communicate to the system. For faster responses, he/she could also use gestures.

Another very common example of multimodal interaction is seen while driving and using a mobile phone. Distracting one-self from the road ahead, and dialing a number on the mobile phone could be very dangerous. The driver instead uses voice input to dial a number by suggesting a name already stored or speaking out a whole number. The system also gives auditory feedback so the driver does not have to look at the screen.

Future Directions
So what do we learn? How soon could we expect such an interaction being a part of our daily lives? Or before that, are we even ready to adapt? Or is the technology ready to make the interaction transparent? How does usability come into picture? All these questions are being answered. Research all around the world are going on to overcome challenges which are being faced.

The current state of research has not produced robust implementations of algorithms and recognition based techniques. Further development of such interaction also involves a seamless behavior and synchronization between the input and output channels so that the user interacting does not enter a confused state. Another challenge would be to make the technology as much transparent as turning a knob of our living room. As much as the user is “aware” of the interaction, the less productive and efficient the interaction becomes.

]]> http://johnnyholland.org/2008/11/the-future-of-interaction-is-it-multimodal/feed/ 4 http://johnnyholland.org/2008/11/your-body-as-an-input-device/ http://johnnyholland.org/2008/11/your-body-as-an-input-device/#comments Wed, 05 Nov 2008 09:45:14 +0000 Jeroen van Geel http://johnnyholland.org/?p=322 Who isn’t hanging over his desk to read a text or view a picture on his computer screen? -to be [...]]]>

Who isn’t hanging over his desk to read a text or view a picture on his computer screen? -to be honost… I’m doing it right now- The movement that you make as a result is almost exclusive for this reason (viewing details). And in a world where gesture-based interfaces are top notch, we could have expected some interesting experiments.

A.o. Chris Anderson from Carnegie Mellon University initiated a research towards the possibilities to combine human behaviour with digital functions. In this the digital function is the ability to zoom on your screen. In the video below you see what it actually looks like (and/or read the paper).

Everybody knows that it will definitely become irritating if your computer starts zooming in and out depending on your position… but this research doesn’t have to result in a 1:1 implementation. It would be interesting to put the researchers in one room with a physiotherapist and an interaction/industrial designer. I think they could come up with interaction solutions that can cut back RSI.

Not only games are a healthy source for innovative interface design. Hollywood also always tries to look into the future and create impressive interfaces in their sci-fi and action movies. Most of the times the interfaces only have to look cool, and any professional would immediately spot the errors. But sometimes they are really impressive and cause jealous interaction designers, like in The Island and Majority Minority Report. A lot of these interfaces where designed by Mark Coleran. Check out what he creates

Another interface, which isn’t designed by Coleran, is the Minority Report interface. Luke Wroblewski wrote an article about this futuristic (but also realistic) interface.