How Much Personalization Should Your Software Support?

In my last post, I took a look at one specific element of the design in Windows Vista. My intention was to explore two themes that I think this one small example illustrated well: the importance of telling a consistent story well, and the importance of understanding the human emotional response to a user interface.

A couple of comments targeted particular pet peeves about the particular design element in question, which unfortunately wasn't my target because I don't really have the ability to change it with anything more than a bug report (which I am happy to submit on behalf of my readers), but it makes for a good discussion nonetheless. I want to focus in on one in particular, because I believe it really targets a broader and more interesting discussion on user interface design.

Dispite the fact that it makes sense (in a small way it does), there should be an option to allow for being either still transparent or opaque when maximized. I believe one of the many reasons that some/alot of people don't like Windows is because there's not enough customizable options. Sure, there are some, but there are options unavailable where they should be; such as the example you just emphasized. When comes to the UI, judging from working with computers for 15 years, people want it to be 'fully' and not 'partially' customizable (remember something called Linux :)....'nuff said.

I want to dissect this assertion because it gave me some interesting things to think about.

First, there is a hidden claim, assumed to be true, that "some/alot of people don't like Windows." If we want to try to understand the reason why something is true, from a scientific perspective, we first want to understand that it is true. And what do we need for that? Data. I have not seen a scientific study that sought to determine the emotional response to the product, and how people feel while using it (although for all I know this could certainly have been done many times over). Note, however, that the emotional response to the pure aesthetics can be divorced from the emotional response driven by daily usage. What looks startlingly beautiful in a screenshot may be overbearing and annoying during constant use. Remember the Pepsi challenge, where people reacted strongly to the sweet taste of Pepsi in a sip test because we are evolutionarily programmed to favor sweet things; in higher quantities (read: normal usage - when was the last time you drank 2 ounces of our soda and tossed the rest away, not craving another soda for a few days?) the data looked significantly different.

For the moment, let's overlook this assumption. After all, if everyone already had a perfect emotional response to Windows, we wouldn't be working so hard to make another one, would we?

The larger claim is making an assertion as to why this might be the case, zeroing in on customization. This comment suggests that it's just not customizable enough. If I flip through the options in Windows, I see a whole lot of customization. Tons and tons of it. Control panel applets that branch into more specific applets, many of which offer a popup advanced window that can even allow you to change the behavior of the power button on the start menu differently depending on whether or not you're running on batter power. A host of options in gpedit.msc that can even be deployed across an entire enterprise. Raymond Chen's famous TweakUI. There is a LOT of customization available. And with it, a huge amount of complexity.

So, if we want to take anecdotal evidence, my experience is completely different. Until this comment, I have never once heard somebody suggest that lack of sufficient customization was an issue in Windows whatsoever. In fact, complexity (which is what customization necessarily brings) would be one of the biggest issues. Reliability. Security. All of which the team is working hard on in Windows Vista. But never once customization. Similarly, I have never once heard somebody who uses one of our competitors' products claim that they do so because of the customizability of the product. John Hodgman has never once been ridiculed for not being customizable enough. (Incidentally, if you are a Daily Show fan, be sure not to miss Ed Helms' on-scene report on Microsoft.)

Without any detailed research findings exploring motivation behind purchasing decisions, let's instead just go through a thought exercise around customizability and personalization. I am not limiting this to Windows, mind you. After all, you probably don't design and implement the UI for Windows, and neither do I. Rather, let's take the general case. For any software that you or I may write, how personalizable should it be?

How many personalization knobs and switches should you have?

We tell you to provide personalization in your applications. "Because of their widely varying skills and preferences, users must be able to personalize aspects of the interface." It is easy to interpret this statement as being as sweeping as it sounds, and honestly I do not know the intent of the author. However, I would be cautious about taking this statement too far.

First of all, even being the most sophisticated user of an application does not necessarily endow you with user interface design skills. To quote Jef Raskin, "The central point of this issue is that if we are competent user interface designers and can make our interfaces nearly optimal, personalizations can only make the interface worse."

It is also important to consider the ramifications of extensive personalization. Jensen Harris discusses how personalization can lead to a degrading user experience with Microsoft Office in his blog. The user must learn both how to use the software and how to personalize it, and personalizing it frequently does not lead to increased productivity (particularly if you begin with a nearly optimal design). Documentation becomes harder to create. Screenshots may not match what you see on your screen. If you are trying to walk a friend through using the software, you may direct them to use a feature which has been customized to be hidden, so now you not only have to help them learn how to use that feature, you end up teaching them how to use the personalization features before you can even get to that. If you end up accidentally personalizing, you can be left in a mode you simply don't know how to get out of. There are important side effects to consider for providing personalization features.

Of course, the counter argument is that your "personal" computer really should be personal if you want it to be. While most people want their operating system to really fade to the background and not even be noticable (which is what Windows Vista strives to do - your applicaitons should be the focus) and don't give it a second thought, there certainly is a percentage of the population that wants their operating system to shout loudly a personal statement about them. I have intermitently been among this group, so I get that. Stardock sells their Object Desktop line of products precisely to fill this need. And I think this makes for a very complete story. Most people want to have a modern, crisp UI that does the job well, feels nice to use, and really does a good job of staying out of the way because they don't care about their operating system, they care about their work or their fun. For those that want bling, we have partners who deliver.

