::scr Editors. Again.

[Piers Cawley]

Chris Heathcote <chris.list@unorthodoxstyles.com> writes:

> celia wrote:
> 
>> 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.
> 
> Individuals want strange things. Some will be quite useful, others will be
> incoherent and stupid (I want to turn all the text to flames!), it's
> someone's job to turn this into a coherent strategy.
> 
> Piers wrote:
>> So we get a bunch of RFCs that are, to put it
>> mildly somewhat incoherent.
>> 
>> So we rely on Larry.
> 
> Indeed. I've got a great book about this kind of design - "The
> Inmates Are Running The Asylum" - which basically states that
> computer people and marketing people are equally inefficient at
> judging what's good for a software product and users as a whole.
> Most usability books tend to allocate a role of "user advocate" to
> ensure that everything is on track, and that features aren't added
> or deleted on a whim.

Yeah. And just to underline this, the person who gets stuck with the
job of doing the synthesis MUST be trusted by all the parties
involved. In the Perl 5->6 push, we have the advantage that we've got
used to trusting Larry with Perls 1-5, and he made those changes with
(by comparison) almost no input. 

And it's (understatement) not an easy job at all. To do it well you
need to keep a ludicrous amount of state in your head and then follow
through the consequences of change. Which is, I suppose what we do
when we're programming anyway, but designing something as open and
flexible as a language (or any other 'sufficiently powerful' tool) is
a whole order of magnitude harder. 

Coming back to PhotoShop, my other favourite example of 'deep
interface', look at the effects that the Non-linear history palette
had on working practices. I can only speak for myself, but the
possibilities for 'exploratory' editing that this opened up, with the
ability to hang onto snapshots of interesting places in the trousers
of photoshop time, combined with the history brush that lets you paint
stuff from one leg to another... well, it's just wonderful. The only
catch is, there's no option (in PhotoShop 6 at least) to save that
history session state when you save the image; if you need to keep it
hanging around you either have to save your snapshots into working
images, or leave the session open and hope that things don't crash.
Good job the basic app is pretty stable...

Anyway, my point here is that on one level non linear history is just
a faintly arcane feature (and you have to explicitly turn it on)
that's presented to the user in a wonderfully simple, intuitive
fashion, but once you grok it, it becomes 'obvious' and dramatically
changes the way you interact with the tool. Christ alone knows how
much programming effort went into implementing the feature. The beauty
of it is that it doesn't show. 

The other weird thing about non linear history is that it doesn't
appear to have been an idea that had occured within the user community
before Adobe implemented it. Everyone had been saving interesting
intermediate images, and occasionally thinking "There's got to be a
better way", without necessarily coming up with that better way.
Presumably someone in Adobe looked at the problem and had an 'Aha!'
moment. 

And for me, that's what makes for a good interface. Someone has that
moment of inspiration and comes up with a seemingly simple and easy to
understand extension to the interface that enables whole swathes of
functionality. When I've discussed the Perl 6 redesign I've found
myself talking about wanting a language/tool that gives me big levers
and rock solid places to stand. Too many things give you either loads
of levers and nowher to stand or copious amounts of solid ground, and
a toothpick as your only lever.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?