Showing unsaved status for document-based windows
Ian Wood
revlist at azurevision.co.uk
Sat Jan 12 18:30:55 EST 2008
On 12 Jan 2008, at 21:56, Randall Lee Reetz wrote:
> Maybe a better question is: why does the document "need to be
> saved"? Why isnt it saved as it is being changed? Should the user
> have to be aware of the memory/hard disc schism? Just a thought.
Re-written because it was turning into a nasty rant and I don't think
you *meant* to irritate me...
The saved/unsaved document concept is immediately familiar to almost
ALL computer users. As the app I'm working on is based around building
visual flowcharts to automate photographic workflows I need to keep
the rest of the app as familiar as possible. The app itself introduces
enough new concepts for people who aren't used to thinking in those
ways - we photographers are renowned for not thinking in programming
terms. ;-)
There are also issues of ease of coding, reliability and speed.
A routine which grabs info about all the flowchart steps, converts it
to XML and writes to file is pretty easy to write, and the user isn't
expecting the app to do anything else at the time so it doesn't matter
if it takes a moment.
If the flowchart gets sufficiently large and complex that the routine
starts impacting noticeably on the end user by being called too often
you then need to start breaking down the saving routines to only
handle what has changed, a *vastly* more complex affair. And, as
always, complex code tends to mean buggier code.
Next - have you tried implementing a fully-functional and totally
reliable undo mechanism in Rev? Doable, but not particularly easy. So
what does your user do when they make a mistake and delete a vast
swathe of their flowchart? They open up the previously-saved version.
With constantly-updating files this is no longer possible.
Further issues arise when people want to make a new doc from an
existing one - they immediately look for a Save As... command, in
which case they are already conditioned to expect a Save command just
above it.
Potentially you are looking at building a versioning system, which is
total overkill.
Obviously there are areas where it works, like iCal, iTunes etc. but
they aren't really what I'd regard as document-based apps. You don't
generally have a few dozen different calendars or music libraries you
open and close and choose between. The apparently document-based apps
that work in this way, such as Aperture and Lightroom were full of
people in the early days asking 'but how do I save it?'.
So, a nice enough thought, but but waaaay off-topic for my needs.
Ian
More information about the use-livecode
mailing list