In all likelihood both HTML5 and Flash will coexist for years to come. Though there is a lot of overlap in what each can do, both have their strengths and weaknesses. HTML5 does not require a third party plug-in, it’s an open standard which anyone can create development tools for, and it has huge support on mobile platforms. Flash has the benefit being an established platform with solid development tools and existing UI and development libraries to draw from. It also handles video more seamlessly than HTML5, which as of yet does not have a standard video codec defined, meaning there is no standard way of compressing video for HTML5 (there is a heated debate going on which codec should be used and no resolution is in site.)

What the HTML5 versus Flash argument amounts to is that, in spite of the dreams of graceful degradation and cross browser compatibility, designers and developers are going to have to design and develop for specific platforms. Ultimately this is not a bad thing, in fact from a design perspective, it’s a really good thing. There is a widening spectrum of net enabled devices that include desktops, laptops, tablets and smart-phones. Each device has its own set of strengths and weaknesses, its own set of constraints and limitations. Designing variations of one user experience for all devices will result in an ideal experience for one device and a compromised experience on all the others.

One of the most used examples of game metaphors in web UI design that I heard referred to at SXSW was also the subtlest, linkedIn’s profile progress bar. This progress bar is persistent on a user’s profile and informs him or her of what percent “complete” their profile is. The reward is the warm, fuzzy feeling users get when their profile reaches 100%, the sense of completion and accomplishment.

More obvious uses of game metaphors are used in both Gowalla and Foursquare, which are location aware social networking apps for smart-phones. When users visit a real world location they can “Check In”, or post their location to their status along with an optional short message. Users of both these apps get badges/stamps for visiting real world locations and can even get discounts or gift certificates for visiting a series of locations.

Another point about registration that was raised in several panels was do not require users to provide a lot of data during registration. Many sites ask for way too much info during the account creation process. Even if only a few of the fields are required, they are a perceived barrier to the user. Ideally a registration form should consist fields for email address and password and not much more. There are ways of encouraging users to provide more data after registration. More on that when I discuss video game metaphors in web site UI design.

Though it looks pretty simple, the technology behind the iKat opens up a lot of possibilities for augmented reality apps. The technology allows a phone to recognize spaces in 3D and add virtual objects into them in realtime, which could be used to show directions in perspective, play games based on your local environment, and everything in between.

TechCrunch has a somewhat related article, In Mobile, Fragmentation is Forever. Deal With It. With new platforms and OS’s come new design and development challenges. Graceful degradation of the user experience, which never worked well to begin with, won’t cut it when you have many, many levels of degradation to support. User experiences will have to be more specific to a platform. And the fragmented nature of devices outside of the conventional PC will likely not go away.

I remember way back in 1999 observing my first user test, I was working for frog design on a web site for a large direct sales computer manufacturer. The client had taken it upon themselves to hire a third party to conduct user testing on the site which frog, in collaboration with the client’s own web team, had just launched. It was both awesome and horrifying to see users actually using that which we had created. Some of our design decisions succeeded exactly as we thought they would while some, that we had thought were pretty simple and straight forward, baffled users to a point where they could not complete necessary tasks. The whole experience was very enlightening.

When I got back from user testing I talked to one of the managers at frog about user testing and asked why frog didn’t as a matter of process include it in their projects. I was told that frog doesn’t do user testing. Period. The argument against it was users often do not respond well to new or innovative ideas (and frog had built its reputation on new and innovative ideas.) New or innovative work will rarely test well, thus negating the relevance of user testing.

Since I left frog I’ve heard that they have changed this policy (if it ever was an official policy, rather than just a general stance by the management.) And since I’ve left frog I’ve gotten to work with a lot of user experience professionals. Some of which have insisted that everything be tested. Every decision should be in some way be run by users. I’ve seen the User Centered Design methodology be taken to great lengths, where paper prototypes, then wireframes, then design comps, then the finished site are tested revised and retested until the data shows what the usability experts are looking for. If a user does not figure it out on the first try, it’s a fail.

I’ve also worked with user experience professionals who have demonstrated that there are ways to test innovative ideas and that not all data from user tests should be taken at face value. Just because someone doesn’t figure something out on the first try doesn’t always make it wrong. Sometimes it’s when a user doesn’t figure it out on the second or third try that it means something is wrong, and the fact that the user found something compelling enough to try to use it multiple times should be given some weight. Innovative ideas introduce a learning curve, it’s whether or not users are willing to overcome the learning curve that should be paid attention to.

Designers should always listen to their users. Designers should really listen to everyone, you never know where a good idea might come from. But being a good designer means knowing which ideas to use and which feedback to listen to. Good designers also know when to take a risk and try something new and when to stick to convention. My own philosophy on the subject is based on a quote from Charles and Ray Eames, “Innovate as a last resort.” If an method exists that users are familiar with, use it. Use it unless you think you’ve really got something new that works, and when you do, test it. And if no one gets it in testing, weigh the costs versus benefits before going forward anyway.