Thinking through a feature
The commentary after my entry on taskbar grouping drifted into people asking for still more features in taskbar grouping. Writing the code is the easy part. Designing a feature is hard. You have several audiences to consider. It’s not just about the alpha geeks; you have to worry about the grandmothers, the office workers, the IT departments. They all have different needs. Sometimes a feature that pleases one group offends another. So let’s look at some of the issues surrounding the proposed feature of allowing users to selectively ungroup items in the taskbar. One issue with selective grouping is deciding the scope of the feature. Suppose the user ungroups Internet Explorer, then closes all the IE windows, then opens two new IE windows: Do the new ones group? If so, then you now have an invisible setting. How do you configure grouping for programs that aren’t running? (How do you configure something that you can’t see?) Suppose you’ve figured that out. That’s fine for the alpha geeks, but what about grandma? “The Internet is all disorganized.” “What do you mean?” “All my Internet windows are all disorganized.” “Can you explain a little more?” “My taskbar used to be nice and organized, but now the Internet parts are disorganized and spread out all over the place. It used to be nice and neat. I don’t know how it happened. I hate the Internet, it’s always messing up my computer.” What is the UI for selective ungrouping? Anything that is on a context menu will be executed accidentally by tens of thousands of people due to mouse twitching. Putting the regroup onto the context menu isn’t necessarily good enough because those people don’t even realize it was a context menu that did it. It was just a mouse twitch. Mouse twitches cause all sorts of problems. Some people accidentally dock their taskbar vertically; others accidentally resize their taskbar to half the size of the screen. Do not underestimate the havoc that can be caused by mouse twitching. Soon people will want to do arbitrary grouping. “I want to group this command prompt, that notepad window, and this calc window together.” What about selective ungrouping? “I have this group of 10 windows, but I want to ungroup just 2 of them, leaving the other 8 grouped together.” Once you have selective/arbitrary grouping, how do you handle new windows? What group do they go into? Remember: Once you decide, “No, that’s too much,” there will be thousands of people cursing you for not doing enough. Where do you draw the line? And also remember that each feature you add will cost you another feature somewhere else. Manpower isn’t free. But wait, the job has just begin. Next, you get to sit down and do the usability testing. Soon you’ll discover that everything you assumed to be true is completely wrong, and you have to go back to the drawing board. Eventually, you might conclude that you over-designed the feature and you should go back to the simple on/off switch. Wait, you’re still not done. Now you have to bounce this feature off corporate IT managers. They will probably tear it to shreds too. In particular, they’re going to demand things like remote administration and the ability to force the setting on or off across their entire company from a central location. (And woe unto you if you chose something more complicated than an on/off switch: Now you have to be able to deploy that complex setting across tens of thousands of computers – some of which may be connected to the corporate network via slow modems!) Those are just some of the issues involved in designing a feature. Sometimes I think it’s a miracle that features happen at all! (Disclaimer: I’m not saying this is how the grouping feature actually came to be. I just used it as a starting point for a rant.)
For another perspective, you can check out KC Lemson‘s discussion of the feature-design process a few days ago under the topic There’s no such thing as a simple feature.
Light
Dark
0 comments