HTML5 vs. Flash – The War Begins
Not surprisingly there was a lot of talk at SXSW about the iPad and what it means for content creators, designers and developers. One of the first things I noticed when attending panels related to the iPad was that sides are being chosen. Though a few people approached the design and development challenges introduced by the iPad pragmatically, most were either declaring that Flash was dead (and long live HTML5) or that the iPad was going to flop (at least in part due to its lack of support for Flash). In a way the HTML5 versus Flash debate is very much an extension of the Mac versus PC debate, which is really disappointing. It should be about the right tools for the job.
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.
Your Web Site as a Game
When I first heard someone mention using video game metaphors in web site UI design I thought of the UI common in many first person shooters, such as heads up displays and menus for managing weapons and tools inventories. But I was thinking too literal. It’s way more basic, it’s about saving the princess and leveling up. The cornerstone of using game metaphors is to provide rewards to users who accomplish certain tasks on your site. These rewards can be virtual, such as badges, medals or special titles (guru-user) or real world rewards, such as discounts, free schwag (t-shirts) or gift certificates. When users accomplish multiple tasks, they get even more. By providing rewards for tasks and sets of tasks you can encourage exploration on your site. Users will be more likely to try a feature on your site if there is an incentive, even one as small as a badge. You can also use rewards to encourage users to provide more data about themselves.
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.
Show the Value Proposition, Don’t Just State It
The summation of this post is this: Put as few obstacles between your users and your site’s functionality as possible. It sounds simple, but a lot of sites do not follow this basic rule. Largely this applies to site registration and when to require a user to register. Often sites will only offer screen shots or demos of their functionality and require users to register to get into the real experience. Let people use your site before you require them to register, let them use the tools, create some content, do whatever it is your site offers, all without the hassle of account creation. But do so in a way that lets people know that everything they create will disappear if they do not register. When a user clicks “Save”, then prompt them to register. That way users get to know first hand what the value proposition of your site is as opposed through marketing pages, demos or screen shots. They have also invested some time and energy working with your site; they will be more likely to register to save that.
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.