Category Archives: Innovation

Microsoft’s version of Multitouch: “Surface”

Now that everyone's waiting for the iPhone and its innovative user interface – have you seen Microsoft's product / vision video on "Surface"? It's well worthwhile … The system has been announced for public availability at the end of the year.

[youtube IqVNAnuQQyg]

Search for more videos on Surface on YouTube

But wait – there are quite a number of similarities to Jeff Han's impressive work; watch the video:

[youtube QKh1Rv0PlOQ]

Search for more videos on Jeff Han on YouTube

For those who – like me, intially 🙂 – thought Surface was a nice copy of what Jeff Han had done, you can find a very nice overview of multitouch and related projects on Bill Buxton's website. Bill tracks back the history of multitouch interfaces until 1982.

Still, the question remains: What are the use cases for such a system? With a price tag of $5.000-10.000, this will not be a PC replacement any time soon. It might also be a bit expensive for a digital photo organizer. I find the kiosk examples in the marketing videos more convincing. Still, this could be a Product Management challenge – how to position this device with its cool technology, how to identify the latent user needs that will make this an irresistible device (apart from "it demoes well", which it sure does).

Update: The Register has, as always, a biting comment on Microsoft Surface, saying

for Microsoft it's just another attempt at getting its software out from the beige boxes under our desks to somewhere, anywhere, else.

But read for yourself

Designing the (AOL Phone) Box

AOL Phone Box (small image)In August 2006, AOL Germany launched the AOL Phone Box, an AOL-branded ADSL 2+ modem / router with integrated 4-port Ethernet switch and VoIP telephony functionality. When we started working on the AOL Phone Box project more than a year ago, the AOL Germany world looked quite a bit different: AOL was one of Germany's biggest ISPs, providing a huge number of customers with fast DSL Internet access (and a big number with slower narrow-band dial-up access); the web-based products like the portal, e-mail, instant messenger offered functionality on top. Now, the access business has been sold to Telecom Italia, and AOL is turning itself into a portal player, offering free e-mail, news, and other web-based services and content. Time flies …

The project had a number of goals, apart from just creating the Box:

  • Create an Internet Access Device that is simple and straightforward to set up – in order to reduce the number of support calls (setting up the access device is a major call driver).
  • Create a compelling, appealing user experience make people want to possess the box.
  • Build up in-house expertise on how to create hardware products for future projects.

After quite a bit of research, the project team decided on working with a German manufacturer, Bautzen-based Sphairon Access Systems. Sphairon had a hardware and software platform that looked very promising, and they had lots of experience working with various telecoms – they build DSL splitters, Internet Access Devices, ISDN NTBAs and other devices needed for telephony and Internet access. We started out from an existing product, but had it completely revamped to fit our ideas of what an AOL-branded device should look like. Nuremberg-based industrial design firm B/F Design supported us here – they created innovative rough designs, did fantastic renderings and great prototypes.

The Interactive Design sub-project had a couple of tasks:

  • Revamp the existing user interface to make it fit into AOL Germany's visual design language.
  • Check and improve the user flow to achieve a higher level of usability.
  • Control and manage external development and design efforts.
  • Innovate on new features and parts of the offering.

Where we were coming from

The closest relatives to our AOL Phone Box are the members of Sphairon's line of Turbolink devices. They feature quite a versatile, extendable hardware platform, but come in a rather plain, matter-of-fact shell. The IAD shown below was presented by Sphairon at the 2005 CeBIT.

Sphairon Turbolink

Likewise, the design of the configuration web interface was a bit plain, and we felt it could be improved a bit – it had to be adapted to our visual standards anyway. We therefore adopted a visual style that mirrored our AOL Germany portal design.

How we got there

First, a new shell was developed by B/F Design. It needed to reflect AOL's brand values – Human Individuality, Top Quality, Elegant Simplicity, and Inspiring Enjoyment – and look high-class. I think they did a tremendous job.

AOL Phone Box

