Constructive vs. Incremental Design

Posted on December 6th, 2006 by Chris.
Categories: Chris, General/Misc., Product Design, UI Design.

Incremental design involves updating features on an already designed product. Consider Joel on Software’s critique of Vista’s shutdown, or an article reviewing buggy features in a new software product. This sort of design allows for improvements on a current product, but of course this is restricted by the limitations of the preexisting design.

In order to make more than incremental progress, one must design constructively, by creating a new system. The web browser and the spreadsheet, for instance, were not examples of creating a better word processor; they involved a smart designer thinking about a problem in a new way.

In some ways incremental design is best accomplished through constructive design as well. If you start with the initial assumptions of the product (i.e. it must have a way of being turned off, it must have a menu, it must use buttons), then you’re stuck with the initial limitations. Incremental design is better when the designer can think without being absolutely fixed to any narrow paradigms.

0 comments.

UI: Pop-ups are bad, and not just for web pages

Posted on October 4th, 2006 by Tim.
Categories: Tim, UI Design.

 Everyone knows that pop-ups used to be the scourge of the Internet. These days, modern versions of most browsers contain “pop-up blocking” built in. They had become prevalent due to their use as high-visibility advertising, resulting in high click-through-rates. But everyone knows that pop-ups are bad, because they’re annoying and hurt usability.

Consider why pop-ups are bad: 

  • They steal focus away from the current context: This should be obvious, but whenever something appears on the screen which interrupts your current task, it negatively impacts usability.
  • They require extra actions to complete your task: Every pop-up must be closed before the existing task can continue. This may be as quick as hitting Alt-F4, or take as long as switching from keyboard to mouse in order to click the close button.

Despite knowing that pop-ups are evil in web applications, many application writers continue use pop-ups in client-side applications. The terminology for client-side applications is slightly different, however. Pop-ups in client-side applications are known as “pop up dialogs”, “modal dialogs”, or sometimes simply “dialogs”. Some great examples of annoying dialogs can be found The Daily WTF.

One specific type of dialog that is particularly bad is the “Do not show this again” or “Don’t ask me again” type dialogs. Here’s an example from a project on CodeProject:

These types of dialogs generally show information that the user might be interested in, but most likely isn’t. For developers, the easy way out is to simply implement a “Do not show this again” type dialog, justifying by saying “Sure, it’s annoying, but they only have to see it once”. Chances are, if it is annoying, you shouldn’t be showing it as a dialog to begin with. On top of that, users generally immediately click ok for this type of dialog without reading the text. And if they do click on the checkbox, it’s possible that they may want it to come back at some point, which is likely impossible.

Here are some guidelines for when dialog boxes are inappropriate:

  • Providing informational messages that may be interesting to the user.
    Informational messages should never interrupt the users workflow. Present this information to the user in ways that are non-intrusive. Examples of this are tooltip-style boxes that provide information without stealing focus, and tooltip bubbles.
  • Alerting the user to non-fatal errors and warnings.
    Users probably don’t care about non-fatal errors. Chances are, they don’t know how to fix the error, or don’t want to bother. For example: a dialog box alerting the user that the connection to a server failed is probably inappropriate. Alternatives would be: status bar text, status icon indicating connection state, and tooltip bubbles.
  • Input validation errors.
    Don’t put up a dialog box saying “Hey, you can’t have letters in your phone number!” This is annoying, and interrupts the users workflow. Direct the users attention to the field using non-modal UI, such as highlighting the erroneous field, or using a tooltip bubble (can you tell that I like tooltip bubbles?)

On the other hand, however, there are some scenarios where you can, should, and must use dialog boxes.

  • Feedback is required from the user.
    “Do you want to save this document?” is a great example of when a dialog is absolutely necessary. You need to get feedback from the user to determine the proper choice of action. However, if there is ever a scenario where a “default” is usually appropriate, consider the impact of using the default instead of prompting the user for an action.
  • Fatal errors.
    A perfect application would never have fatal errors, but everyone knows that perfect applications are as common as unicorns. When your program crashes, make every attempt to save the users data in some form, and alert the user that a problem has occurred. However, under no circumstances should you give an error that looks like this: “Unhandled exception at doFoobar.cpp:2534″. This sort of information should be logged for customer support, not presented to the user in a dialog box.

2 comments.

Review: Windows Live Writer

Posted on September 8th, 2006 by Tim.
Categories: Tim, UI Design.

As I mentioned in my last post, I’m trying Windows Live Writer as a blogging tool. Despite having a really long name that apparently needs to be prefixed with “Windows Live,” Writer is actually a very convenient tool for blogging. This will be a short review covering the positive and negative aspects of the tool.

(more…)

2 comments.

The Undeletable E-mail

Posted on September 6th, 2006 by Chris.
Categories: Chris, General/Misc., UI Design.

One of the things that is common to do with clubs/organizations is to distribute e-mail newsletters in this sort of form:

——————————

EYE OF SAURON NEWSLETTER

1) Saturday meeting: Trash talking and board elections

2) Sauron-con ‘96 is here!

3) Concerns about membership dues

4) Membership rules change
——————————

1) The Saturday meeting

Yup, that’s right, it’s time for ANNUAL ELECTIONS again!…

(more…)

1 comment.

Older » « Newer