Presentation “UI Best Practices & Trends”

12. April, 2013

A short summary of the presentation “UI Best Practices & Trends” held by Roland Studer of We Are Cube (slides).

Short summary:

  1. UIs are often bloated, confusing and frustrate users.
  2. 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.”
  3. “Don’t make me think” by Steve Krug (Amazon)
  4. “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.

14 recommendations:

  1. “Show me where I am”
    – breadcrumbs, highlight tabs, use tree navigation
  2. Use the F-Pattern
    – eyes travel left to right, top to bottom in Western cultures
  3. “Emphasize in Tables”
    – gray out less important values, make important ones bold, group with color, use gauges instead of numbers
  4. “Affordance (sic): Show what’s interactive”
    – Make it obvious for users to see where they can click
  5. “Make frequent uses accessible”
    – Show only the most important actions as buttons (max. 5).
    – Put the other, less signification actions in a popup menu.
  6. “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.
  7. “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”
  8. “Avoid OK / Cancel”
    – Instead of asking “Is it OK to delete?”, ask “This object is still be used. [Delete Anyway] [Keep]”
  9. “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.
  10. 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)
  11. “Be nice to user input”
    – Support “slang” like “next Tuesday” or “now” in date fields
    – Keep illegal values so the user can edit them
  12. “Prevent errors”
    – Calendar popups
    – Offer a list of valid inputs in a drop-down list or use radio buttons
  13. “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
  14. “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?


  1. 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!
  2. There is a trend towards flat and minimal design. Example: where a lot of things on the page are interactive (i.e. responds to clicks) but almost everything looks like plain text.
  3. “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”
  4. “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.

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

Does It Have To Be a Scrollbar?

12. June, 2008

Every once in a while, someone comes up with a nice idea and everyone adopts it. People needed a way to navigate in a document larger than the screen, so scrollbars were invented to give an idea where they are related to the whole document.

Scrollbars offer a consistent interface, they are well understood and they don’t change size while you use them. That’s good. But they also fail give you an idea where to look when you search something. Like: Where did I modify my document? What’s above and below?

farmhand shows this information. Instead of a gray/blue blob that moves, you get a zoomed view of the document along with change marks. It takes a bit more space on the screen and I’m not totally convinced how it fares with really large documents but it’s definitely a new idea with some potential.

I’d just put these “farmhand bars” as pop ups on the editor tabs, so they don’t clutter the screen when hidden and are still easily accessible when you switch editors.

Creating a Visual XML Editor

23. April, 2008

A long time ago, I’ve complained about XML editors and that there is no decent XML editor out there which you can use as the basis for a nice visual editor for your custom XML format.

It seems my prayers have been heard.

Portable UI

18. January, 2008

For many years, I’ve been looking for a way to write portable applications with a nice, responsive user interface. Many have tried and many have failed:

  • Python with tcl/tk – A nice experience from the developer side. The Python wrapper around the tk widget set shows how you can get compact, yet easy understandable code and write UI’s in short time. If it just weren’t that ugly …
  • Java with Swing – Swing borrows a lot from X11, the grandfather of all graphical desktops. I have yet to see anyone managing to impress the world with their grandfather …
  • Java with SWT – Now, here comes a contender. Java is pretty widely available (not quite as many platforms as Python, but still), it is pretty fast, okay, the download is a bit on the big side … but no DLL hell, easy to setup (especially if you don’t provide an installer and just push a ZIP out). SWT is nice, fast … and bare bones. MFC? Well, they have JFace and in a few years, there might even be a text editing component that can do word wrap and still show line numbers. Oh, and SWT is available on even fewer platforms than Java. Palm, anyone?
  • HTML – Web based apps are all the hype. If you want to use your app on the run, it gets tricky. I don’t know about the US, but here in Europe, going online with you mobile will ruin you. Literally. Also, I’ve had my struggles with HTML and CSS and I can do without. Either and both.

I’ve tried a few more but in the end, things never felt right. Until recently. I’m a big fan of treeline. Treeline uses Python and PyQt which wraps Qt (say: “cute”). Qt is a mature framework, currently at version 4.3.3, with 4.4 is around the corner. It doesn’t have all the nifty stuff I can imagine (like an RTF editor; QTextEdit can only do a (big) fraction of that) but it gets closer to what I want than anything else.

In the past two weeks, I wrote a little clone of yWriter4. The little baby has currently about 8000 loc and about half of the functionality I want to give it (especially the text editing is still leaving a lot to be desired). Except for two bugs (signal names and GC issues), it’s been a real pleasure to use. I managed to implement almost every feature within a few minutes or few hours (the storyboard took 6 hours, the scene chart view took two), also thanks to the good defaults of the framework. Here is an impression of v0.2:

So when you’re considering to write a small to medium sized application which needs to run on Windows, Linux and MacOS, give PyQt a try.

%d bloggers like this: