Mark Miller

February 2009 - Posts

  • Great UI: Clarity and Color on the Presentation Layer

    Color consists of:

    • Hue Hue
    • Saturation Saturation
    • Lightness Lightness

    Consider the images below:

    On the left gaze attracts toward the deeply saturated hues, and the mind grapples with the hue variance and attempts to discern meaning (of which there is none).   On the right, with all shapes represented in the same hue, gaze attracts toward interesting details and the mind attempts to discern meaning from shape, of which there is a great deal.

    From this, an important lesson:

    Hue variance should justify itself.

    Two screen shots from the iTunes installer: one real; one altered.

    On the left you have an interesting variety of hues, with saturation and lightness apparently disconnected from information relevance.    On the right the same data is represented with only a single hue. Saturation and lightness levels are consistent with the information presented.

    Which image would you rather see during an install?

    So hue variance must be justified. Following this guideline over time, we eventually realize a second, important guideline:

    Fewer hues is better.

    Now let's move to an example that pretty much disregards that guideline. Here's a screen shot from an Excel spreadsheet we use to track refactorings shipped in Refactor! Pro (click to see the full-size image):

    In this spreadsheet, each language supported has a dedicated color (e.g., C# is red, VB is green, C++ is orange, etc.). Also, at the far right of the spreadsheet we track the version where each refactoring was introduced, and also we also note whether that refactoring ships in CodeRush Xpress or Refactor! for Visual Basic. Here too color carries meaning, and is useful. If you're interested in refactorings that only support XAML, for example, you can scan your eyes down and look for a blue circle in the XAML column.

    The column headers serve as a legend of sorts, connecting color to the data it represents:

    We even follow this convention in descriptive text inside the spreadsheet, for example in this description for the Rename refactoring:

    Speaking of Excel, the Excel application itself uses color in an interesting way. When editing formulas, Excel uses color to connect the cell reference in the formula to the cell on-screen. In the screen shot below, the cell reference "R[-4]C" is rendered in blue, and there is a corresponding blue box surrounding that cell:

    On to a practical example. Let's say we have an application that presents sales data to managers, like this:

    Managers using this application want to quickly see the best and worst members of the sales team.

    So let's use red to indicate the lowest values, and green to indicate the highest values.

    That's not too bad. Now at a glance we can see the best and worst performers for any quarter. And we've reached a third guideline:

    We can enhance clarity with color.

    Sometimes I hear developers say:

    "You shouldn't use color at all to convey meaning, because a significant percentage of the population is color blind."

    Is this a reasonable guideline to follow?

    Let's find out.

    First, a bit of background: Color blindness affects 8.6% of males and about 0.4% of females (or 4.5% of the entire population). Our eyes detect low-light variances with rod cells, and full spectrum bright-light variances with cone cells, of which there are three types: L-cones, M-cones, and S-cones. When there is a defect or absence in one of these groups of cones, color blindness occurs. Many of the color vision genes fall on the X chromosome, which is why color blindness occurs more frequently in men.

    Here's the color vision breakdown for humans on this planet:

    In addition to the percentages listed at the top, each color vision category in the figure above includes a list of six named colors, rendered as a person in that category would view them. Note that for the two most prevalent forms of color blindness (M-cone defect and L-cone defect), differentiating between red and green, as well as between blue and magenta, is challenging if not impossible.

    Notice however that for all categories listed, differentiating between red and blue is relatively easy.

    How does this impact our widget sales application? For someone with an M-cone defect, the data looks like this:

    And we lose our at-a-glance ability to see the highs and lows. But what if we take the information learned above, and instead of using red and green, we differentiate with red and blue? Then to someone with normal vision, that change looks like this:

    And to someone with an M-cone defect, the same data would look like this:

    And so we are able to keep with the intent of using color to convey meaning, and do so in a way that works even with people who are color blind.

    And we have a new, important lesson:

    When conveying meaning with color, use reds and blues to differentiate, rather than reds and greens.

    Speaking of conveying meaning with color, you might be wondering what Excel's cell-reference color-highlighting looks like to someone with an M-cone defect. It looks something like this:

    As you can see, we get into trouble with Excel's choice of color for the first and third cells referenced in the formula. The blue and magenta both appear blue, and are nearly impossible to distinguish. Here are sections of the two views, enlarged:

    Should Microsoft address this? Well, let's look at the impact. Editing formulas is something most Excel users do at some point with the product. So it's a highly visible feature of the product. Excel has over 450 million users, and that means over 20 million color blind Excel customers are impacted by this choice. Seems like the answer is a resounding Yes.

    So how can the Excel team fix this? One option would be to slightly increase the lightness of the third color, magenta, so it appears as a lighter blue to someone with an M-cone defect, making it easier to distinguish from the first color. That simple change would look like this:

    All this leads us to a final lesson about color:

    When conveying meaning with color, differentiate by varying lightness in addition to hue.

    So here are the guidelines for color, once again:

    • Justify hue variance.
    • Fewer hues is better.
    • We can enhance clarity with color.
    • Use reds and blues to convey meaning, rather than reds and greens.
    • Convey meaning by varying lightness in addition to hue.

    Coming soon, we'll discuss clarity and noise. After that we'll dive into the second essential component of Great UI: efficiency.

  • Great UI and the Presentation Layer - Clarity and Shape

    In our last post, we saw that information in parallel allows viewers to more efficiently understand data on the presentation layer.

    In today's post, we'll talk about conveying information with shape (e.g., something other than a rectangle).

    Non-rectangular shapes can fulfil a variety of objectives:

    • Create a smaller footprint (so more background information is visible).
    • Model a physical device from the real world.
    • Convey information more dynamically, using conventional graphic elements

    When using non-rectangular shapes it is important that the shape serve some purpose.

    When the purpose is whimsy, you get windows like this:


    In the ducky media player, above, we're actually creating a larger footprint instead of a smaller one. And the only device we're modeling is a bathtub, and last time I checked, this has nothing to do with playing media (at least not in my house). So from my perspective, this non-rectangular shape fails spectacularly.

    And so does this one:


    In the examples above, the custom shapes waste a phenomenal amount of space, and simply do not justify their non-rectangular being.

    Here's another non-rectangular window:


    This is the shortcuts hint from Refactor! Pro and CodeRush. This window shows shortcuts available for interactive states. The tab at the top holds the name of the interactive state.

    Compared to a similar design employing a rectangular window, this custom shape permits more background information to be seen:


    So the benefits are minor, but then again so are the changes, and so the non-rectangular shape justifies itself.

    Speaking of custom shapes and subtle changes, compare the impact of slightly rounded corners against squared-off corners:


    The sharp corners attract gaze, whereas the rounded corners appear more natural, and are easier to ignore.

    Custom shapes can also be used to reveal details of densely-packed information. The screen shot below is from the 3.3 version of CodeRush.


    The document bar to the right shows code issues for the file, however when a file has more lines than there are pixels in the height of the document bar, and there are many issues in a short span of code, you can have overlap. When that happens, the most serious issue is painted in the document bar (the horizontal red line indicates the error).

    Hovering the mouse over the horizontal line in the document bar reveals the details about the densely-packed information below. The custom shape effectively connects the expanded details to the compact representation. The visual connection is instantly assimilated. For this application, the benefits of that instant understanding justify the custom shape.

    Here's another non-rectangular shape:


    This shape appears when certain commands are executed inside CodeRush and Refactor! Pro. The arrow points at the location of the change, and the text inside holds the name of the feature applied.

    More custom shapes, from Oliver Sturm's Instant Gratification plug-in for Visual Studio:

    RTFM   CompiledBaby   YouRule

    Here, the semi-opaque text layered on top of the data provides temporary status information (in this case, immediate feedback on whether the latest compile actually succeeded or not). This text is created as a window, and displayed in a semi-opaque state on top of the data below.

    And finally, we'll wrap up with a custom shape you have probably seen before:


    This shape has rounded corners and a point that connects the information contained within to the applicable task bar item below. This shape is particularly effective as it uses the conventional graphic element, the bubble call-out, to provide useful information in a non-modal way.

    One interesting thing to note -- with the exception of the duck and penguin media players shown above, all examples of non-rectangular windows shown here are used in some way for discoverability, which we'll talk about much, much later in the series.  :-)

    From the standpoint of clarity, if you're going to use a custom shape, the most important guideline to keep in mind is this: Non-rectangular shapes should justify their existence. Justification comes from tangible benefits, such as a smaller footprint, familiarity through the modeling of a physical device, or using conventional graphic elements, such as call-outs, or large arrows, to connect information to specific points of interest on screen.

  • Great User Interfaces, Clarity, and Information in Parallel

    In the last post, we talked about the elements of design we can adjust to match information relevance. In this post, we'll talk about another, equally important guideline to presenting with clarity, called information in parallel.

    This concept is introduced in an amazing book by Edward Tufte:

    TufteBook Title: Visual Explanations: Images and Quantities, Evidence and Narrative

    ISBN: 0961392126

    The book and title both look dreadfully dry. However, proof of Tufte's genius lies therein.

    The idea behind information in parallel is simple. It's much easier for humans to compare and understand when they see information side-by-side, rather than when the same data is presented in serial. This is crucial for user interfaces, because the very nature of software -- representing a large amount of information in a constrained space -- lends itself to solutions that tend toward the presentation of information in serial.

    Take for example, the trusty standby, the modal dialog box. Since the age of windows, modal dialogs have been with us. Two questions:

    1. Have you ever clicked the mouse down on the title bar of a modal dialog, the dragged it off to the side just so you could see something underneath it?
    2. Have you ever clicked the Cancel button on a modal dialog, just so you could access information behind it (perhaps copy some text to the clipboard),  information necessary for successful interaction with the dialog itself?
    3. Have you ever had to click the Back button on a browser, to see a previous page, just so you could then immediately click the forward button to use that information on the current page?
    4. Have you ever had to scroll up when viewing a document, just so you could see information above necessary to understand the information below?

    If you answer yes to any of these questions, then you may be the victim of information presented in serial.

    Examples of information in serial include:

    • Audio podcasts
    • PowerPoint presentations
    • Stacked modal dialogs
    • Wizards
    • A long paragraph of text.

    So far in covering the science behind great user interfaces, a number of comparisons have been presented using information in parallel. Some examples you may remember:

    A failure of efficiency in Why is Great UI so Hard to Achieve?:



    A failure to match visual weight to information relevance, from a table in Microsoft Word, from Great UI, Clarity, and Information Relevance:


    An illustration showing how adjusting too many elements of emphasis (e.g., saturation, size, and contrast) can lead to visual noise, in Great User Interfaces, Clarity, and Emphasis:


    Let's compare information in parallel with information in serial, to see how they differ.

    Information in parallel is more effective than information in serial, because it can be exploited by our eyes which are excellent at quickly moving back and forth. All layers are simultaneously visible, and the viewer has full control over the pacing and the sequence in which information is understood. Information in serial, on the other hand, burdens the viewer with pacing challenges (information may arrive too quickly or too slowly). Viewers also have no control over the sequence of presented information when arriving in serial.

    That last paragraph was an example of information in serial.

    Here's the same data presented in parallel:

    A viewer can... Serial Parallel
    Control the pacing of information: No Yes
    Control the sequence of information: No Yes
    See all information simultaneously: No Yes

    Notice when information is presented in parallel, our eyes can move back and forth, easily and quickly comparing data in the columns at a pace that feels right.

    One note about pacing and information in serial: Sometimes UI provide viewers with a mechanism to control pacing, as in the example of a wizard dialog that allows you to navigate forward or backward through its pages. This all comes at the expense of introducing an interaction mechanic (e.g., reaching for the mouse to click the Next or Back buttons) that is likely to be far less efficient than simply shifting gaze, which is all it takes to control pacing with information in parallel.

    So the goal is to take a serial interface (e.g., stacked modal dialogs) and flatten that out. How can we do this?

    Well, it isn't easy. It often requires careful thought applied to layout as well as an understanding of what information is essential and needs to be readily available, and what information is less important. Sometimes it requires innovation, in the form of new user interface elements. Let's look at an example from the world of software development.

    Let's say your challenge was to create a user interface that assisted developers in reordering parameters in a method declaration. Using traditional software-building tools, you might crank out a modal dialog that looks something like this screen shot taken from Visual Studio 2008:


    There are good things here, and there are also some undesired consequences. Let's talk about the good first. There are two:

    1. The dialog appears under the method you are trying to rename, so that the source code you are trying to change, as well as the dialog itself, are both in view. This is information in parallel.
    2. The Preview method signature box shows the impact of your changes before you apply them. This is also information in parallel.

    Next, the issues:

    1. The dialog hides a significant amount of otherwise visible code in the document. When a window hides information below it, this is information in serial.
    2. The user model changes. Developers are used to working with the keyboard and source code, but now developers have to adapt to a new unfamiliar model, one that uses a grid, buttons and mouse clicks to manipulate code.

    So, how do we flatten this down? Is there a way to remove the dialog completely, yet still allow interaction with a preview before changes are committed? The answer is yes. Here's how we do it:

    1. Move the UI elements down to the lowest layer of the UI (the source code, in this example).
    2. Introduce a similar state-like ability for the interactive phase (where developers can reorder the parameters without reaching for the mouse and without having to adapt to an unfamiliar representation of method signatures).

    That UI might look something like this:


    On the good side, we've removed the modal dialog that blocked out so much of the code. And we've introduced an interactive phase that allows parameters to be reordered without reaching for the mouse (efficiency gains) while keeping a familiar representation of the data (clarity gains). On the downside, in keeping with the familiar representation of the code and losing the dialog, this in-source interactive phase will no doubt be an unexpected surprise the first time developers encounter it. So we compensate, improving discoverability by adding the shortcut hints window in the lower-left.

    So yes, flattening the UI can take some effort, and even the introduction of new UI elements or states. However the gains in efficiency and clarity (and sometimes even discoverability), can make it all worth it.

  • Great User Interfaces, Clarity, and Emphasis

    In our previous post in this series, we established an important guideline to achieving clarity:

    Visual weight should match information relevance.

    The essence of this guideline, is don't overdo it. So as we discuss ways to control emphasis, remember that the goal is to be subtle, to emphasize with what Edward Tufte refers to as the smallest effective difference.


    The easiest, and most powerful way to control emphasis is with contrast. Here's another screen shot from Adobe Lightroom:


    Notice the less relevant labels on the left are rendered in a slightly lower contrast than the more important data on the right.


    Color can convey meaning, especially when used sparingly. In a sea of mostly black and white data, deeply saturated information will stand out.

    Trillian, an instant messaging client, has an interesting option to render non-focused windows in a semi-transparent state, or in gray scale. Here's an example. On the left, the window is focused. On the right, unfocused.



    Opacity is related to saturation and contrast. As you increase transparency of graphical elements, both saturation and contrast will drop. Opacity can also be used to indicate elements that are partially available.

    Below are two screen shots from Visual Studio with Refactor! Pro loaded. The arrow in red explains the command that just executed. On the left the arrow is fully opaque, distracting, and hard to ignore. On the right the red arrow is partially transparent, much easier to ignore, and yet the text is also readable if needed.


    When we initially shipped Refactor! Pro, the arrows were fully opaque, and we received many complaints from customers that the arrows were too distracting. We changed the default opacity for the next release, and the complaints dropped to zero (and we even received several emails praising their usefulness). So by controlling opacity we can take a distracting UI element that contains useful information (but perhaps is rarely needed) and turn it into something useful that feels right.


    Use a bold font to draw gaze into essential or important meaning, as in the tool tip below, that describes the Change Case button in Microsoft Word:


    In the checkboxes below, notice how you can quickly find the control you need just by visually scanning for the important words describing the functionality you need:


    Being able to emphasize portions of control text is important, and it's something you can do with DevExpress controls. Julian Bucknall shows you how in his post, Using DevExpress controls to get a great looking UI.


    Size can be useful for attracting gaze. You can combine larger size with a lower contrast to attract the eyes and let them move on to more relevant data below, as in the screen shot from the DXCore options dialog, showing the Recent Files options page:


    Here, the title of the options page, "Recent Files" is in a larger font, which makes it easier to see for users encountering this page for the first time. But the contrast between this title text and the background is also low, making it easy for repeat users of this page to ignore the title and move on to the more important elements of the UI.

    For another example, take a look at the the "Image Settings" text in the gray-scale screen shot in the discussion on Fonts, above.

    Wrapping Up

    The essence of clarity, from a design and emphasis point of view, is to selectively match a subset (generally one) of the following traits to information relevance:

    • Contrast
    • Saturation
    • Opacity
    • Size

    I've left out Font because to some degree it's a subset of Size, and just as I don't want you to create UI with low-relevance information rendered in high contrast, I also want to make sure you don't create UI that so strictly follows this guideline to the point that you're no longer following the guideline and instead creating UI that approximates a ransom note.


    The goal, after all, is clarity.

    For example, imagine a tree list of information. One could make the argument that sibling and cousin nodes have different levels of information relevance than their respective parents or children, and therefore should be each rendered in a corresponding font size and contrast. That line of thinking could produce something like the following, which shows all references to the decimal type in a C# project:


    The problem here is that by going too granular with grouping and dividing of information relevance, and also by applying too many levels of emphasis (e.g., font size as well as contrast), with good intentions and the goal of clarity we actually end up introducing some visual noise in the form of the varying font sizes and contrast. And that noise interferes with the essence of what we're trying to achieve. So just like the first guideline essentially says "Don't overdo it." A second, perhaps equally important guideline to consider is "Don't overdo it (or go too granular) when matching emphasis to information relevance."

  • Great UI, Clarity, and Information Relevance

    Let's create a 3x4 table in word....


    And let's fill the table with data....


    Now, at this point, we might pause to ask "What's wrong?". But before we answer, let's make the observation that in the table above, there are a number of graphic elements working together to convey information. There is the data, rendered as text:


    And there are lines separating the data:


    Note that in Word, both the lines separating the data, and the data itself, are both rendered with essentially the same visual weight. The thickness of the line matches the thickness of the strokes used to render the text, and the contrast of the lines also matches the contrast of the text.

    However, it seems that the lines and the data, in terms of relevance to the viewer, are far from equal. A viewer is far more interested in the data than the lines separating the data.

    Let's look at the same table in Excel:


    Notice that when creating the same table inside Excel, something interesting has happened. The lines are rendered in a much lower contrast than the data itself.

    Which table do you find easier to read?


    On a whim, let's create a version of this table where we do the opposite of what's done in Excel. Namely, let's reduce the visual weight of the important data, while increasing the visual weight of the much less relevant separating lines:


    How easy is this to read, compared to the table from Microsoft Excel, above?

    So, two important points to take away:

    1. Not all information is equally relevant to the viewer.
    2. We have control over the degree to which we can emphasize information.

    And from these two realizations, you can reach the third, perhaps most important guideline to achieving clarity in your UI:

    Visual weight should match information relevance.

    This guideline is incredibly important, easy to follow, and yet violated frequently. My contention, as set forth in the post that explored the question of why great UI was so hard to achieve, is that the rampant violations can be explained by a lack of training.

    Here's a screen shot of Visual Basic source code as seen in Visual Studio 2008:


    The horizontal lines carry little information relevance. And even though they are rendered above in a medium gray, their contrast and corresponding visual weight far outweigh their intended purpose.

    Here's the same image with one minor change:


    See how much easier it is to get your eyes into the relevant data.

    Here's a screen shot from Adobe Lightroom:


    Notice how the labels on the left, being less relevant than the data to their right, are rendered in a lower contrast, allowing your eyes to quickly get to the relevant information.

    In near-future posts, we'll talk more about ways to control emphasis and dive deeper into clarity.

  • Why is Great UI so hard to achieve?

    Filling up my car with fuel this morning, I'm suddenly hit in the face with more evidence that the vast majority of user interfaces fail to satisfy those three important elements of great UI, clarity, efficiency, and discoverability.

    One of the common mistakes you see in the physical world are buttons on a single device designed as if they will all be pressed with the same frequency. You can tell this because the buttons are all the same size, and in some cases the buttons you have to hit most frequently are two small and located in places that require more thought and more precision to hit than they should.

    Speaking of buttons and precision, here's part of the interface I was looking at:


    On the left you have the button from a fuel pump that selects the most popular grade of gasoline in the United States. On the right sits the button for the less popular, more expensive grade of petrol. The erosion on the left is like a chart showing both frequency of hits as well as signaling where people wanted to hit the button. It is clear that humans who interacted with the button on the left wanted to work with a button far larger than the designed "Push Here" area afforded.

    Here's a redesign of this interface, keeping with the essence of the original:


    Here are the changes (we'll explain the rationale behind these changes in future posts):

    • "GRADE SELECT" converted to the less-noisy "Grade Select".
    • The unnecessary underline below "Grade Select" has been removed.
    • The redundant "Grade Select" text has been removed.
    • The tabs holding the "Grade Select" text have been removed.
    • Button area increased and low-contrast border added.
    • Contrast of the "Push Here" labels has been lowered.
    • Contrast between the Regular and Plus text, and their backgrounds has been increased.

    So, while there is plenty of evidence that some buttons are pressed more than others, there isn't much evidence that designers actually understand that.

    One of my favorite large buttons is the space bar on a modern keyboard. Of course that originates from an ancient machine known as the typewriter. Unfortunately, the QWERTY layout that dominates today takes a step far, far away from efficiency by unbelievably moving frequently-accessed keys into harder to reach spots, reportedly because early adopters of typewriters with pre-QWERTY layouts were so proficient they would frequently jam the typebars of the machine together. I can't tell you how much I would like to be in on that meeting back in 1874 when they decided to move the keys around so they were actually harder to hit. That one decision had to be one of the most expensive user interface mistakes ever made, in terms of lost productivity multiplied over time. That space bar likely survived only because hitting it simply advanced the paper one character to the left -- and did not increase the risk of typebars getting wedged together.

    But it did survive and it's big and easy to hit with either thumb, so I like it. :-)

    You need to get to that cross walk over there in the distance on the right. Which path do you take?


    On the left, the designers' intention is highlighted in red. On the right, the more efficient path is outlined in blue:


    There is evidence humans prefer efficiency to flat hard ground.

    You're watching TV. You need to change the channel, and you need to change the volume.

    Which remote control would you rather hold in your hand?


    Which remote would you rather adjust volume on?


    On the white remote control on the right, the channel-changing buttons on top are far away from the volume-changing buttons at the lower-right.


    Also, these horizontal and vertical orientations are inconsistent and require some mental training before it feels natural. And the visual weight (shape, size, contrast) of these buttons is identical to nearly all the other buttons on the control, including the rarely-pressed buttons labeled Language and Clock.

    You're inside an elevator in the N-terminal at Seatac airport. You need to get on your plane. There are three buttons to select your destination:

    • RAMP (*R)
    • TRAIN (TRN)


    Which button do you press? That RAMP button with the star next to it looks mighty appealing. After all, I must walk down a ramp to get onto my plane. And haven't I seen stars on elevator buttons used to indicate the main floor or lobby? And what's a concourse, anyway? I need to get to my gate, and it's in a terminal.

    Here's a wider picture of that elevator control panel:


    Apparently there was sufficient ambiguity between the RAMP level (some obscure mid-level where passengers apparently do not want to be) and the CONCOURSE level (where you can board your plane) to justify the addition of the hardware-equivalent of software's floating tool tips. Of course, these tool tips are completely invisible to blind folks who are likely to all be congregating on that floor marked with the star R on it.

    So, there is evidence that designers of hardware (and certainly software) are not paying attention to important matters.

    Now back to the original question -- why is great UI so hard to achieve? While a number of factors impact the ultimate outcome, I would suggest the most important influencer is training. It seems that most developers and designers creating interfaces for human consumption simply lack a small bit of knowledge that could make a huge difference.

    How big of a difference? Well, for starters, let's go back to the gas station where I bought fuel this morning. Swiping my credit card, I'm presented with a message on screen, that looks like this:

    Is this a debit card?

    Of course I am unable to proceed until the question is answered. I happen to be using a credit card, not a debit card, so I know the answer is no. However it is not immediately clear how I'm supposed to communicate this status to the machine.

    So next I move my gaze down to scan the keypad. After reading labels on a half-dozen buttons, I find the buttons labeled Yes and No at the bottom-right of the keypad (much farther away from the message than they need to be). I should point out that the question (e.g., "debit card?") changes from station to station -- sometimes the machine wants to know if I'm using a credit card, and sometimes the machine asks me to find buttons labeled Credit and Debit and then press the right one. Remembering that the question this time was asking if I was using a debit card, I click the No button, and return my gaze to the screen above, to see if I am now permitted to put fuel in my vehicle.

    All told, this sucks up about ten seconds of life each time I use my card. And not only at gas stations, but grocery stores and many other places of business. Every time I try to give my money to the merchants, they just try to slow me down. This is not in their best interest, nor is it in mine.

    Poorly-designed UI acts as a frictional force against the economy. How much does it cost? Well, let's start multiplying those ten seconds out across all the millions of transactions occurring every day across all of these machines, and you have a picture of an amazing amount of time wasted. Multiply that time by average salary of those affected and you have a way to estimate the cost of this design choice.

    But why ask the debit card question in the first place? Personally, I never carry any debit cards. For me, the answer will always be the same. Well, it would always be the same if the questions were always the same. And surely we live in a world where technology can identify on some end (the gas station, the bank, etc) which way my card swings.

    So, bad UI surrounds and the reason for this failure may simply be lack of training. And I'm betting when you first saw the question you were thinking it was something else. :-)

    The test for this assertion is simple. Follow the series, get the training, and watch how dramatically that improves your ability to design great interfaces.

    In the next post, we'll dive into clarity.

  • The Essence of Great UI - An Overview

    I've decided to spend some time doing a brain dump of everything I know about great user experiences. Here's the first of what I hope will be a fun and inspiring journey. I also expect this series will serve as a replacement for the book on great UI that I'm unlikely to ever write....

    The most important thing to start with is the knowledge that great UI is all about three things:

    • Clarity

    • Efficiency

    • Discoverability

    Clarity is the ease of understanding presented information.

    Efficiency is the ease of control and movement through the data. There are obvious physical components to this, and there are not-so-obvious mental components as well.

    Discoverability is the ease of finding and understanding that which lies below the surface.

    So the challenge to creating a great UI is to maximize all three of these. However, this is rarely easy to do, as there are many paths we might take, and natural tensions that exist along those paths.

    In future posts, I'll show how to measure efficiency, clarity, and discoverability, and talk about interesting ways we can improve these elements of the user experience. And as always, I encourage interaction and ideas from you. Feel free to post a comment below, or email me directly at markm at the Dev Express domain.

    No series on great UI would be complete without a discussion about the value of great UI. And so in future posts we'll show how to measure the cost of poor UI. Today, I'll just leave you with an observation you may find interesting. There appear to be correlations among the following:


    In the next post, we'll look at why great UI is so hard to achieve.


Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at or call us at +1 (818) 844-3383


DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, Delphi, HTML5 or iOS & Android development. Whether using WPF, ASP.NET, WinForms, HTML5 or Windows 10, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2018 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners