Talkative, chattering UI

During a discussion on the GNUstep-UI mailing list, I remembered a user-interface-related topic that I haven't seen covered much yet: I call it talkative user interfaces, but sometimes it's covered under the more generic topic of cluttered user interfaces, or simply under featuritis.

Featuritis is a problem that especially GNOME and Mozilla used to be known for, though both have these days made great inroads into fixing this. But I'm going to focus on a less noticed aspect of this, on a smaller scale. In the process, I'll find myself going head-to-head with the Linux hacker ethic of more settings = more power to the user. While I agree that flexible, extensible and configurable apps are usually better than ones that force you to do things their way, there is a balance to be held.

Talkative Installers

Talkative Preferences

1. It can cause an invalid state - If two of your preferences can be set up so they conflict with each other and cause your application to work wrongly, or even crash, they are parameters that should be grouped into one setting. Ideally, the user should never be able to specify an invalid combination in the first place.
    
2. It heavily depends on another setting - This is along the same line as #1: If one setting completely changes its meaning or value range depending on another, you are likely dealing with two parameters that want to be one setting. E.g. If you had sliders that manipulate block size and page size, the latter of which must be a multiple of the former, use an equation like page size = block size * N, where changing block size would transparently change the page size, but the user would only manipulate block size and N. Or sometimes you even have a fixed relation between both settings, where you can just have one slider that sets the cache size to page size * 2...
    
3. It depends on the user's system setup - This applies to e.g. cache sizes, turning on optimizations for a particular type of CPU etc. Ideally, your application should be able to just detect that particular CPU using Gestalt() or intelligently increase cache sizes as needed. The user shouldn't have to care about this.
    
   Obviously, there are exceptions. E.g. if your app is a compiler, the program generated may not be destined to run on your computer at all. In that case, any decision made based on your system setup could well be wrong. But then again, your compiler could just add auto-detecting code to the generated app, and thus make sure the programmer using it doesn't have to write this code herself.
    
4. It conflicts with your metaphors - The use of metaphors to make it easy for the user to grasp a complex concept in your application requires that the metaphor fit snugly around the behavior the user experiences from your application. Users are used to the simulated pencil tool on a computer being like an ideal pencil or pencil on steroids, but they still expect it to draw dots and lines, and maybe to have an eraser on the back, but if your application conflicts with the typical characteristics of the real-world-source of your metaphor, the user will usually be confused and think your app was broken.
    
   If a setting doesn't fit the metaphor, on the other hand, most people will just leave it alone, because they won't understand what it does (after all, users can't see how it's implemented under the hood). So, effectively, this setting will remain unused, and thus simply constitute dead screen space and confuse new users. In those cases where it is used, people will often mistakenly specify the wrong value and, again, think your app was broken.
   
   Example: A brush tool with a "refresh rect". Yes, internally you may only be selectively refreshing the screen around the parts changed by the brush, but why bother the user? Make it as large as the brush's shape, because that's what the user wants. If you know that brushes beyond a certain size are too large to work smoothly, use a cache or a reduced-quality drawing mode. A good programmer will have a solution that fits, so why bother the user who may not know what a brush could possibly have to do with refreshing something.
    

Good Examples

Aaron Ballman writes: You're absolutely correct. Modern installers tend to bother me because they're either lacking in information when they ask you a question, they have extraneous information that no one cares about (such as a welcome screen), or they have way too much information (der... a EULA?). I think UI design has largely gone downhill in all camps. OSes tend to provide the underpinnings and examples of how NOT to do things (drawers: Mac, Toast windows: Win, etc) instead of leading the charge in making the end user's experience good. I could sit and rattle off numerous examples of horrible UI and never even have to touch on a 3rd party application. My hope is that vendors begin to figure out that shiny and sparkly only goes so far towards making a useful user experience. Ok, I'm done ranting and rambling, I promise. ;-)

Uli Kusterer replies: ★ I just had that discussion with a colleague at work: I guess it's the point of brand identity and marketing vs. usability. If you want to sell a product, it's in your interest to ensure your users have a separate spot in their brain set apart for your product. You want them to think "Excel" not "Spreadsheet". Because otherwise, they'll eventually realize that your competitors exist and that those might be an alternative. OTOH, from the user's point of view, that is bad. You want to reuse as much previous knowledge as you can and focus on your work instead of memorizing logos and brands. In the end, we need a compromise: Brands need to stand back a bit so users can still recognize them even if he hasn't memorized the corporate ID, while users will have to cope with some brand identity, because otherwise the company goes broke and they'll have to switch programs every year. Okay, that's simplified.

Aaron Ballman writes: Yes, but brand identity should never get in the way of the user. For example, with my Nike shoes or my Dodge pickup truck, I know the brand and see them and can identify them, but it's not a part of my user experience with the object. For example, the horn on my truck is a standard-sounding truck horn. It doesn't play the Dodge jingle. ;-) Software companies do some absolutely horrendous things to make their brands stick out in people's minds, and that's why I won't use their products. I enjoy using products that do what I need them to do without getting in my way constantly. So go ahead, stick your logos in the installer. But don't go much further than that -- it's not going to help your cause.