Presentation “UI Best Practices & Trends”

12. April, 2013


Short summary:

  1. UIs are often bloated, confusing and frustrate users.

14 recommendations:

  1. “Show me where I am”
    – breadcrumbs, highlight tabs, use tree navigation
  2. Use the F-Pattern
  3. “Emphasize in Tables”
  4. “Affordance (sic): Show what’s interactive”
    – Make it obvious for users to see where they can click
  5. “Make frequent uses accessible”
  6. “Caution with icons”
  7. “Emphasize primary actions”
  8. “Avoid OK / Cancel”
  9. “Use undo if you can”
    – Avoid confirmation dialogs. No one ever reads them.
  10. Avoid left aligned form labels
  11. “Be nice to user input”
    – Keep illegal values so the user can edit them
  12. “Prevent errors”
    – Calendar popups
  13. “Instant Feedback”
    – Use tooltips on disabled buttons to explain how to enable them
  14. “Help users recover from errors”



Always keep in mind:

Developer != User
Product Owner  != User
UI Guru != User


Things Users Don’t Care About

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.

Designing a Garbage Bin

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.

Not convinced?

Let’s design a public garbage bin together.

What do we want?

  1. Big enough so it never spills
  2. Easy to clean
  3. Nice to look at
  4. Robust enough to withstand riots
  5. Soft enough to cushion the impact of car
  6. Long lifetime
  7. Cheap

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.

Designing DSLs

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.

Software Design With Modern Languages

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.

UI Design: Why is That Button Gray?

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).