Reversed-engineered Information Architecture for Web FrontendIn parallel, we reversed-engineered the existing browser-based configuration front-end – we created a site map containing all the places and functionality. We then compared this site map to our list of desired features and started moving functionality around, restructuring the configuration tool's organization. After deciding which functionality should be experts-only and which should be available to all users, the IA for the web configuration was finalized and wire frames for a number of screens were created to illustrate the arrangement of elements on the UI. To get the web configuration tool to sport our visual style, we developed a visual design style guide especially for this product and delivered all the necessary assets to Sphairon, together with a couple example screens. We then moved on to defining two new parts of the AOL Phone Box experience: the "Einrichtungsassistent" (setup assistant) and the "CD-Intro" (CD-based introduction to the product). The customers should use the CD-based introduction to get the cabling right; once everything had been connected properly, the setup assistant (resident on the hardware) should take over and lead the user through the basic configuration of the product. To the user, this two-platforms approach should feel like one seamless process. During the interaction design process, we especially focused on possible error conditions: We analyzed them and either tried to circumvent them, or we used them to help users identify what might have been the cause of their issues and to help them out (again, a way to reduce Call Center volume and thus cost).Extremely close collaboration in the team and with our development partner Sphairon helped us make great progress, and we took great pride in seeing our ideas get realized and the designs getting closer and closer to what we had envisioned.

Design and Usability Evaluation

After some time of working on a project, you lose the ability to actually assess a solution's quality. So, at two points in the development cycle, we conducted usability evaluation measures with our partner HCiconsult. Early on (with a rough version of the UI in place), a heuristic evaluation was done. Later, when the development was 2/3 complete, we had a usability test conducted with seven test participants. Both measures showed we were on the right track, but of course there was still room for improvement. The findings were discussed and incorporated into the design iterations.

When we started to think about packaging and printed material, we realized that it would be highly desirable to provide a consistent wording throughout all materials – be them on the configuration UI of the box, on the CD, on the packaging or on leaflets. So we provided the necessary wording and operated as wording QA for the electronic manual. While this was quite an extra work package, it nicely followed the philosophy of an end-to-end design responsibility.

AOL Phone Box packaging

A challenging and rewarding project

In the end, the Interactive Design team had contributed in the following domains: For Interaction Design, we had contributed Information Architecture, user flows, and screen layouts. As for Graphics Design, we had created Visual design standards and provided the graphics assets for the development partner. Wording of all customer-facing texts including Web Interface, packaging, and manual had been provided by us. We had had our say in the design of the packaging, and of course there had been the final sign-off of all materials by the Director Interactive Design.

The AOL Phone Box has proved to be quite a success. The expected benefits were realized, the customers love it, and we have not only delivered a fantastic product, but also learned a lot – and had quite a bit of fun.

AppleTV vs. MS Home Server – some thoughts

Last week at CES in Las Vegas, Bill Gates announced to-be-released Windows Home Server, and a day later, Steve Jobs showed Apple TV. Both products aim at solving the same issue: how to get media files that are on different devices, hard disks etc. onto one terminal (i.e., the TV). Interestingly enough, the two solutions are vastly different:

  • Windows Home Server, which is based on Windows Server 2003, will replicate media files from all computers, XBoxes, and Zunes on the local network onto its hard drive and play them from there so that it won’t matter whether the PCs are running. The machine running Windows Home Server can be operated headlessly (no display) and will be wired (Ethernet). The software will be administered from a separate machine using Windows Home Server Console. Ideally, the devices would be between $400 and $500.
  • Apple TV, which will be $299, takes a different approach. Although it features a 40GB hard drive and can be synced to one computer through iTunes (like an iPod), it can stream media files from five computers on the network – wirelessly, using the (non-final) 802.11n standard; i.e. the media files themselves are not replicated. Videos can also be bought through the iTunes Music Store.

Let’s see who has done the user research properly – I personally don’t think consumers want another PC in their homes just to watch their videos, and few people actually need a home server (we got rid of ours years ago). Apple might have done a very good job disguising their newest computer.

Update: There’s a nice article on Ars Technica: more details about Windows Home Server. Author Jeremy Reimer basically asks the same questions:

It’s a neat idea, but how many home users will want to shell out the cost of a separate server for their media files? It’s already possible to use the regular versions of Windows as servers in limited form through Windows File Sharing, and some might balk at dedicating an entire computer for this task alone. Others might argue that it would be cheaper to set up a dedicated server with older components and by installing a free operating system such as Linux. Where Microsoft can overcome these objections is by making the operating system affordable and by making these sorts of “home admin” tasks much easier than they have been before.

The iPhone is here

You'll all have heard about it – Steve Jobs of Apple Inc. (no more "Apple Computers Inc.") has demonstrated the upcoming iPhone, to be released in June 07 in the US (in Q4 in Europe, in Asia probably 2008). The iPhone features just one button ("Home"), a giant touch-sensitive screen with "Multi touch" abilities and runs a (probably stripped-down) version of Mac OS X (although Apple's marketing pages refer to it just as "OS X").

