Re: ::scr Editors. Again.

[celia romaniuk <space@xxxxxxxxxxxxxx>]

On Thu, 1 Nov 2001, simon wistow wrote:

> On the other feature requests are quite useful : usually because they're so
> noticeable because they do interrupt the work flow - you happily typing along
> and you wish you could apply the quux feature repeatedly over all the frobs in
> a window or the ones you've selected by dragging the mouse over them rather
> than having to click on each one and then hit the quux button.

I agree with you. Feedback from people who are actually using
the darn thing is really useful. If you're using something every
day, you're bound to have a pretty good idea about what can be improved.

You can't rely solely on this type of feature request, though. Firstly,
there may be problems that you don't notice anymore because you habitually
work around them, or forget to mention for whatever reason.

Secondly, the quality of feature requests will vary.  See, one person may
send in a feature request that turns out to represent a significant
improvement, but others others may send in idiosyncratic requests, and
others with good ideas may not make any contribution at all. So you need
to collect data from lots of different sources, and you need to prioritise
it.

I assume that people here are familiar with the 80/20 "rule", which says
that 80% of the people only use 20% of the features. Sometimes, as a
designer, you can cut functionality out all together by establishing that
it doesn't further the needs of users or the business. Sometimes, though
(especially in the case of software that is used to perform complex tasks,
such as Photoshop), you can use it to structure and prioritise
functionality. 

If you don't prioritise, the interface becomes crufty and simple tasks
become difficult to perform. But it is possible to achieve interface
depth, as Piers discussed in his mail this morning, by seeing the
interface as something that is structured and, er, deep.

So, relying on ad hoc feature requests is problematic because your
chances of prioritising well are slimmer than if you try and consider
the system, and the needs of its users, as a whole. 

Some argue that this is the why a lot of Open Source software suffers from
clunky interfaces and poor usability. Um,I can't find any references right
now.
 
> Asking people what features they want when you design something from
> scratch has always been a mare for me - especially since I've usually been
> trying to design more marketing idiots who wouldn't actually even bother to
> sit down and talk to me about it. Consequently I delivered a product that was
> useless. v1.0

Yes, it sucks when that happens. One of the biggest parts of my job is
actually about wangling my way into spending time talking to the right
people, about the right things. It's surprisingly difficult to do...  
especially surprising when the agencies you work for cite "user
experience" as their Unique Selling Proposition. *cough*.

Marketing people are especially bad when it comes to features, because
they're used to thinking about what will sell, as opposed to what is
needed and suitable for use.

> Hence one of Brook's many laws - "Always plan to through the first two away"

I like to go with "measure twice, cut once", myself, where the measuring
involves building and testing prototypes. I really should go read Brooks,
though - it's been sitting on my shelf for months now.

> Anyway, that's diverged slightly off the point but what it amounts to is that
> once a product is in place I think that there's room for feature requests in
> product design especially among people who are largely intelligent and at
> least aware of both basic interface design and the problems in programming
> some things.

I agree with you completely.

Celia