Mark Miller
  • CodeRush Xpress 9.1 Beta for C# and Visual Basic Developers

    Alright kids, we've got some exciting news. The CodeRush Xpress 9.1 beta is now available for download. It's packed with crazy powerful features, for both C# and Visual Basic developers working in Visual Studio 2008. This product is free, licensed by Microsoft on behalf of Visual Studio 2008 developers everywhere.

    Here's a quick overview of what you get in this free download....

    59 Refactorings. That's right, 59 refactorings. And you get some really powerful refactorings here including Decompose Parameter and Extract Method to Type.

    17 Consume-first providers. You've got to see these in action to realize how powerful they are and how well they partner with Visual Studio's built-in Intellisense. Use Intellisense to build an expression, and use CodeRush Xpress to instantly declare the variable to hold it.

    Powerful navigation tools. Such as Tab to Next Reference, CamelCase Nav, Quick Symbol Nav and File Nav.

    And so much more. Smart Cut, Smart Copy, Structural Highlighting, and Duplicate Line, to name a few.

    Videos to get you started:

    C#       Visual Basic

    (note, the links at the end of the videos telling you where to download CodeRush Xpress 9.1 are not yet published -- use the links in this blog post instead)

    This could be the most powerful no-cost developer tool created ever, in the history of all time!

    Remember kids, this beta won't last forever, so get it here, and get us some great feedback ASAP!

  • New Video -- New CodeRush Features for Development

    This video shows templates, navigation features, selection embeddings, and refactorings for and HTML development inside Visual Studio, with CodeRush and Refactor! Pro:

    CodeRush Features for Development

    Check out Cell Nav, and the simple yet elegant UI for creating HTML tables.

  • Refactorings Shipping in Refactor! Pro 9.1

    With the 9.1 release of Refactor! Pro, we bring the count a few refactorings closer to 200. This release only adds a small handul of refactorings, but that's okay since a great deal of our focus has been on improving performance and reducing memory usage. Click below to get the same spreadsheet we use internally to track all the refactorings. You can sort, filter or group by language supported, version number, or refactoring category.

    Refactorings in 9.1

  • What's New in CodeRush & Refactor! Pro 9.1

    9.1 is out. Here's what's new in CodeRush and Refactor! Pro since 3.2:

    New Version Number. We are now synchronizing our version numbers and releases with the rest of the DXperience product line. Here's how you can make sense of the version number:


    Faster Performance. Performance should be noticeably faster in most areas of the product, especially on large projects. Startup time, project opening time and editing performance have all been affected by this work.

    Reduced Memory Footprint. Memory usage has been reduced significantly, and should be especially noticeable when working with large projects.

    Code Issues. Code issue technology is now shipping. This new technology shows redundant code, hints, warnings, errors, and design-related problems (a.k.a. "code smells") while you work, and also binds to CodeRush's CodeProvider technology and Refactor! Pro's refactoring technology, so you can quickly apply fixes to a number of detected issues.



    Feature Control. Now when a CodeRush feature executes, you'll get confirmation and an instant way to keep that feature active or disable it. For example, if our default shortcut conflicts with an existing Visual Studio shortcut, you'll have an opportunity to decide which feature wins. Here's an example:

    When the modeless feature control window appears, you can:

    • Ignore it and simply continue to work.
    • Click one of the "Always do this" links to enable or suppress the feature.
    • Click one of the shortcut links (e.g., "Tab" in the screen shot above) to change the shortcut binding to something else.

    Note: If you disable a feature, you can re-enable it on the Core\Features options page.

    HTML Selection Embedding. You can embed HTML selections in a variety of useful tags, including:

    • Bold (<strong>)
    • Italics (<em>)
    • Underline
    • Anchor
    • Div
    • Paragraph
    • Table

    Just select the text you want to embed and press the CodeRush/Refactor key (Ctrl+` by default), select "Embed Selection" and the tag you want to wrap with.


    HTML Templates. We've added powerful new templates for HTML developers. These templates appear in the CodeRush Training window (DevExpress | Tool Windows | CodeRush). Supporting both ASP.NET and raw HTML, these templates make it much easier to create content from the source window. Here's a partial list of HTML templates in this release (use the CodeRush Training window to see them all):


    These HTML templates are smart and will generate unique values for the ID, Name, and Value properties as needed.

    The table templates (.t, .thf, and t appearing in the screen shot above) include UI that makes it easy to create tables of any size. For example, I can create a 2x5 raw HTML table in four keystrokes (".t", Space to expand, followed by Enter to accept the table dimensions).


    HTML Cell Navigation. Once you have your table, you'll want to navigate through its cells. We've made this easy, too. Just press the Tab key when the caret is inside a table cell, and Cell Nav will take you to the next cell in the table.


    And of course Shift+Tab takes you to the previous cell.

    Cell Nav even understands cells that span multiple columns:


    And you can use the mouse to get to the cell you're interested in.


    Now that you can navigate quickly through your tables, we thought you'd also want to be able to navigate just as efficiently through the items in your list controls (e.g., DropDownList, BulletedList, select, etc.). And so you can. Just press the Tab key to navigate through the items.


    CodeRush developers familiar with Tab to Next Reference are no doubt beginning to detect a pattern here. :-)

    New Refactorings. This release includes a few new refactorings:

    • Compress Assignment. Compresses this assignment to a short form assignment. For example, converts "a = a + b;" (in C#) to "a += b;".
    • Expand Assignment. Expands this short form assignment to a full assignment.  For example, converts "a += b;" (in C#) to "a = a + b;".
    • Split Using Statement. Splits this multi-declaration using statement into two or more neighboring using statements.
    • Sort Namespace References. Sorts namespace references in the current file.

    Code Providers. There are some powerful new code providers (including a spell checker!) as well:

    • Declare Properties. Generates auto-implemented properties for an object initializer expression.
    • Declare Fields with Initializers. Adds fields and initializes it to each parameter of a constructor.
    • Declare Property with Initializer. Adds an auto-implemented property and initializes it to the parameter under the caret.
    • Declare Properties with Initializers. Adds auto-implemented properties and initializes them to each parameter of this constructor.
    • Declare Method (abstract). Generates an abstract method for the method call with appropriate parameters.
    • Convert to Procedure. Converts a function that returns an object into a method that returns void (or a Sub in VB).
    • Convert to Function. Converts a method that returns void (or a Sub in VB) into a function that returns an appropriate type. Note: I use this one frequently. Just add a value to a return statement inside a proc, place the caret on the return keyword, and press the CodeRush/Refactor key.
    • Convert to Auto-implemented Property. Converts an unimplemented property into an auto-implemented property.
    • Convert to Property with Backing Store. Converts an unimplemented property into a property with backing store.
    • Spell Checker. Corrects a spelling error in a comment or string.

    We hope you enjoy this new release. We're not finished with our work on performance and memory. We expect the 9.2 release to be even faster with an even smaller footprint. Looking forward to your feedback on 9.1.

    Oh, one more thing! CodeRush, Refactor, and a host of other DevExpress products are in the running for the PRO readers choice awards. Please vote for your favorite tools and controls. Thanks to everyone in advance!

  • Prepping for the 9.1 release of CodeRush and Refactor! Pro

    We're all deep in the final stages of prepping for the 9.1 release of CodeRush and Refactor! Pro. That explains the relatively quiet front out here. The jump in version numbers synchronizes with the rest of the product releases here at Dev Express. The 9 corresponds to 2009, and the 1 signifies the first release of the year.

    I'm currently working on an plug-in that HTML devs should be excited about, and in it I noticed the following code:

          if (leftSideIsWhiteSpace && rightSideIsWhiteSpace)
            ea.Satisfied = true;  // On an empty line.
          if (!leftSideIsWhiteSpace)
            ea.Satisfied = true;  // Text to the left.

    You may have spotted the redundancy here. Fortunately, I have Refactor! Pro. So I can place the caret on the if statement, press the CodeRush/Refactor! key, and choose Combine Conditionals, which gives me this (sans redundancy):

          if (!leftSideIsWhiteSpace || rightSideIsWhiteSpace)
            ea.Satisfied = true; // On an empty line.
          // Text to the left. 

    Nice. :-) Now I can manually combine the comments into something more meaningful, like "// Text to the left or on an empty line" and I'm done.

    I will be back soon with previews of what's you can expect in 9.1, including some powerful sweet fun code creation and navigation features for HTML developers. And after 9.1 is out I'll return to the Science of Great UX blog series.




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

4 5 6 7 8
10 11 12 13

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, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. 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-2017 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners