More broken Apples...
roger.holmes at microspot.co.uk
Mon May 4 06:17:37 CDT 2009
>> To answer the question of why you'd want easy to use software, that
>> really does come from the corporate world. My favorite example for
> My entire post was about differentiating "easy to use" v "easy to
> The corporate push is for "easy to learn", since they don't want a
> training expense for the digital sweatshop.
> Apple's marketing pushes "easy to learn" while calling it "easy to
> "Easy to use" and "easy to learn" may occasionally overlap, but are
> the same for those who are capable of learning.
> Conflation of the two phrases is detrimental to the well being of our
I agree with the confusion being bad. I do not agree with the rest.
Ease of learning is important if you only want to use a program a
couple of times. Ideally you do not want to learn anything, you want
to get a job done and move on and not have irrelevant facts hanging
around in your head for ever-more. Where the Mac UI really used to
score over DOS and old Windows programs is that you learned a
technique which would be valid in every Mac program you would ever
come across, and so was worth learning. It did not matter if the
application was word processing, CAD, 3D, spreadsheet, drawing,
painting, photo retouching, page layout, music composing, video
editing, disk utility or whatever, the techniques were the same.
I find it very hard to get users to read a manual these days. If
facilities are not visible they do not find them. I know most,
probably all, of the people on this list are not manual avoiders but
we are a small minority, to write application software today which
could only be used after reading a manual would almost be commercial
suicide. Quite a few of my users remark that it is so rare to have a
printed manual available these days (we mail it out to users who pay a
small amount for it). We sell mainly via download and also have a
physical product we sell through the Apple stores and elsewhere, but
it has to be a standardised box to fit their shelves, and the box is
too small to fit the printed manual in.
For programs to be used long term I think that user configurability is
the key. There is no point hiding facilities as it makes learning
harder in the first place but once users become experienced they will
know which facilities they use most and can assign them short cuts.
The software designer should not make permanent choices on these,
though an educated guess which can be overridden can save time. There
does need to be a host of features but without impeding ease of
learning, this can be very tricky and itself takes years of experience
by the designer.
Not that my opinion is worth any more than anyone else's.
More information about the cctalk