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.
