Not necessarily. Some are needs, some just wants. Software should offer solution to user's problem, not features. Often features are wanted just because user has a particular vision of solving his problem which requires these features, but that does not mean that there is not more elegant way to solve the problem with less features.

> I'm afraid UI/feature minimalists will never understand why on earth so many people will pay $650 (or whatever) for MS Office, the mother of all feature monsters.

I am afraid many who paid for MS Office won't know themselves. And I bet many of those still use spaces instead of tabs in Word :(

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

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.

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.

They focus so hard on elimination, that they don't add back things that the other apps do not have.

AND they think that they will still have universal appeal. They don't consciously say "OK, we are going to remove these features, because we don't want to serve this type of customer... which will make us more appealing to another type of customer."

They just think that less === more, and that's it.

Just like any dogma, people cargo-cult it. They use it as a mantra without understanding why.

FWIW, my app was one of the ones featured -- Freckle Time Tracking (http://letsfreckle.com/). They wrote:

"Freckle just makes you want to keep track of your time. The conveniently condensed interface shines with energetic color, turning a routine task into something fun."

And that, in a nutshell, is much of what we tried to achieve with Freckle. Our key feature? Take away the pain. Take away the guilt. Make it effortless, and dare I say it, fun.

We don't have everything, by choice.

Do we have fewer features than Harvest? Damn straight.

We don't do time sheet approval. We don't do pre-approved tasks. We don't do any kind of extreme permissions control.. anyone in the account can create new projects, for example.

Our software is built for small teams with a flatish hierarchy, not for traditional iron-fist-control businesses.

That is LESS with a purpose.

For our customers, that's not a "lack of features" -- it's a downright BONUS. Because they have a small team, or are by themselves, and so having to set up tasks in advance (like in other software) actually reduces their ability to work effectively.

On top of all those removals, we've added back things that nobody else does. Time entry on every page. The Pulse, which helps you identify your work patterns. Saveable reports.

Even most of the people who cancel their accounts write us that they love the app and they're sorry they have to cancel.

So I certainly feel we're doing something right. We don't want to be Microsoft Word. Our goal isn't just to make gobs of money, or even dominate the niche. We want to build software that fits our philosophy and makes people happy.

We have a smaller audience, yes, but it's an audience who agrees with our principles.

But do you really think that the only way to make one group of users happy is to simply exclude functionality that would make another group of users happy? Is this an unsolvable problem in your opinion?

I tend to agree with TomOfTTB that it is a UI challenge that can be met.

I didn't take a mental image of a time tracking app and then remove stuff. I started from scratch.

Different groups of people have different use cases, and different needs. It's a fallacy to think you can design one thing for all people. It compromises your vision.

Make sense?

And yes, by the way, there are lots of things we are able to do with Freckle because we have decided paths that we do not want to tread. For example, project creation is always on-the-fly. It's so elegant I could cry.

But if we added permission restrictions, based on who could create projects, that would take away the elegance, and add confusion.

In the end, our approach -- which is awesome for our desired audience -- would be totally compromised by the additional error-checking and rigamarole if we were to add this as a feature.

Thus, we won't do it. There are plenty of people who don't need or want that, who are our potential audience. And people who do need it, won't like the other assumptions our app makes. They will be better served by more traditional products.

To my mind, this is win/win/win.

To me this discussion sounds like an argument for user controlled scripting languages in web applications.

This is needed since web applications which use lots of Javascript can't be automated by normal web scraping libraries with no Javascript/DOM emulators (they support cookies, etc so they can do sessions etc).

Something like the classic Applescript, for user control. (Or maybe the latest web frameworks already have that?)

Edit: Reformulated sentence for clarity.

Edit 2: I think the plugins for Firefox etc are too hard to write? Maybe you could add scripting languages to them?

I think ahoyhere has alluded to the reason why the pile of features tends to win, and that is because it is better at leveraging the economies of scale in the shrinkwrap software business. It is so cheap to distribute software that you are much better off building for the mass audience. Now the hot thing is webapps which do not scale nearly as well (but avoid most of the junk that comes with shrinkwrap scaling, like having to deal with a strange machine and a crappy OS that deluges the end user in spyware, or pushing updates to users you don't know much about), so there is more incentive to meet the needs of a niche audience. And Apple is having some success sort of splitting the difference (vertical integration from the hardware up, and attempting to exert more discipline on developers to increase quality, all at the expense of distributing software to mass audiences). Microsoft, of course, is still in a pretty dominant position from exploiting this scaling to the max when IBM so graciously made the hardware into a commodity mass market item.

So far, the most successful web app (Google) is the one which has made web app discovery scale like nothing else (every page with useful content on it is a web app - code, data, it's all the same). The brilliance of Google is that it captured a mass end user market with a minimal user interface. They did it with math (maximal leverage of plain text queries plus the structure of the web, and similarly with ads which have simple interfaces at both ends and are backed with sophisticated algorithms), and scaling by imposing unusual amounts of internal discipline on the best developers they can get (and they can get pretty good ones). All this just to get to a position where they might be able to compete with Microsoft as a platform, and unseat the power of shrinkwrap scaling. I think the only way they can do it is by attracting a lot more developers than Microsoft, and the only way they can do that is by taking a lot of Microsoft's developers away. They might be able to do it, but there are all sorts of challenges. My guess is that what will happen is that they will draw a lot of developers away from Microsoft, and in the process they will lose a lot of their external cultural influence as far as being able to promote clean interfaces. Web apps will be even more dominated by the everything in one place aggregators (exemplified by Amazon and eBay) than they are now.

The problem with nice UIs is that there just aren't enough good developers to make it scale.

1. No one will do it.

2. Even people who do know how to program have a special aversion to JavaScript, especially.

3. Almost no one is equipped (or willing to invest the time/effort) to analyze their work and come up with a process that is best for them.

A typical person is about as self-aware as a box of rocks. Even particularly smart, savvy, successful people. It takes a lot of work to get real insight out of them in terms of work processes. And impossible to get them to generate novel ideas for solving those problems.

More importantly, to design great software you have to understand not just business processes, but software itself, and the human animal (psychology, sociology).

That is an extraordinary amount of extra crap to expect somebody to do, when they just want to get their work done.

This is born out wherever you see "lay people" creating their own solutions. Ever worked in an organization that powers itself on Excel? It's not only not pretty in a technical sense, but they never, ever, ever do a good job, even within the constraints of what is possible with Excel. And they also never think to question if there could be a better way.

So, that's what people like me are FOR.

All this crap happens to be my passion.

Consider that the scripts would run on the web server. That means they would be published and used by other users... (After a bit of analysis, so they don't do anything destructive.)

And charge money from users that really want their scripts to be private.

Just make certain that there is a script language defined for the web app framework -- and an extensible object model for the local web site's data. (Again, Applescript. But not that syntax!)

Why?

This would be a way to add functionality (and possibly to integrate with other services, so you e.g. could do "legal" XSS.)

Don't worry, we're working on our invoicing attack plan. And marking reports as invoiced is step #1.

Our #1 feature request has been a timer, and we built one. (Have you tried it yet?)

#2 is invoicing. We're building that next :)

It's just a little bit slow because A) I am a perfectionist when it comes to defining the initial approach (and it serves me well), and B) we're doing the part-time 37signals thing.

But we will get there... soon, hopefully!