Not true, because his users needed those features and then they should be in the final product. "Requirements creep" ideally shouldn't happen in a well designed product, because all requirements (and a complete reference of all posible interaction with the software) should be made before writing a single line of code (and thus the final users should already have added everything that they wanted in the product).
"Intuitive" is not the same than "easy to use", althought this is an error frequently done. Intuitive is synonym with "familiar", and no entirely new product can be familiar; this is especially true with new technologies. The problem with most software interfaces is that they're bad even when you get familiar with them.
Maybe the article is not well written, but the point it makes is a valid one.
The problem is not only in learning how to use a new kind of product. Most current software is terrible even when you already are trained to use it. Think of a car which needed to go through a "next->next->accept" wizard every time you wanted to shift gears, and maybe you will get what is the problem.
A good UI designer surely would tell you that, if the user want feature Y configurable, it means that it's badly designed. It should be taken away and the whole interface redesigned to achieve the same result of feature Y with a different interface.
User interface designers shouldn't think of features, but of goals and tasks. When you design software to solve a task under some given constraints, a "best solution" should be fairly clear to develop. If different people have different constraints, they probably need different tools.
So, you're saying that your product wasn't designed to meet its user's goals. I would call that a badly designed product, and bad engineering practice.
It's very sad that engineers are not also taught to test the interface with real users, because both skills are indispensable to write good usable software.
And, for people really interested in learning about the basis of Human-Computer interaction beyond the WIMP ("Window Icon Menu Pointer") paradigm, check out Jef Raskin's "The humane interface".
And most important... don't forget to test your cases with real people performing the task. Testing with real users is the best possible advice to follow when designing user interaction.
Also don't forget that, most of the time, the way that an user thinks about the application (the user "mental model") is really different than the designer's mental model.
Sad thing that software developers tend to follow the opposite advise: "Make it easy to do what is easy to program". It's the biggest mistake in interface design, bar none.
This should send a message to all open source developers that feature bloat is not at all an indicator of better software. It is best to have a right, balanced set of features with well chosen defaults and, only when possible, easy extensibility.
And configurability is NOT a good thing to have in software; interaction should be designed according to cognitive principles. When the interface is designed to assist the human mental resources, it is easier and better to retrain that to configure the interface to old habits. Hear, KDE?
my understanding of the concept of a limiting value is that the sum never reaches the value.
Yes, but 0.9999~ doesn't represent the sum of the series, it represent the limit, which is 1. This is kind of a false debate; truth is that 0.9999~ = 1 by definition.
Try Photofinder, from the HCI Lab in the University of Maryland. It's experimental software, not commercial, but I've found that it have some very interesting ideas on storing and retrieving a big collection.
The word you was looking for is "declarative": in Prolog and Make you state rules on how to transform your original data into a solution; the order in which those rules are combined is up to the language and not known by the programmer.
On the other hand, an "imperative" language is a sequence of commands to the machine; it can be interactive/interpreted like Python, Basic, Perl, or compiled, like C, Ada, Pascal.
Descent was too difficult to handle, too an "alien" experience. This hurted its gameplay, because the learning curve was too high. But it was a good game if you spent time learning to play it.
Not a language per se but a Perl dialect, Lingua::Romana::Perligata allows you to program in something that strongly resembles Latin (that is, if you don't know real Latin to tell the difference).
Slashdot Mirror
Not true, because his users needed those features and then they should be in the final product. "Requirements creep" ideally shouldn't happen in a well designed product, because all requirements (and a complete reference of all posible interaction with the software) should be made before writing a single line of code (and thus the final users should already have added everything that they wanted in the product).
"Intuitive" is not the same than "easy to use", althought this is an error frequently done. Intuitive is synonym with "familiar", and no entirely new product can be familiar; this is especially true with new technologies. The problem with most software interfaces is that they're bad even when you get familiar with them.
The problem is not only in learning how to use a new kind of product. Most current software is terrible even when you already are trained to use it. Think of a car which needed to go through a "next->next->accept" wizard every time you wanted to shift gears, and maybe you will get what is the problem.
Sorry for the link, it should be this.
User interface designers shouldn't think of features, but of goals and tasks. When you design software to solve a task under some given constraints, a "best solution" should be fairly clear to develop. If different people have different constraints, they probably need different tools.
So, you're saying that your product wasn't designed to meet its user's goals. I would call that a badly designed product, and bad engineering practice.
It's very sad that engineers are not also taught to test the interface with real users, because both skills are indispensable to write good usable software.
And, for people really interested in learning about the basis of Human-Computer interaction beyond the WIMP ("Window Icon Menu Pointer") paradigm, check out Jef Raskin's "The humane interface".
Also don't forget that, most of the time, the way that an user thinks about the application (the user "mental model") is really different than the designer's mental model.
Sad thing that software developers tend to follow the opposite advise: "Make it easy to do what is easy to program". It's the biggest mistake in interface design, bar none.
Dave, from "6 feet under" is not that bad.
They have a page with Frequently Raised Objections. Now I've made redundant 40% of the remaining posts to this article.
Or, the editor could have provided a link to the previous story, which she hasn't.
Probably you're referring to the APIs, and grandparent is referring to runtime configurability options.
Sorry I hadn't any mod points today! X'-D
I feel that good education (and good healthcare) are things that would truly benefit the country as a whole.
That is what is usually called socialism.
Grandparent's I do not consider it my responsibility to buy computers for your wife's school.
That's called libertarianism.
This should send a message to all open source developers that feature bloat is not at all an indicator of better software. It is best to have a right, balanced set of features with well chosen defaults and, only when possible, easy extensibility.
And configurability is NOT a good thing to have in software; interaction should be designed according to cognitive principles. When the interface is designed to assist the human mental resources, it is easier and better to retrain that to configure the interface to old habits. Hear, KDE?
my understanding of the concept of a limiting value is that the sum never reaches the value. Yes, but 0.9999~ doesn't represent the sum of the series, it represent the limit, which is 1. This is kind of a false debate; truth is that 0.9999~ = 1 by definition.
Try Photofinder, from the HCI Lab in the University of Maryland. It's experimental software, not commercial, but I've found that it have some very interesting ideas on storing and retrieving a big collection.
The word you was looking for is "declarative": in Prolog and Make you state rules on how to transform your original data into a solution; the order in which those rules are combined is up to the language and not known by the programmer.
On the other hand, an "imperative" language is a sequence of commands to the machine; it can be interactive/interpreted like Python, Basic, Perl, or compiled, like C, Ada, Pascal.
Descent was too difficult to handle, too an "alien" experience. This hurted its gameplay, because the learning curve was too high. But it was a good game if you spent time learning to play it.
This article in Ars Technica is the reference for the Spatial Finder that the guys in Gnome used as inspiration for the new Nautilus.
My nickname is chosen after the fact that I am gay and I admire Alan Turing.
There is a blog, Gaygeeks, in which Turing is a well-known hero.
Not a language per se but a Perl dialect, Lingua::Romana::Perligata allows you to program in something that strongly resembles Latin (that is, if you don't know real Latin to tell the difference).
Well, according to the Attention Economy principles, you're doing M$ a favor.