I've been using Handspring's (and later palmOne's) Treos for nearly four years now. I've been very happy with them: they allowed me to reduce the number of devices from two to one (from a mobile phone and a PDA to just one smartphone). Nevertheless, Palm OS seems to have got stuck in development somewhere – no multitasking, slow, syncing actually only works properly with Windows … and I won't go for a Windows Mobile device. Moreover, although Handspring (and later Palm) have done a tremendous job of integrating phone functionality into an OS that had not been designed with this intent in mind, the Treo still feels like a PDA with add-on phone functionality. And I'd love to have my iTunes music with me as well (which cannot be played from the Treo; and even playing non-DRMed music from the Treo isn't much fun).

So again I'm stuck with two devices – the Treo and an 80 GB 5th generation iPod. Moreover, I recently began to heavily use the mobile Internet on my Treo's Blazer browser. It works, kind of … but it's not exactly fun. This is why I will definitely have to get one of Apple's new gizmos. Not only because I've got that Early Adopter virus(TM), because I'm an Apple aficionado and fascinated by all new technology, but because this thing appears to have been designed to serve the following purposes perfectly:

  • making calls
  • listening to music
  • browsing the web
  • reading and writing e-mails

… and I believe that at some points you just have to start from scratch again, drop bloated approaches covered with "scar tissue" (Alan Cooper) and held together with band-aids, and go out and try new ideas based on what people actually need and want to do. (The mobile phone industry appears rather help- and clueless as to what to offer their customers as most people don't seem to be willing to use all the cool features in their phones.)

Oh, and another thing: In "The Invisible Computer", Don Norman argues that the future will provide us with lots and lots of specialized devices – one for each purpose. I guess he was wrong Smile I'm very much looking forward to actually test-driving one of these things, to see whether Apple's new product can live up to the promise. Have they really re-invented the phone? At least they've got a lot of attention and shaken up the industry quite a bit (again).

Update: Bruce "Tog" Tognazzini has put together a very nice and detailed analysis of the iPhone's strenghts and weaknesses (as far as can be seen from the available material). Definitely worth a read!

Using User Interface Patterns as a Design Framework

Design Frameworks in UI Design have come some way. Starting out as conventions amongst designers, then platform standards or standards across a number of platforms, to a written-down and agreed-upon set of guidelines, we have arrived at pattern libraries. Just recently Yahoo! released their UI pattern library to the public, allowing designers to profit from their research and development effort. Design Frameworks not only offer guidance as to how to design things so that a certain level of consistency is achieved. Their real power lies in structuring the way designers think about their domain and the tasks their users are doing: They can be used as tools for requirements engineering as well. But some hindrances need to be overcome.

What are Patterns?

The idea of patterns originated in architecture with Christopher Alexander's 1977 book "A Pattern Language". Alexander noticed that certain design problems kept occurring in different contexts but afforded a relatively small number of similar solutions. So he created the idea of patterns as the optimal solution to a given question in architecture. It could deal with a room, a building, a street, a town, or some transportation infrastructure. Alexander identified and described a set of design patterns and a "pattern language" that described the interrelationship between the patterns. Later, the idea was adopted in User Interface Design, and Martijn van Welie and Jenifer Tidwell started researching and publishing design pattern libraries for user interfaces for PCs; later these were expanded to cover different devices.

It is important to understand what patterns are not: patterns are not single interaction elements (or controls). They are not solutions to simple problems like "select one element from a list". They are parameter-sensitive sets of controls, interacting with each other on a given input and creating a certain output. Their aim is to support one specific design problem. Use Cases are one way of stating design problems. Basically, design patterns can be defined as optimal solutions to a given abstract use case, and a design pattern in context (i.e. with the right input and output parameters) represents the design solution to a specific use case.

Just as Christopher Alexander set up a number of patterns and defined a pattern language, a pattern-based design approach requires a basic set of patterns to choose from. Your pattern library is the toolbox you need to build your applications from. So, how do you create a pattern library?

Creating a Pattern Library

A pattern library needs to have a critical mass, to contain a certain number of patterns to work. It's useless to start with too small a number of patterns because you will end up trying to "squeeze" your applications, to fit your requirements to the patterns. That's not sensible. You should have patterns for all major places in your apps. E.g., in business applications, you'd need at least one list pattern and one framework / container pattern for actually viewing / editing business objects. Within the editing container pattern, you'd most certainly use different patterns for applying actions to the object. These patterns need to be there in different flavors to provide notifications (like success or failure messages).

Defining a pattern library is not really a democratic process. There needs to be a group in charge of the pattern library, and their task is to document patterns, evaluate requests for new patterns, and keep the number of patterns low. A high number of patterns not only increases design ambiguity and waters down the guiding power of patterns, but also increases maintenance effort. Therefore, all patterns should go through this central group to be approved.

The best way to arrive at a sufficient number of patterns is to take a close look at some exemplary applications. Abstract the use cases and activities undertaken in these apps from the actual design solutions. Out of the number of use cases, a limited number of recurring activities will emerge. Based on your industry, your users will mostly edit business objects, browse image libraries, request information on articles, or search huge databases of information. Within each of these domains, only a limited number of sufficiently different activities exist. For each of these core activities (i.e., for each of these design problems) an optimal design solution can be found. Try to identify the solution or solutions that are applicable to most or (if possible) all your use cases. Draft and iterate it until a somewhat stable solution emerges. This is your first pattern. Write it up on a Pattern Card, describing the design problem, the usage context, constraints, dos and don'ts. Then move on to the next pattern until you think you've covered most cases. Then go back into actual application design and re-design your apps, incorporating your newly-defined patterns

as you go. You will undoubtedly encounter numerous cases where your patterns don't fit as well as they should. Document these cases, but try to keep the number of patterns low for the first iteration. Once you're through with your apps, go back to the drawing board and re-evaluate your work from a certain distance. Think about the difficult cases – do they warrant new patterns, or can the existing patterns be extended to satisfy the newly discovered needs and requirements?

Once you've arrived at a stable number of patterns, you can go the next step: get the design patterns wrapped in code so that you end up with a number of components. Believe me, it's easier to start later, once the requirements and flavors of the patterns are clear and been through at least one iteration. Now it's time to profit from the work you've invested.

Harvesting the Crop

As soon as you've got design patterns and components – their equivalent in code –, you can benefit from your previous work: You'll realize how much patterns speed up the process of product definition and development. On the way, you'll notice that you've changed a number of job descriptions: UI design is changed from creating specific solutions to every problem anew to rather analyzing the use cases and identifying the most appropriate patterns for the problem at hand, including the right flavor of a given pattern and well as connecting the patterns in screen flows. Visual design will be freed from tactical day-to-day business to pursue more strategic design approaches. And development's tasks change from creating new solutions over and over again to configuring the existing patterns, wiring together the solutions, and create new and even better patterns. (Basically, given a Business Process Design Time suitable for end-users, business architects can be empowered to plug together basic applications from the patterns – as described in Dan Wood's 2003 books "Packaged Composite Applications" and "Enterprise Services Architecture".)

So, adopting a pattern-based design approach not only changes the processes of product definition, design, and development, but also the responsibilities within the development organization. Change Management should be involved in every step to avoid rising levels of frustrations in a great number of departments.

Once you start using your pattern library as a framework for requirements gathering it gets really interesting. As your pattern library contains the boiled-down interaction design approaches about your design problem domain, you can create standardized interview guidelines using the patterns to structure your interviewees' responses. For example, if your pattern library contains a pattern "list of business objects that I must work on" and one pattern "overall list of business objects with advanced filter mechanism", your interview could touch questions like:

  • Do you have a list of things you need to do – are there objects you get at certain times and need to work on, and once you're finished with them, they can disappear from the list? Which ones? The objects mentioned now should be part of the "list of business objects that I must work on" pattern.
  • Do you need to access objects regardless of whether they are new, in progress, or done? Which ones? What are the criteria you use to find the relevant object quickly? These objects would be part of the "overall list of business objects", and the "advanced filter mechanism" can be parametrized according to the answers, too.

With the right set of questions, you can cover all your patterns and understand how they need to be set up to meet the users' requirements. But don't forget to listen for any hints at things missing, ideas and concepts not covered, or elements rather "squeezed into" the design system your patterns represent. It is possible (and, at first, quite probable) that you will learn that your patterns don't quite fit, that a new flavor or even a new pattern is needed. A pattern library is a living structure that will evolve over time, and so will your design thinking.

So, you might ask, where will this lead us? Once we have a pattern library in place, once we've streamlined our UI design and application development approach, what next? Let's take a look into one possible future.

Vision: Towards a competition of components

Apple's Mac OS X Automator.

Imagine a computing world that has got rid of monolithic applications – on the desktop, on the servers, everywhere. For every purpose, the best possible component can be chosen and just plugged into a framework supporting and living open standards. "Application development" means: business experts define the processes, and business architects select the appropriate components and parameters, following an approach as described above. Using an application design time much like Apple's Automator, elements can be plugged together and auto-negotiate their interfaces and data exchanges.

Part of this is true already. SAP's NetWeaver platform is the first to use the term "applistructure", a Forrester Research-coined term for the convergence of "application" and "infrastructure". And SAP is not the only one on the market with a comparable offering for enterprise software. But on the desktop, much remains to be done. A concept for a basically document-centric approach to desktop computing was presented by Jef Raskin in his book "The Humane Interface", contrasting it to the current (well, 20+ years old) "application-centric" approach. Raskin asks: Why force people to buy an office suite that is poorly integrated when they could rather buy the components they need – a text editor, a chart drawing component, etc. (Well, Apple tried to introduce this approach as "OpenDoc" in System 7.5 to 8.1, unfortunately, rather halfheartedly, and then killed it.) It would be up to the OS manufacturers to provide the necessary infrastructure. And it would be up to a great number of small software companies (Independent Software Vendors) to compete for the best possible components available for a given user need. This would create a whole new momentum on the market, out of which everyone would benefit – well, maybe everyone except for the companies producing office suites right now. But then, why not prove they've got all the experience to create the best competitive components?

And the fascinating thing is: It's started to happen on the Web already. Basically, all the Web2.0 hype is about people composing their "information and application cockpits" tailored to their needs, based on an open infrastructure and publicly available components. And I guess that's just the beginning.

Next-gen Desktop object manipulation metaphors

Just stumbled across a phantastic prototype video (the BumpTop 3D Desktop Prototype) by the Digital Graphics Project at the University of Toronto that’s illustrating some cool new interaction techniques for desktop object manipulation. It’s building on the idea of Piles (that’s an older concept Apple still holds the patent on) and using gestures to manipulate files (or their representations as icons, resp.) on a high-fidelity desktop environment. Object behavior like momentum, acceleration etc. is simulated through a physics engine much like the engines built into newer Ego Shooter games.

BumpTop Desktop Prototype

What I’d love to see in addition is the Wear and Tear concept – objects that have not been touched for some time start showing signs of age, get wrinkled etc.While I quite enjoy the great graphics and the cool ideas behind the demo, I think it doesn’t solve the problems inherent in the Desktop metaphor – like: limiting our approach to object manipulation by what we assume is possible on desktops with real objects etc. The other drawback I see is that manipulating objects in this environment might be so much fun that actually working with the objects becomes a boring chore :-)What’s cool as well about this is using YouTube to distribute your ideas. What a great medium to use! The traditional approach would have been to present this at some conference where it would have been seen by a small number of experts … now it’s out in the field!

IDEO’s Tim Brown on Design Innovation

The Business Innovation Insider features an excerpt from a talk by IDEO‘s Tim Brown. When I saw Tim on stage at the 2004 CHI, I was deeply impressed ? his enthusiasm and presence made his talk a highly memorizable experience. And, obviously, so was SAP’s Hasso Plattner when he first met the IDEO people and later decided to put $35m into Stanford’s D.School. Tim Brown’s talk can be viewed on the MIT World website.
According to Brown, design is everywhere around us – on the covers of business magazines, as part of consumer experiences at companies like Nike and Apple, and increasingly mentioned by Fortune 500 executives as an important way to grow a business. For many companies, design thinking is a way to create the future.
And right they are. Innovation doesn’t happen by accident. Someone must drive it.

Interactive prototyping: OpenLaszlo and Dojo Toolkit

Just recently a friend (Lars Grunewaldt) made me aware of the OpenLaszlo environment. It’s an open (and free) XML-to-DHTML / XML-to-Flash environment that comes prepackaged with a tutorial, example apps and a simple IDE. (At least) on the Mac, there’s an installer package that contains everything to be up and running in a minute.

It’s fascinating to see things in the browser coming to life. Life resizing, smooth animation, drag’n’drop, sound effects – you name it. And it’s fairly easy to create new little apps or modify the exisiting ones.

Another very cool thing is the Dojo Toolkit. It’s a set of Javascripts creating all the nice Ajax behaviors. Fascinating. And best of all: it’s all free!

So: Looks like real interactive prototyping has just come one step closer. Still need to evaluate these tools’ utility on a day-by-day basis.

I remember (just one and a half years ago) getting looked at suspiciously in a meeting with front-end developers when I requested drag-and-drop for our front-end technology (I had quite a number of reasonable use cases to strenghten my request). I wouldn’t be laughted at anymore, I guess. Finally things are getting moving.