I hate the submit button. For visualizations and a lot of other applications it puts a barrier between me and the things I’m looking for.
As a user, I want my tools to react to me. I don't want to have to respond to them.Many “Interactive Tools” ask you to do too much before you can get any information from them. I know someone who had to answer between 5 and 10 multiple choice questions, each with a separate screen, each with its own submit button. 10 button presses before he could see anything. Some of the questions he didn't always have an answer for but there was no way to skip them. So instead of pushing all those buttons he just stopped using the reports.
The Edmonton Police Service's Neighborhood Crime Map shares this problem, though to a lesser extent. First I have to click the crimes I want, then I have to choose a neighborhood, then a time period and finally click Show Crimes. The first time I did this I got an error message because I forgot to select a time period. The next three times I got a blank map because the neighborhoods I was choosing didn't have any crimes yesterday. Each time I had to click that infernal Show Crimesbutton just to see a blank map. When I finally did get some crimes on the screen, I had to click that button every time I wanted add or remove a category or just change neighborhoods.
What could have made my experience better? What would facilitate the translation of the data into answers and insight? Responsiveness. Responsiveness is not just about speed. It’s about understanding what the user wants, and giving it to them right away.
The goal of a crime map is to view and understand where crime happens. If we start with the assumption that I want to see crimes (a pretty safe guess for a crime map) we can remove a lot of the things that get in the way of seeing the crimes. Why do I need to push Show Crimes? Why not start with some crimes showing and then react to the actions I take? If I check a crime to show, show it as soon as I check that box. If I move locations, show me the crimes there right away. Don't wait for me to command you to do what I've asked, do it the moment I ask. Check out Oakland Crimespotting for a crime map done right (there is a chapter in Beautiful Data that talks about the creation process).
Responsive applications are not that hard to create. It just requires a change in perspective from “how do I get what I need from the user” to “how do I give the user what they want”. While reading Kevin Mitnick's biography Ghost in the Wires, I noticed he had some puzzles at the start of each chapter, one of which is a cipher known as the Caesar Shift. I was trying to solve the puzzle by hand when it occurred to me that this is literally what computers were originally built for - cracking codes. So I built a little web tool that would allow me to decipher these puzzles. Here is the slightly prettied up version.
What makes it worth sharing is its responsiveness. Someone using this application is trying to decode or encode a Caesar shifted message. The application is already aware of this and that is why it immediately responds to any entry by the user. As soon as you start typing (or pasting) a message, it starts decoding. It doesn't wait for you to push a submit button, it already knows what you want it to do, so why make you work for it? It usually has the encryption key figured out by the second word and you can watch your nonsense characters magically turn into a real message even as your fingers are type them out.
Google is particularly good at responsiveness. They spend considerable time on speed and their efforts pay off. When you begin typing a search into their spartan home page it starts searching even before you're finished typing. No wonder we all use Google. They are using their vast data collections and army of coders to get you things a few milliseconds faster. But you don't think of it as saving just a few milliseconds, you think of it as magic. Why? Because Google can read your mind, giving you the answer before your fingers could even finish the question.