Why features don't matter anymore

[Textfarm]

'You can't make things easier by adding to them.'

An interesting discussion piece here:

http://www.acm.org/ubiquity/views/v7i07_pfeiffer.html

[Leoram]

I don't agree with the article referenced by Texfarm on features. The author Andreas Pfeiffer wants us to believe that the impact of many features is the same on devices like media players, cameras, etc., as it is in the field of softwares. My opinion is that although we normally want few features on, say, a camera, being that what we expect from such a device is the high quality of the photos by simply pressing one and only one button; in the area of softwares to me is a different arena. When it comes to softwares on the contrary, almost the whole body of users of a program ask the developers for the integration of many features. The more features the better while at the same time taking care of simplicity of design and user-friendliness. This is especially true in the field of PIMs. The user normally feels the need to do many things with the information in his/her database.

Leoram

[Textfarm]

It is precisely this user friendliness that I believe to be at stake. Clayton Christensen (2003) calls it the phenomenon of 'overshooting': competition among providers of technology products inevitably pushes the technology beyond the needs of most customers.

http://www.amazon.com/gp/product/006...56842?n=283155

Therefore, increasing competition in the PIM market may result in what Douglas Coupland calls 'option paralysis': given the multitude of choices, people choose not to choose at all.

I like Ultra Recall a lot, particularly because of its rather unique ability to serve as a text editor/word processor (dictionaries!) on the side. It is the best one I've found so far, and I certainly appreciate the passion and commitment people are putting into it.

But what may hinder its success is the fact that it lacks a sufficiently intuitive interface and, consequently, requires a rather steep learning curve, which may eventually translate into limited market share.

I do hope that Ultra Recall will evolve further into a viable one-stop platform for information management, yet I feel that it is important not to relinquish ease of use in favour of a feature battle that will impress or benefit only very few users. First things first!

[Leoram]

