Forms suck. Creating a style guide for form design is difficult.
- Christopher Schmitt – Heat Vision
- Eric Ellis – Bank of America
- Kimberly Blessing – Comcast Interactive Media
- Sunday, March 15
- web form elements research
- jquery validation
- moz monkey
The Luke W. mantra: forms stand in the way of what we want to do.
Conversations are rooted in trust. Good forms should be structured on trust. Think about people/relationships, and context. The way you speak to your users impacts their excitement/enjoyment. The way you label your forms focused on a label that makes sense to the user not just to you.
- Apparently expectation is obvious.
- Can a user look at a page in a matter of seconds and understand the pattern of interaction.
- [Managed] Noise
- Forms that are not initiated or expected; noise is anything that inhibits the user’s ability to complete the task. Marginilization over removal.
- Important things (the task) first, then the rest should be add-on. But make sure I have completed something soon.
Lead a user down a path and show them questions only if they are necessary to the context and the type of user you are (if I already know about you, don’t ask me to fill it in again).
HTML5 Form Elements
- Input date (calendar) drop-down
- Input time
Web Form Management
Forms get re-purposed most often. How can you manage all the different form purposes simplistically in a common application pattern library? An editorial style guide for web forms: how do we speak to our customer or about our services?
Pull together the people who care about standards and build a style guide from the ground up.
Client-side validation doesn’t get it all, and can expose your validation methods to DoS. Split validation between client/server: format v. required. Server-side response for validation errors at top so screen readers see it force.
These are notes from a session at sxsw interactive. My own take on topics are mixed in with what the presenters were actually saying, so do not assume all of this content is my own.