.net: How do you make something as inherently boring as online forms sexy?
Chris Coyier: There’s no reason a boring task has to have a boring interface. There are a lot of people working in less-than-inspiring environments and Wufoo can help make their job easier and brighten their day. The fun in Wufoo comes from obvious things, such as a child-like colour palette, a playful layout and poetic wording. It also comes from less tangible areas, such as trying to reduce frustration when doing tasks within Wufoo through a user interface that’s clear and responsive. To give proper credit here, Kevin Hale is our lead designer and co-founder, and has been crafting Wufoo’s unique style for years. I'd encourage anyone interested in learning more about this to listen to Kevin's talk about Support Driven Design.
.net: How can new HTML5 features help improve conversion rates?
CC: HTML5 has great features such as ‘placeholder’, which enables you to put a value into a field that then instantly disappears when the field comes into focus. Putting a value such as ‘555-555-5555’ into a telephone number field, for example, helps explain what you want and reduces any slight user confusion and possible form abandonment. There are also little things, such as incrementation arrows for numeric inputs, which will help users adjust fields quicker, and inline validation, which can give users feedback on what they’ve done wrong faster than server-side validation can. The quicker users are able to understand and fill out a form, the higher conversion rates will be.
.net: Which features already work and which have you implemented in Wufoo?
CC: There are millions and millions of live Wufoo forms out there, so we need to be particularly careful when we make changes to how forms look or behave. The first thing we did was a ton of research on what features work in what browsers. All that data is publicly available here: wufoo.com/html5/. Then we decided which features we could roll out that are only improvements with zero setbacks. We're marking required fields with the required attribute, using new types like URL and email, and using new elements like output where our forms perform calculations. But the truth is the biggest, juiciest features of HTML5 forms aren't ready for us to use yet. The date picker stuff, for example, is great, but there is no way to get a consistent quality user experience with that with only HTML5, so that stuff is all still JavaScript based.
.net: How do you replicate HTML5’s form features with JavaScript for progressive enhancement?
CC: Any HTML5 form enhancement can already be handled using JavaScript in a far more crossbrowser compatible way. For example, date fields have a datepicker in Opera, but we have long replicated that ability with JavaScript. It makes more sense for us to stick with that and provide a better, more consistent experience to all users for the time being. For people building their own forms, there’s no better progressive enhancement tool than Modernizr, which provides CSS class names and a JavaScript API for knowing exactly when to fire up a fall-back technique and when not to.
.net: What steps do you go through before and after you launch a new element for the user interface?
CC: In my experience so far, a feature doesn't even go into development unless 1) there is a clear demand for it 2) we think the development time is worth it 3) there aren't other more pressing features and 4) it fits the developer’s own skills and tastes. Once all those things are a match, features typically start with UI, then are passed over to be functionally developed. Sometimes these features have been "stewing" for so long that it's pretty clear what needs to get done to make it happen. One hot tip in this area: iterate, iterate, iterate. The more times you revisit something with a fresh and open mind, the tighter the concept will be.
.net: Why do even designers and developers have to answer custom support emails at Wufoo?
CC: This is really the root of Wufoo as a business. Our entire team is responsible for the site in the sense that we all have to support it. It keeps everyone very in tune with how things are working and how our customers are feeling. This means development efforts stay focused around real needs, not perceived ones. Also, if a developer has to answer a support email about something broken in the app more than once, they’re likely to just stop what they’re doing and fix it.
