::scr Editors. Again.

[simon wistow]

On Thu, Nov 01, 2001 at 08:09:38AM -0800, celia romaniuk said:

> Tangentially: asking people about what they want isn't really a good user
> research technique, for a whole bunch of reasons (she said lazily). A
> better technique is to watch how people work and ask them questions about
> what they're doing as they do. There's a really good book on this, called
> 'Contextual Design'.

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.

Text editors are something we use everyday and spend most of our time in
which, I suppose is why people like Emacs - because they don't have to pop out
of emacs to check their news or their mail or whatever and because a
consistent interface is is presented for all those things. 

By using them everyday on a variety of specific tasks we tend to build up
certain repetitive actions - like compiling and examining the output which is
why programmers editors tend to have a function to shell out and compile
automagically and then examine the output and let you jump around.
Programmers' editors tend to be very good in this respect because eventually
they become dogfood - the editor is programmed from within the editor and
therefore a lot of testing is done during development.

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

However once they'd used it for a while I got feature requests and bug reports
and bleating phonecalls from poor little Oxford C16 Germanic Poetry graduates
who'd been hired on the basis of their ability to cast a nice silhouette when
stretching in front of the window saying that they'd accidentally gone past
the delete all button and the variety of warnings and was there anyway to fix
it etc etc so I'd cruft those on and I'd get ... v2.0

Finally, when those requests died down and they seemed to be happy then I'd
take a good long look at the code and mentally remap it and sit down and write
it and release it and get v3.0

Finally, I'd fix the bugs that sloppy programming had introduced into that and
I'd get v3.11 (<- number chosen at random :)


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

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.

On the other hand you do this sort of thing as a job when it comes to
interface Top Trumps your n years experience beats my cod HCI and you win the
stack including the one with Jakob Neilsen  (fear factor : 10!)

 


-- 
: not as clever as i used to want to be