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.
Let's provide an example from the end-user's perspective, before we finally end up at how this should impact your software designs:
When you install DriveGauge (an excellent app that shows you how full your hard disk is by displaying a badge on your drive's icon indicating this) it tells you how you have to be careful to install at least one gauge style for the app to work and that you can download those from their web site.
It then goes on and transparently installs DG plus the default gauge style for you anyway.
*bonk* Think about this from the user's point of view: To most users that aren't total geeks like you or me, software is simply a solution. Hard disk is always full? I want it to show me that in a prominent place, so I remember to back up and delete some of the junk that's accumulated. This installer just bombarded me with a ton full of useless information. It even confused me, because I first thought I still had to download and install some gauge style, while the app already did it. Why do I need to know about internal implementation details that could have easily been encoded as a few checks and one error message in the application itself?
Don't show this info in the installer, but rather, have the app's delete command complain when you try to delete the last style. Most users will probably just use the default and never even get to see this code. They will just see the app works and be deliriously happy, and maybe even thankful. Moreover, they get the info about why they can't delete the last style when they attempt to do it. By telling them during installation about something they may or may not do in a few months, you're risking they have forgotten about this detail by then, and thus you're only causing more support calls, not less.
Note that I'm not advocating that installers hide all the details away from the user. I think every installer should have a button that lets you see at a glance what it will be doing. But this information needs to be filtered: Most users who want this information, want it to find out about any security issues your app could theoretically cause on their critical system. So, include what you add where, where any backups of modified files will go, and what permissions your app changes or applies to installed files. Tell the user if an internet connection is needed for some of these files.
But most installers these days are either secretive or kind of autistic: They don't tell you at all what they do, or include a full transcript of every cd and ls command they perform. Users that know about permissions usually know how to change them. So, just telling them the high-level action you performed and how it's relevant to their system should usually be enough, (e.g. group all changes to one file in a single entry). But note that progressive disclosure is important here: Most users won't care about this information, so don't confuse them with it. Those who do care will be able to click a button to show it.
A less obvious case of how application UIs can be talkative can be found in many powerful applications: They provide lots of options to customize their behavior (like Matthew Thomas illustrates in Point 7 of this article). While this is in general a laudable thing, most programs contain more parameters in their algorithms than actual settings. Most programmers are tempted to just expose all those parameters. After all, there may be someone who really needs to customize that one aspect you didn't think of.
However, the more stuff your preferences dialog contains, the bigger will be the hurdle for new users coming to your app. And you don't want that, because new users mean additional sales, and additional people who buy updates (or additional geek credit, or whatever scientists find out is the motivation behind open-source authors). So, how to find out what's a setting that the user will want to work with, and what's a parameter that can safely be left un-exposed?
While there's often no 100% answer, there are some indicators that something is a parameter, and not a setting (and only settings should be exposed to the user through the GUI):
In general, preferences shouldn't be necessary. Often, applications can just do the right thing, thus simplifying the design of your app. The user would ideally only see those options that actually provide a tangible benefit: Margin sizes, colors, fonts, styles... things that people mainly think of when they talk about doing equivalent things in the real world.
- 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.
- 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...
- 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.
- 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.
Apple's installer is usually fairly good in this regard: It asks you where you want the stuff to go (folder or drive), then maybe presents you the license, maybe offers two radio buttons to let you pick whether to do a full or minimal install, and then it'll just do its work.
Or, if you've ever used Keynote, you'll see how well few settings can work in an application: Even though it has all the features you'd expect from a presentations program, it has only very few menus, they're short, and even its floating palette windows are surprisingly simple and clean. There's still room for improvement, but it's proof that you don't have to sacrifice functionality if you manage to eliminate unneeded parameters.
And do you notice how quiet your app suddenly becomes, and how light and fast it feels?
Update: Opened for comments and added an example.
|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.