Thinking differently about application design

The theme for the 2008 AUSOUG Conference series was "Oracle Software from a User's Perspective". While you could infer focus on the end user from some of the presentations, it's sometimes a difficult theme to focus on, especially when you're writing a technically heavy paper. It's more like relating yourself to your second cousin once removed (unless of course I've missed the point and we're talking about the developer/DBA as the user of Oracle development tools.)

This doesn't mean we can't maintain our awareness for our ultimate customer - the end user.

Tom Kyte recently linked to a cartoon that painted 1000 words about the way we write applications. (Thanks Eric Burke.) We've all been on projects where screens look like this, and considering we write GUI applications for databases that contain structures like this, it's an interface that's inevitable. The same reason the 747 cockpit contains 1000+ knobs and switches.

However, we can still look for opportunities to simplify. The interface to Apple's iPod - iTunes isn't exactly a dummy user's delight. There are plenty of options and interface difficulties. They've just transferred the complexity away from the entry point for 90% of the music player's use.

So what about your application. Are there points of entry that result in a large percentage of use? Is there a way to simplify the entry of key units of data? To go even more granular, are there little smarts you can add to certain types of fields, such as dates? Are there ways to minimise use of the mouse at all times? Is the first key field of your entry form user/time/context aware?

Many considerations to make. I read a lot of blogs, and I admit many of them are certainly from a technical perspective on the database, but there are a few I subscribe to that aren't even software related - but still pertain to my job. In the same way that Microsoft employ psychologists to assist with the design of the menu structure and interfaces to their ubiquitous applications such as Word & Excel, I read some blogs that encourage thinking outside the square.

One such article I came across recently was from Seth Godin - The End of Dumb Software. I can't remember where I first stumbled across his blog, but he always has interesting perspectives as a marketer that I can either apply within my job as a database developer, or even utilise in day to day life.

He was having a gripe in particular about simple calendar applications. If 2 o'clock was selected, you'd have to presume 999 times out of 1000 that 2pm would be requested. So why is that not the default? Why can't a calendar application presume most dates used are within working hours, with the option to change if required. He goes on to suggest he shouldn't need to "edit" an event to view further details, though I understand the architect's potential thinking in that scenario.

There are plenty of other quick examples he runs through that I think all developers, architects, designers should read through and consider. How many LOVs, search windows, entry points of various kinds have you created that could have been written slightly differently to save the end user some time & frustration?

A simple example I can think of in a forms application I once worked on was the ability to enter the letter "t" in a date field to represent (and be automatically translated into on when-item-validated) today's date. How many times in your application may the user want to enter today's date? Turning it into 1 keystroke has saved between 5 and 10 keystrokes, depending on date format settings (310809 to 31-AUG-2009). One keystroke vs eleven? I know what I'd prefer.

Food for thought.

If you have other blogs in your RSS feed like Seth Godin, I'd be interested to hear about them.