backup-files

[josch <josch Rcs1 urz tu-dresden de>]

This is kind of proposal ... encouraged by Liss Svanberg <lisss@ydab.se>.
(maybe even someone will put it onto the proposals-page)


Watching users--and I mean ``naive'' users--do their work I am
surprised about the ``mistakes'' they perform. Would any of you as
experienced computer hackers think that ``Save as ...'' appends to the
file selected instead of overwriting it? But is this really such a bad
Idea? To put it in other words: anything wrong with this kind of
``mental model'' of the computer system? I don't think so. Don't blame
the user.

On the other hand is the fact that documents change rapidly and
sometimes even incidentially. So any one of us may have experienced
the situation when we changed something and wanted to back up to an
older version. This version is no longer available then. Never seen
files like this: dgps1.tex, dgps2.tex, ... saving different versions
in successive evolution?

So I would like to add some thoughts about backup files saved by
various programs that are quite useless. At best the last version is
saved before you started editing. In many cases you will only find the
version before the last ``Save''.

As Don Norman <don@jnd.org> points out ...

> Things have not always been this way. Earlier systems, such as
> Tenex, used to save all versions of files, so it would be possible
> to back up to the third-previous version.  An early word processor
> used to save 'dribble" files, which was a keystroke history of the
> editing, so that one could always recover anything. One could even
> recover past a file deletion.

Programmers know something like a source or revision control system,
saving not only the last version of their work but the complete
history of changes done. All the versions back to ``hello world''---if
you like to. This could be done in a space effective manner
(cf. manpage for RCS and the article by Tichy mentioned there).

Wouldn't it be nice to have this feature present in user programs
nowadays, too? Maybe it could even be built into the filesystem:
keeping track of any changes for selected file-types.

Of course all this would need some clever interface to access the older
versions:-)

Don:

> I personally think the file structure is irrelevant to humans and
> should be discarded. and your notion of a 'delta record" is
> appropriate; record al the changes, so it is possible to undo them
> or redo them, no matter what actions have taken place.

Liss:

> Perhaps the most user friendly solution would be to create a brand
> new diskformat that could be supported by a couple of OS'es...
> ... but I presume that it would be far easier (and therefore less
> dangerous) to create a new *file*format with logging support.

> This fileformat could then be handled by GNOMEapps through a CORBA
> interface.  (with different logging technics for different types of
> files) That way most GNOMEapps would support logging of older
> fileversions, and the rest of the OS would behave in it's normal way
> (actually the OS wouldn't have to change at all).

> The drawback would be that normal programs, not running under GNOME,
> would be unable to read this logged fileformats.

I don't agree on this point: the last version coud be stored in a
stand-alone fashion readily accessible by other programs.

Don> Alas, I don't see any glimmers of hope.

Is there anybody out there seeing a real chance to realize this? I
don't have the knowledge and the possibility to do any practical
programming but I'm eager to learn and assist ...

Is there any glimmer of hope in the Gnome-Community?

    Johannes




P.S. Go and read the books by Don, they tell a lot about (cognitive)
     design which is relevant for user-friendly software, too.


-- 
Johannes Sch"afer
    mailto:josch@rcs.urz.tu-dresden.de