12. April, 2013
A short summary of the presentation “UI Best Practices & Trends” held by Roland Studer of We Are Cube (slides).
- UIs are often bloated, confusing and frustrate users.
- A major factor is that features are often requested by people who won’t have to use the software later i.e. by (self) “important” managers. A variation of “Nothing is impossible if you don’t have to do it yourself.”
- “Don’t make me think” by Steve Krug (Amazon)
- “The interface is your product” (“Getting Real – The Book“). Customers don’t care about the code or the effort which went into the product, they only see what you show them on the screen.
- “Show me where I am”
– breadcrumbs, highlight tabs, use tree navigation
- “Use the F-Pattern”
– eyes travel left to right, top to bottom in Western cultures
- “Emphasize in Tables”
– gray out less important values, make important ones bold, group with color, use gauges instead of numbers
- “Affordance (sic): Show what’s interactive”
– Make it obvious for users to see where they can click
- “Make frequent uses accessible”
– Show only the most important actions as buttons (max. 5).
– Put the other, less signification actions in a popup menu.
- “Caution with icons”
– “A picture says more than 1000 words but which words exactly?”
– Icons can be confusing, hard to remember and they depend on culture/training.
– Offer at least user preferences to replace them with text or show text in addition to the icon or use tooltips.
- “Emphasize primary actions”
– Make the button stand out which the user most likely wants to click next or reduce visibility of less likely options (like “[Submit] [Cancel]”).
– Be careful that the visual cue doesn’t conflict with “this button is disabled”
- “Avoid OK / Cancel”
– Instead of asking “Is it OK to delete?”, ask “This object is still be used. [Delete Anyway] [Keep]”
- “Use undo if you can”
– Avoid confirmation dialogs. No one ever reads them.
– The user should never be able to do anything that isn’t reversible in some way.
– Allows users who got confused with an icon (see #6 above) to unto destructive action on touch screens.
- “Avoid left aligned form labels”
– The eye is only able to align elements when they are close enough.
– Right align labels, rely on browser search for locating elements if you have too many of them (which you shouldn’t)
– Or put the label on top of the fields (but this works better for forms where you have to fill in every single field)
- “Be nice to user input”
– Support “slang” like “next Tuesday” or “now” in date fields
– Keep illegal values so the user can edit them
- “Prevent errors”
– Calendar popups
– Offer a list of valid inputs in a drop-down list or use radio buttons
- “Instant Feedback”
– Show what has been entered correctly as well as what’s wrong.
– Display validation errors immediately (when the focus is lost) instead of waiting for the user to click on a “Submit” button
– Use tooltips on disabled buttons to explain how to enable them
- “Help users recover from errors”
– Avoid “There have been errors” dialogs; they aren’t useful in any way.
– Don’t tell what’s wrong, tell how to fix the error. If you don’t know how to fix it, will the user?
- “Responsive Web Design” – adjust the layout to available screen space. “Mobile first” helps to concentrate on the core features of your application. “Reduce to the max”, avoid distractions, show only the absolute minimum of data. Anything on the page begs to be noticed, so even if the user doesn’t read it, it will still take a tiny bit of concentration to ignore!
- There is a trend towards flat and minimal design. Example: http://basecamp.com/ where a lot of things on the page are interactive (i.e. responds to clicks) but almost everything looks like plain text.
- “Actions only on hover” – Show available actions only when the user hovers over some part of the page. Drawback: Doesn’t work on touchscreens since the user can’t “hover”
- “Implicit feedback” – Show a “saved successfully” message. Give hints in text fields.
Always keep in mind:
Developer != User
Product Owner != User
UI Guru != User
Do usability testing. If you can’t, try installing the product on a laptop and ask someone in the corridor to use it for five minutes. A little is better than nothing. You’re blind to your own prejudices.
8. February, 2013
“Things users don’t care about” is something every software developer needs to know about.
Kudos go to Thomas E. Deutsch for finding and telling me about it.
17. December, 2012
Many of us have noticed that designing software is surprisingly hard but many don’t know why that is. The simple answer: Design is the art to balance contradicting goals.
Let’s design a public garbage bin together.
What do we want?
- Big enough so it never spills
- Easy to clean
- Nice to look at
- Robust enough to withstand riots
- Soft enough to cushion the impact of car
- Long lifetime
It’s easy to see that “cheap” contradicts almost anything else. “Nice to look at” means an (expensive) artist has to build the form. Big garbage bins ain’t cheap. Easy to clean and robust mean high quality materials for hinges and locks. Easy to clean and long lifetime involve expensive surface materials and finishing.
It should be easy to lift for the cleaning crew but not for rioters. When a car hits it, the bin should give way. So these contradict each other as well.
Still not convinced? Look at my elevator example.
16. July, 2012
Hello and welcome to a new series of blogs called “Designing DSLs” or DDSL for short. If you have used or designed a DSL before, then you’ll know that there are a couple of pitfalls. This blog series aims to provide tips how to build “great” DSLs – whatever that might be 😉
What are the most common pitfalls for designers of DSLs?
- The DSL is too broad
- The DSL is too limited
- The syntax has weird quirks (a.k.a. backwards compatibility syndrome)
Why is it so hard to design a great DSL? They should be simple, right?
Well, as Einstein (“Everything should be made as simple as possible, but no simpler“) and Blaise Pascal (“I would have written a shorter letter, but I did not have the time.“) already knew, it’s always easy to make something complicated – simplicity is hard.
On top of that, every mathematical system is either incomplete or inconsistent. And let’s not forget that each DSL is a model, too. And as you might know, all models are wrong but some are useful.
Should we abandon all hope? No. Just always remember that a good DSL is hard work.
First, a general tip: Look at existing examples. There are thousands of examples out there; use them. Knowing several programming languages yourself is a big bonus (everyone should know more than two languages).
“Wait a minute,” I hear you ask, “these are real programming languages!” So? A lot of brainpower went into designing them (or working around shortcomings), which makes them a great source of inspiration. Bonus: A lot of people know these languages which gives you a larger audience to discuss ideas (as opposed to the 3-4 people who will use your DSL in the beginning).
18. May, 2010
I just stumbled over “The Rise of “Worse is Better”“. The article deals with the “get it right the first time” and the “get it as right as possible” dilemma. In Software development, you often have a situation where you don’t know enough for “get it right 100%” and you don’t have the time to learn. Or “get it right 100%” just isn’t possible.
In the end, “do it as good as you can” is, all things considered, better than the alternative. Or as Bill Gates allegedly said: “Windows doesn’t contain any bugs which any big number of users wants to have fixed.”
Which explains nicely why programming languages which strive for perfectionism (like Lisp) never really caught on. There are just too few perfectionists – and it’s a recessive trait.
6. November, 2009
There is a nice series of articles on IBM’s developerworks by Neal Ford which talks about software design and how modern languages help to come up with a clear and cost-efficient design. To get a grasp why this is important, I like this quote:
Building software isn’t like digging a ditch. If you make compromises when you dig a ditch, you just get uneven width or unequal depth. Today’s flawed ditch doesn’t prevent you from digging a good ditch tomorrow. But the software you build today is the foundation for what you build tomorrow. Compromises made now for the sake of expediency cause entropy to build up in your software. In the book The Pragmatic Programmer, Andy Hunt and Dave Thomas talk about entropy in software and why it has such a detrimental effect (…). Entropy is a measure of complexity, and if you add complexity now because of a just-in-time solution to a problem, you must pay some price for that for the remaining life of the project.
Any software developer should be familiar with the concept of entropy and how it affects their lives.
In a later installment, Neal shows some reasons how modern languages allow to implement many of the design patterns by the GoF much more naturally with Groovy.
13. August, 2009
Here is one tip for your UI design that can really make life easier for your users: “Why is that button gray?” – or smart tooltips for disabled elements.
One additional comment: The tooltip shows a lot of information why the button is disabled. Why not simply set the right tooltip in the save place where you disable the button? At that time, you’ll know exactly why you do it and you can give the user specific directions what to do now (instead of having her read and pick from a list).