In response to your post on BOS I had a look at this.
My initial reaction was – WTF however I squinted quite hard and figured out that it was supposed to be a pit that contained a problem and I needed to get to the chest of gold by solving the problem using one of 4 GUI’s to get there.
In my case, I hope my software falls into the top left scenario however if it doesn’t then it should. If it can’t fit there immediately then I need a good help system to quickly show me the way.
Using the 4 images and it’s construction, then as a ‘test’ to make a critique of it’s user design then I believe it rates the lower left scenario for one simple reason. That reason – there’s no figgin’ one line hint to click on the image to see a larger version that you can actually read what you have cramped into the side of the bridge !!!!!
Glen,
thanks for the in-depth analysis
My key idea was “Interface must be invisible to user, like a bridge. Once an interface gets “visible” users start thinking about interface not about a goal. “
I came here from BOS too. I don’t know what the above poster is talking about. I liked your sketches. Going left to right, top to bottom as 1 to 4, your 1st pic explains what is really needed, 2nd explains what many software companies end up doing with feature overload (perhaps to be differentiators, perhaps to solve the problem generically for all customers and some internal ego, lack of knowledge in the domain space etc) but unfortunately end up with the 3rd one, except a few like projects which end up in 4 and get shelved out. Good one!
This blog is about information management, documentation, user assistance, usability, and software business in common.
We write about how to make good software, how to sell and position your software, how to support your software products, and how to manage your software business.