What does that mean for our applications? Well, if we are designing line of business software, we should design our software to be optimized for the task at hand. (Not that they should be ugly - being optimized for the job at hand, to me, implies driving as positive an emotional reaction as possible, and not just providing the correct number of input boxes.) If we are designing commercial software for consumers, we should take the same route, but we may also want to consider which personalizations may add value. And, once we have done that, we really need to make a well designed personalization system and account for the time to document and explain the intentional modality we have introduced. Windows Media Player provides an interesting example. The documentation will always refer to the full sized window. You can make an arbitrary skin that looks like a giant eyeball, but you can always press the "get me out of this wacky eyeball mode" button and find yourself back in a state that completely matches the documentaiton. And, personally, once the full mode had a well optimized UI, I never went to skin mode again.

Comments (7)

  1. Dean Harding says:

    I agree. It’s usually a tenet of your typical OSS developer to provide tones of customizations. But that’s really just a side-effect of "design by committee" – they couldn’t decide on how to present the UI to the user, so they add an option to switch between two (or more) different UIs. I completely agree that an optimal design shouldn’t need too much personalization.

    By the way, I also agree with your last post about the glass. One of the biggest changes I’ve noticed between how I use Windows XP and how I use Vista is that in XP, I run with most of my windows maximized, but in Vista, it’s mostly in the restored state (the exception has been Visual Studio, but almost everything else – explorer, IE, Word – they all run in the restored state).

  2. B says:

    There are many more types of `personalization’ than funky color schemes. Many are aimed at improving a design that is suboptimal for a given individual user. You seem to imply that the default can be close to optimum out of the box, but everybody’s eyesight is different, so there is no universally optimal font size—everybody has to set their own. Similarly with many less obvious details.

    I have a strong preference for control keys over the mouse, because I’m so lousy with aiming mice, so I want to be able to map a ctrl-key to everything; other people are keyboard klutzes and shouldn’t have single-accidental-keystroke access to most commands. On what you will probably call a quirkier note, I find title bars annoying: I can work out for myself whether I’m using the word processor or the browser without a label, thank you. On a Linux box, I can claim that real estate back, which means that the OS has truly gone away, with zero screen elements. I could probably bore you all day with other personalizations that make my experience more comfortable and productive without adding an ounce of bling.

    You’re probably right that all those UI boxes are a mess, but that’s an argument for why the Everything Must Be a Dialog Box paradigm is broken, not that personalization adds confusion. I think Firefox gets this right with its about:config screen, which is plain old text with a search box. Firefox has hundreds of little customizable details, and they just keep adding more, but the plain text format keeps the on-screen cruft to a minimum.

    Anyway, I have no answer to the Right Amount of Personalization, but personalization is essential when working with humans with different preferences and abilities, and it can be as much about productivity as about bling.

  3. cquirke says:

    Data and installation locations should be customizable; in fact, anything that is > 50M in size or creates/holds code should be relocatable.

    That’s because not everyone will be using MS’s data location model of the day.  For example, I like to keep C: small and fast, D: even smaller and containing only user data, while large bloaty stuff goes on E: and risky incoming stuff goes in a particular subtree in E:.

    That means I can automate complete backup of data on D:, which should be safe to restore.  File corruption generally happens on file system writes, so keeping data away from incessant C: write traffic improves the odds of survival.  And no matter how full E: gets, or fragmented C: gets, most traffic will be within the small C:’s range of head travel.

    All it takes to botch this, is one dumb-ass app that hard-codes its locations, mixes code with data, dumps tons of never-used pre-install material in C:, etc.  

    A prime example of a hardwired C: bloater; %WinDir%Installer.  For every OS code file, you could have 2 or 3 inactive versions lying around – and that’s before Inteller’s copies of stuff that isn’t supposed to be installed on C: at all.  

    I can’t imagine any other performance-sensitive hardware resource that is squandered so pointlessly.  We strive to keep the CPU always active, RAM always filled with useful stuff, etc. yet the thing that keeps us waiting the most, is hard drive head travel (during which no data flows to or from the disks).

    Can one shim %WinDir%Installer to an off-C: location, such as local HD volume E: or F:?

  4. cjacks says:

    You can use CorrectFilePaths to redirect from %windir%installer to wherever else you want, but it’s applied per app rather than to the directory. You could create a link if you want it to go elsewhere and that would apply to anything written there from any process.

  5. cquirke says:

    Thanks, Chris… I’d prefer Installer to be a redirectable shell folder, though there may be safety risks associated with that (malware redirects?)

    The problem’s going to get worse, as MS encourages app vendors to use .MSI-based installers.

    As it is, I’ve been using an F:STORAGE subtree for trusted "cold storage" (pre-installs, etc.).  The only other thing in F: is F:BACKUP that contains the last 5 auto-.ZIPs of D:DATA; F: is intentionally smallish and located at the "slow end" of the HD.

    The other problem with holding Installer on C: is that it’s likely to share the same fate as the code it is supposed to be "backing up" – though I’ve seen worse  🙂

    THE worst software self-backup I’ve ever seen, is a local business package that creates a directory within the "live" data directory (hard-wired on C:, naturally) and then creates new backups of the data there.  It *never* purges the old ones, so you end up with 300M of "live" data and 3G of accumulated backups… so eventually, C: runs out of space and the data does get broken.  Break the directory holding the live data, and bye-bye backups too.  Grr!

Skip to main content