3 ms·
Right, but let's be clear about one thing: If users had a say in which features were included, the number of features would be huge, and these features wouldn't
by TomOfTTB 17y ago
Right, but let's be clear about one thing: If users had a say in which features were included, the number of features would be huge, and these features wouldn't all be just variants that could be educated away. They are real needs. So, not having these features means not to satisfy some user requirements.
Not necessarily. Interaction Design has always focused on profiling users and then using those profiles to expose the functionality that user needs while obscuring the functions they don't. So "eliminating" a feature can just mean having the user set up what features they will use before hand and then using that info the streamline your UI (clearly you'd want some way to change those preferences but that's another discussion)
I think a lot of UI design has gone backwards by ignoring this insight. To give one example, Toolbars have gotten a bad name because developers used them badly in the past. But they had a good purpose which was to allow users to un-clutter their interface by hiding functions they don't use. Now we have Microsoft pushing the unwieldy, homogeneous Ribbon which throws all those confusing features at the user.
But the bottom line is I don't think you need to go as far as taking out a feature just to eliminate it from the sight of a user who won't use it
- fauigerzigerk 17y agoSo "eliminating" a feature can just mean having the user set up what features they will use before hand Sure, but to do that the feature must exist in the first place. The author of the original article makes a distinction between eliminating a feature and hiding it. What you suggest is a clever way of hiding a feature. I'm ambivalent about the idea of hiding a feature based on usage. Microsoft had that idea of hiding menu items that were not frequently used. I don't know anyone who liked that. I always disabled it because I didn't like my UI to change all the time. If I use a feature rarely, I still want it to be where it was last time, not move around until it's seven nested dialog boxes away.
- TomOfTTB 17y agoYou're right about the article I'm just disagreeing. Programs exist to solve user's problems, UI exists to make it easy for the user to discover how to use a program to solve their problem. So UI is supposed to serve the functionality not the other way around. Which is why I think making a program less capable of solving the user's problem based on UI consideration is backwards. As far as the hiding, I'll agree the "menu hide" trick in office sucked but that's sort of my point. Microsoft did it badly so there's this assumption it can't be done. But figuring out how to do it is what UI design is all about. At least, that's my opinion.