Tip dialogs and alternatives

[Andy Waddington on Cave Surveying]

On Thu, Oct 14, 2004 at 10:11:10PM +0100, Philip Underwood wrote:

> Life's too short, and reading a book is a pants way to learn anyway.

Actually, its a very effective "pants down" way to learn. Unless you're set up
for wireless and have a laptop that doesn't burn your bare legs, reading
manuals is about the only productive way to use all those hours you
inevitably spend away from the computer screen dealing with yesterday's
vindaloo. Or relaxing in the bath ...

And of course by "manual" I didn't necessarily mean one on paper. Good
help pages are a form of manual, and the most useful one if you are actually
sat at the screen...

On Thursday 2004-10-14 14:14, Mark Shinwell typed:

> I believe that a far better means of delivering help to the user in
> these situations would be to have more interactive information in a
> status bar.  For example, if Aven is opened without a .3d file loaded
> then it could say "Select File -> Open to load a survey" or something.
> Having got a cave on the screen, then the bar could display what the
> mouse buttons are going to do if pressed.  Say that Shift+Left produces
> rotation only, and Left produces rotate+scale or whatever.  When Left is
> pressed, the status bar can change to more specific information such as
> "Hold down Shift to rotate the cave without scaling".  You get the idea.

That does indeed seem a much better way - you are being given information
useful at the time, and you are free to ignore it without having to click on a
"go away" button.

> Things like this are far more likely to be useful than a single tip
> appearing when the program opens.  They'll probably aggrevate
> experienced users less as well.

Absolutely

> Something else which should be done is to put something more useful in
> the "Help" menu -- say to access the manual, perhaps? ;-)  (ahem)

Yes, it does irritate when a help menu has an "About" entry which tells me
who wrote it, but no access to help pages. Or there are help pages that
just say "the manual hasn't been written yet". There's a lot of that on KDE.

I find it helpful to write the manual first, as writing the stuff down tends
to make it obvious when the user interface I'm writing is actually going
to be a pain to use. Doesn't always work, though, and sometimes I have
to scrap chunks of neatly written manual when writing the code throws
up a better way of doing things...  But you inevitably end up with some
stuff you write that goes in the bin, and its often easier on the grey matter
if its documentation that gets wasted, rather than code that took hours
to debug... Also its an embarassment when you write a chunk of manual
and don't get round to implementing the code for a couple of years
afterwards. But it does mean that people can see that you are planning
a feature, and encourage them to nag you if it is one they'll find useful.

And Mike McCombe says:

> Also good to see Olly pushing back on the "computing arrogance"
> that sometimes creeps into postings on this list!

I suspect he means me :-( I think I have a rather more generic form
of arrogance that says people shouldn't use any technology without
some level of understanding of what goes on behind the user interface,
whether that UI is a mouse-and-buttons GUI, a steering wheel and pedals,
or the handle of a tool...

If you write software to be driven by people who really have no idea of
how they would do this without the software, the interface ends up being
so idiot-proof that people who do know a lot about it (maybe because they
were doing essentially the same job back before personal computers
even existed) will find that it just gets in the way.

This is when you have to start thinking about a basic engine to do the job,
and different front-end interfaces for different "markets". Having a command
line program for experts and a great "Wizard" for new users is one example
of this. Having an easy to use GUI for everyone is a nicer compromise, but
which requires more care perhaps. Help has to be available for when you get
stuck, but it mustn't get in the way, either by requiring extra mouse clicks
to shut it down, or by taking up screen real-estate. It's a nice idea to have
cave survey stuff work on tiny handhelds, so minimising screen clutter is a
pretty high priority. But there are many examples of "modern" apps that have
so much clutter and chunky toolbars that they are a pain to use even with
sixteen virtual desktops at 1920x1440 - there just isn't enough screen real
estate (a quick count reveals 72 windows open on this machine - which is
about normal - an average of 4.5 per desktop...).

I'm not suggesting that any of the survex stuff is even close to this,
but all software has to work in a context, much of which may not be of its
own making or in any way under its control. If that context includes a lot
of programs where the user is constantly having to click on dboxes to get
rid of messages she'd prefer not to have seen, then every extra such message
is a genuine distraction. It might be the only such message _your_ program
produces all day - but if its the seventeenth I've had to get rid of in the
last hour on my desktop, then its understandable that I will swear at your
program.

Andy