My opinion in response to your marked theoretical but valuable thesis (not exclusively yours as can be seen but also others'), is that the dilemma exposed by you Textfarm, as I see it, is a normal environment of the software developing arena. It is exactly the challenge softwares firms have to deal with. If that dilemma did not exist there wouldn´t be any need to fight for the development of strong technology and for innovation. But I insist in one thing: you have to differentiate between the phenomenon found in devices such as cameras, media players, etc., and the one (and more complex) that exists in the software field. Going further with this idea, I can emphasize that it is precisely the search for innovation and inteligence in design interwoven with feature richness what this dilemma has caused. From this reality have emerged software giants like MS Excel and others that seem unbeatable in their respective categories.

Ultra Recall is a marvelous piece of software in my perception, a true gem of a programme. And has the advantage of being a well conceived management tool from its origen. But what has made this possible is that its developers seem to have envisioned what was really needed in the market of PIMs and have managed to pack a balanced and impressive bundle of features into UR. The set of unique *features* is what has placed UR where it is. I also see that Ultra Recall is backed by a competent and awesome community of followers in this forum whose contributions have really impressed me for the high quality of their suggestions/discussions and I can mention many. This combination can push UR even further in the preference of the PIM consumers.

Leoram

[srdiamond]

It depends entirely on the potential market, which in turn is structured by a company's competition and by its own resources, including personal aptitudes and interests. I don't know enough about cameras to argue the point, but I really doubt that there's no profit to be made producing fully featured cameras that require more than pushing a singe button. In parallel, surely there is also a market for software that only requires a single button press, as shown by the popularity of "set it and forget it" utilities.

[alx]

I think we need to distinguish between features in terms of abilities and features in terms of items on a menu list; the former are the ones we, the users, keep and will keep asking for; the latter are what we usually get, but not necessarily the best solution.

Let me give an example: modern cars have an incredible number of features, but most of them are discretely integrated and don't get in the way. Airbags will appear automatically, when required; a microprocessor may control the air conditioning but you will never need to program it; another may control the ABS, but you will only need to hit the breaks they way you are used to.

This kind of discrete integration is a characteristic of mature technology; in the software field, bloatware signifies immaturity.

Even Microsoft has realised this; Office 12 will have much fewer commands than previous versions. Their research showed that most new features requested by users were already there, but users didn't notice. So Office 12's commands will be different; they will be results-oriented; i.e. rather than manually setting formatting attributes, you'll choose from previewed formats and the program will set the attributes for you. Less is more, but it's the kind of less that counts.

In that sense, I am often pleasantly surprised by Kinook's approach to UR development; I find that the program keeps building power following a well thought-out plan and users' suggestions, but this power is under the hood. New features are added with little impact on the number of menu items.

Take importing; underneath the intuitive drag-n-drop, there is a lot of intelligent processing, but you'll probably never need to think about it. In this thread http://www.kinook.com/Forum/showthre...=5041#post5041 Kevin proposed a solution that demontrates UR's versatility through its template "object-oriented" approach.

All I can say is "well done"!

alx

[Leoram]

I welcome your comment alx. I find it well exposed and balanced. Anyone perusing carefully into it can clearly grasp that your take isn't against the addition of new features in a program. I am also in favor of the notion that the addition of features is something that should be done with "maturity" in mind. In that sense I liked the examples you provided, and I also like the direction UltraRecall is being led towards. I encourage to focus/keep this discussion in a way that would be beneficial and profitable to UR.

I am also against a bloated menu in any program, but lets be clear and reasonable in that simple menus doesn't mean few features. Taking Office 12 (2007) as an example, as far as I've read and understood, MS developers did battled against their huge menues (commands) and now with the new Office they will uncover hidden options to the less powerful users, making those options simpler to be found with the addition of what they call "Ribbon". But lets again be reasonable, the addition of the "Ribbon" is in itself a *feature*. We'll all be discovering that Office 12 might have fewer commands as you stated, but (I would add) not necessarily will have less features. On the contrary, what MS will be releasing is a more powerful suite of Office tools that will be packed with even more features. Hidden ones, maybe intelligently integrated. Take for instance the following sneak peeks on MS Excel:

http://blogs.msdn.com/excel/archive/...23/473185.aspx
http://blogs.msdn.com/excel/archive/...26/474258.aspx
http://blogs.msdn.com/excel/archive/...28/475041.aspx

Lets also be clear that not all features can be or need to be hidden. On the contrary, it is possible that by their nature, some options will demand a "physical" placement in the menu.

I hope this will clarify a little.

Leoram

[srdiamond]

Originally posted by alx
[B]I think we need to distinguish between features in terms of abilities and features in terms of items on a menu list; the former are the ones we, the users, keep and will keep asking for; the latter are what we usually get, but not necessarily the best solution.

Some features, so-called, decrease the complexity of the interface without decreasing what the program can do, and I think these aspects of the program have to be separated from the program's power. Usually--but far from always--when people talk about features, they mean power features, features proper. I would reserve some other term for complexity-decreasing innovations, terms like ease of use or user friendliness--or most encompassing, 'elegance.'

I think the originating post had power features in mind, and I think the premise is true, that at a given level of interface refinement, increasing power comes at the expense of interface complexity. So there's a question of balance between the evolution of the interface and the growth of power. The thread originator seems to be saying increases in power typically overshoot advances in interface elegance. As to UR, does it show imbalance? Personally, I think UR's current interface could absorb substantially more power, and I think there's some temptation to succumb to persistent demands for usability aspects, sacrificing advance in power. But this is mostly just one user's preference.

The idea that software developers augment features and sacrifice elegance--despite what their market wants--is one possible explanation for the tendency for programs to show "feature bloat," but I think it's the wrong explanation. Based mostly on personal observation, I think feature bloat results from the oversensitivity of developers to the demands of specific vocal users and many developers' lack of an independent vision for the product to counter-act this over-responsiveness. Depending on the specific user community, such pressures can alternatively over-develop usability at expense of power--the Macintosh syndrome.