Gaming and Application Development
I ran across this article (and most specifically this excerpt) in my RSS reader this afternoon:
“Now an entire generation has grown up with a different set of games than any before it. The last thing they do is read the manual. Instead, they pick up the controller and start mashing buttons to see what happens. This isn’t a random process; it’s the essence of the scientific method and it’s a fundamentally different take on problem-solving than the linear, read-the-manual-first approach of their parents. The fact that they are learning in a totally new way – means they’ll treat the world as a place for creation, not consumption.” – Dream Machines
I really resonated with this, because I myself am very much someone they are describing. I don’t read manuals (unless it’s really really complicated-looking), I just pick it up and start mashing buttons. That posed problems when I purchased my new table saw, but that’s another story…
When it comes to application design/development, my own tendancies force me to lean heavily towards an application design that seeks to be intuitive, and works well for people who like to “see what happens”. I want descriptive text that is simple and offers enough information that I get the gist of what will happen if I click the button/menu/link, but I still have to click to find out details, or to watch it work. I want logically grouped options, I want to drill-down as far as I want to go, and then pop back out. I don’t want any single action to initiate a never-ending action that has a <gasp>progress bar!</gasp>. (Unless I’m installing something, then I never want to touch it after it starts.) I always want the option to cancel, save, or apply my changes at any moment.
The way I figure it, what I want is what users of my applications will want (on some level) and what I enjoy about a well-designed application is what my users will enjoy also.
via Functioning Form