Note to readers who might misunderstand: the above posts (parent and parent parent) are trolls. The only thing worse than dialog boxes are attention whore dialog boxes with poor writing. The user does not want to read your stupid dialog box because they should not have to read your stupid dialog box.
If you use an exclamation point, you incite the user to anger; if your message cannot be perfectly understood every time by every person with a quick skim at 30% attention, they will click a random button because they have better shit to do than read the stupid dialog box that you put there because you couldn't be bothered to come up with a sensible design.
The user has a job to do. They want to do that job. Your job is to help them do their job and make the computer disappear, not remind them that they are using yet another piece of shitty code in a shitty program on a shitty and infested piece of junk that they would destroy with a baseball bat, like that guy in Office Space, if they could do it without getting fired.
The title and content of the post state that, if the UI is terrible, then it was (probably) created by a programmer. They do not say the converse, nor does the converse automatically follow (the converse being: if the UI was created by a programmer, then it is terrible).
I agree he's got the wrong words, I think he is a programmer, but the author is probably writing this from first hand experience. I think he is saying if you're getting a developer to develop a UI for you, you better make sure they're able to design, even a little.
It would be foolish to think all programmers cannot design.
"I’ve been responsible for doing at least one of these things myself over the years. Consider this post repentance for my user interface sins."
Anyway, the whole post misses the point. Choosing the exact wording of dialog boxes and creating icons are not the responsibilities of programmers working on large projects. If programmers have to take on these tasks, the either the company doesn't have a clue, or they can't afford to hire UI experts, graphic desginers, etc.
I can imagine that there would be some UI mistakes a programmer would make which a non-technical person wouldn't, but I don't think this applies to any of the items in his list.
Yes, I'm sure if this were an article on the symptoms of a python-programmer-designed UI it would be different. I had to learn VB.NET in school, it almost encourages bad design.
I think he means anyone who believe that a power user will use Emacs and the command-line and so believes that things like tab order, hot-keys and time-saving in general are of no importance in a GUI.
I have seen many skilled programmers and sys admins with this kind of belief system. The programmers would gleefully produce the kind of dreck which this article describes since they basically think of the end-users as sheep to be herded and occasionally abused.
The ability of produce code and an understanding of GUI standards are two different things.
This certainly isn't a Windows-only-problem. I currently use only Ubuntu/gnome and despite the fact that I've been able to customize it heavily for my purposes, the GUI just reeks of those who don't a sh*t about the GUI user's efficiency.
Every GUI app should provide minimum path from any state of the program to any other state that uses only the keyboard, doesn't flash the screen and requires a minimal number of strokes - and ideally records the keystrokes and lets you play them back. Does this sound unrealiistic or like something a novice wouldn't care about? This exactly what a web browser allows people to do with the address bar.
Personally, I took the article as a warning against the common pitfalls of basic UI design. I felt that it covered several ui issues that are very prevalent in programs today (the excessive use of dialog boxes really hit it home for me) and that the author was simply pointing these issues out and giving a designer's perspective on them to help programmers avoid them. Not all of us (programmers) get guidance in UI design so I definitely see where he is coming from.
He missed the case where verbs in the UI match the model of data within the program and not a normal user's mental model. Git, powerful and amazing and awesome and mind blowing and game changing as it is, is a prominent example.
Cooper first writes something we all like to hear: programmers actually control the fate of most high tech businesses. But then he makes a compelling argument that we're really horrible at what we do.
The ideas in this book are difficult to swallow, but once I got past my own ego I learned a lot from it. Not every programmer is a design idiot, but most of us are. Good design requires study and training. Intuition alone only gets you halfway there (unless you're Steve Jobs, and he's not a developer).
Ted Nelson talked about being trapped by the programmers retarded ideas for systems back in the 70s/80s. He said that the system designers didn't give enough thought to the user interface and instead forced users to comply with some rigid inconvenient standard all the while saying, "This is how the computer wants your data entered".
Also...Steve Jobs is a pleb when it comes to good design.
I've known really great programmers to commit all of these sins. There are different abilities and types of mental focus at work here.
I don't think it's unfair to say a good app will have programmers separate from writers and interface designers, much as a rock band has a different dude on drums and guitar.
The real culprit, if you get an application like this, is management. Your manager did not put together a team but farmed the project out to a single programmer and probably underpaid him. I avoid such jobs and the code they produce whenever possible!
This might be more of a comment on the state of available tools, than the habits of programmers.
While some programmers will have the passion to make great UIs no matter how difficult or tedious the code becomes, a lot will simply find the first thing that gives them the results they need. (In fact, even when their end goal is to make something nice, they may still start with something ugly to make sure that everything else is working.)
There's really only two ways to solve that: give them more time to ship and make "great UI" a clear deliverable (that they're paid for), or give them better tools and expect correspondingly-better results in the time originally allotted.
Assuming your company isn't producing just one product, it's usually wiser to invest in the programming tools. That way, you pay most of the cost once, during development and perfection of the tools, instead of having every single product pay a penalty as programmers and QA have to correct cosmetic and behavioral imperfections in the UI in 1000 places.
Take Interface Builder and Cocoa on Mac OS X. The design of the layout tool, combined with the unapologetic adherence to MVC and KVC design principles in the API, means that interfaces are easier to do elegantly than inelegantly. So it should come as no surprise that the resulting programs, relative to the amount of time spent, tend to be more functional and easier to use compared to equivalents on competing platforms.
On the web, "5. Data Grids" becomes "uses tables excessively".
These tables may extend off the screen horizontally; have unnecessary grid lines or alternating shading; waste massive amounts of whitespace for varied-length cell values; and include form controls that only take effect with some submit button several scroll-pages away.
23 comments
[ 1.2 ms ] story [ 54.7 ms ] threadIf you use an exclamation point, you incite the user to anger; if your message cannot be perfectly understood every time by every person with a quick skim at 30% attention, they will click a random button because they have better shit to do than read the stupid dialog box that you put there because you couldn't be bothered to come up with a sensible design.
The user has a job to do. They want to do that job. Your job is to help them do their job and make the computer disappear, not remind them that they are using yet another piece of shitty code in a shitty program on a shitty and infested piece of junk that they would destroy with a baseball bat, like that guy in Office Space, if they could do it without getting fired.
The title of this post implies that if you're a programmer automatically you are a poor user interface designer.
To me this is offensive to both programmers and designers.
These are just narrow-minded stereotypes, perpetuated by narrow-minded people.
It would be foolish to think all programmers cannot design.
Yes, he is a programmer:
http://www.voyce.com/index.php/about-2/
Yes, he is speaking from experience:
"I’ve been responsible for doing at least one of these things myself over the years. Consider this post repentance for my user interface sins."
Anyway, the whole post misses the point. Choosing the exact wording of dialog boxes and creating icons are not the responsibilities of programmers working on large projects. If programmers have to take on these tasks, the either the company doesn't have a clue, or they can't afford to hire UI experts, graphic desginers, etc.
I can imagine that there would be some UI mistakes a programmer would make which a non-technical person wouldn't, but I don't think this applies to any of the items in his list.
I think he means anyone who believe that a power user will use Emacs and the command-line and so believes that things like tab order, hot-keys and time-saving in general are of no importance in a GUI.
I have seen many skilled programmers and sys admins with this kind of belief system. The programmers would gleefully produce the kind of dreck which this article describes since they basically think of the end-users as sheep to be herded and occasionally abused.
The ability of produce code and an understanding of GUI standards are two different things.
This certainly isn't a Windows-only-problem. I currently use only Ubuntu/gnome and despite the fact that I've been able to customize it heavily for my purposes, the GUI just reeks of those who don't a sh*t about the GUI user's efficiency.
Every GUI app should provide minimum path from any state of the program to any other state that uses only the keyboard, doesn't flash the screen and requires a minimal number of strokes - and ideally records the keystrokes and lets you play them back. Does this sound unrealiistic or like something a novice wouldn't care about? This exactly what a web browser allows people to do with the address bar.
But then, off-by-one is the canonical programming error.
Cooper first writes something we all like to hear: programmers actually control the fate of most high tech businesses. But then he makes a compelling argument that we're really horrible at what we do.
The ideas in this book are difficult to swallow, but once I got past my own ego I learned a lot from it. Not every programmer is a design idiot, but most of us are. Good design requires study and training. Intuition alone only gets you halfway there (unless you're Steve Jobs, and he's not a developer).
Ted Nelson talked about being trapped by the programmers retarded ideas for systems back in the 70s/80s. He said that the system designers didn't give enough thought to the user interface and instead forced users to comply with some rigid inconvenient standard all the while saying, "This is how the computer wants your data entered".
Also...Steve Jobs is a pleb when it comes to good design.
I don't think it's unfair to say a good app will have programmers separate from writers and interface designers, much as a rock band has a different dude on drums and guitar.
The real culprit, if you get an application like this, is management. Your manager did not put together a team but farmed the project out to a single programmer and probably underpaid him. I avoid such jobs and the code they produce whenever possible!
While some programmers will have the passion to make great UIs no matter how difficult or tedious the code becomes, a lot will simply find the first thing that gives them the results they need. (In fact, even when their end goal is to make something nice, they may still start with something ugly to make sure that everything else is working.)
There's really only two ways to solve that: give them more time to ship and make "great UI" a clear deliverable (that they're paid for), or give them better tools and expect correspondingly-better results in the time originally allotted.
Assuming your company isn't producing just one product, it's usually wiser to invest in the programming tools. That way, you pay most of the cost once, during development and perfection of the tools, instead of having every single product pay a penalty as programmers and QA have to correct cosmetic and behavioral imperfections in the UI in 1000 places.
Take Interface Builder and Cocoa on Mac OS X. The design of the layout tool, combined with the unapologetic adherence to MVC and KVC design principles in the API, means that interfaces are easier to do elegantly than inelegantly. So it should come as no surprise that the resulting programs, relative to the amount of time spent, tend to be more functional and easier to use compared to equivalents on competing platforms.
These tables may extend off the screen horizontally; have unnecessary grid lines or alternating shading; waste massive amounts of whitespace for varied-length cell values; and include form controls that only take effect with some submit button several scroll-pages away.
- hjkl are navigation keys
- Significant amounts of configuration via plain text files.
- Plugins. In multiple languages.
- A scrolling log viewer screen.
- Reports obscure metrics in the status bar.