Survex (interface expectations)

[Andy Waddington on Survey stuff]

Andy A says:

> do you think that the majority of this may be getting off the intended
> aim of the list

No, I don't. Seems to me to be entirely about deciding how to make it easy
for new users to use Survex, surely very On-topic for this list. Providing
a really useful and readable manual doesn't seem to help all such new users...

I'll comment off-list to Dave about Word - maybe he can help me :-)

Dave says:

> if you are unable or unwilling to exercise your brain in learning what
> *everybody* else does ...

Dave, you seem to have totally missed the point. I am able, and willing,
and I have always been an avid reader of manuals, readme files, and even
"help". My low tolerance is for people who don't! I don't expect software to
be totally transparent and whilst I prefer to learn by playing around, I
don't give up if I can't do what I want, I look for information in those
sources. It is when I don't find those sources that I then form a low
opinion of the software...

In another mail (which I've only just read after writing most of this)

> it is nonsense to blame Bill Gates for the fact that the Windows version
> of Survex has an 'unusual' method of driving it.

It doesn't have an 'unusual' method (see below). And Bill Gates isn't being
blamed for that. He is blamed for having instituted a culture of not needing
to read a manual.

The point is that many users *don't* look in these obvious sources. They just
ask a mailing list (or usenet group, or whatever) "where's the 'run'
button?", even though useful and fairly complete documentation is provided.
How can that be ? Presumably because they have "learnt" that manuals are
unneccessary, an idea that seems to be promoted to make computers less
frightening (!). A story from a (US) helpdesk seems to sum it up. The caller
was having trouble doing something covered in the first few pages of the
manual (this was back in DOS days) and the patient helpdesker suggested that
reading this would be a useful way to get started. The reply: "I've just paid
$2000 for this, I am not about to read a goddamned manual!". There is no hope
and should be no help for such folk.

Windows and other "modern" software seems to set out to encourage that
attitude, partly by providing a consistent interface to all the applications
for which that common interface is appropriate - and I don't have a problem
with that, since it genuinely helps. But if users then expect everything to
conform to one style and simply cannot cope with anything which doesn't, this
makes it extremely difficult for software authors to develop cross-platform
on desktops with very different idioms, as the Survex authors clearly wish to
do. They provide clear instructions (at least, the ones I have read when
using Survex on other platforms seem to have been developed hugely since they
were perfectly adequate several years ago - it is difficult to put oneself in
the position of a new user, which is one reason why documentation is so hard
to write). These clear instructions should help people to use the software
without tying it down to a counter-conceptual set of menus.

> All we're talking about is that when you load up Survex there should be
> a File menu with options for New, Open, Edit, Save, Save As and a file
> history list. That doesn't seem that contentious to me.

Well, you'll have to forgive me, but it seems totally inappropriate to me.
The beauty of survex is that it doesn't have bloatware to edit the survey
data. That is not its job. You can edit your survey data on any plain text
editor, not necessarily one that runs on the same platform that you are
running survex. You don't need to learn the Survex developers' favourite
editor or be limited with what editing functionality they might choose to
provide when they really want to be getting on with loop closure code or
whatever. Those very same menu items you think are uncontentious are one of
the "windows-specific" interfaces that irritate users coming from a
non-windows background, whereas the idiom of clicking on your .svx file is
an interface that is equally appropriate to Windows, but also much more
natural on some other systems. It is the quintessential cross-platform GUI
way of interfacing a specific-purpose file format with the code that runs
it.

Perhaps your phrase "when you load up survex" is key. Survex is a thing you
run to process some data. An application you "load up" sits there for a long
time whilst you work on some sort of document (a text file, a picture or even
some survey data). Something interactive. Processing a survey is inherently a
batch thing. The "load up" idiom is not appropriate.

Now, a way forward that might satisfy both sides of this argument would be
a separate "veneer" which had those menu items, and when you chose "New"
it would open an empty document in your favourite text editor (which you
could no doubt configure via a plain text .conf file :) and when you chose
"submit to survex" or even "run", it would send the file off to survex, the
command line program, and pop up a "Save as" dialogue for you to choose a
location to save the .3d .pos .err etc. files (whichenver ones you had opted
to generate).

But that is a thing someone else could do - it doesn't need any knowledge of
the core Survex code, and to provide this sort of stuff would be an
inappropriate burden on those who are developing the actual useful
functionality of the code. It would be straightforward to provide a RISC OS
idiom user interface with the FrontEnd module (which could provide a lot of
options not readily available with the current IconCLI front end), there
would be a load of options for Linux (always more choices) and no doubt
handy tools for this sort of thing exist on Windows (I know you can get
Tcl/Tk, for example).

Any user who really wants a "New, Open, Edit, Save, Save as" menu has the
option to write some code - all they need to do is read a manual :-) This
sort of thing seems to be a very common first programming project for many
people - easy front ends for command line code are very common, precisely
because it is easy to split a project into a core functionality chunk (which
the experts in the application can write), and a user-interface chunk, which
an expert in human-computer engineering who specialises in a particular
platform could write. Or, in many cases (judging from what is available)
any old user who can't be bothered typing at a command line could write,
but writing such an interface does mean you need to understand the command
line you will generate, and that seems to be beyond a lot of potential users
:-(

Andy