Re: [Usability] GNOME3: Handling/Opening Documents (Website for Contributing Ideas?)

[Samuel Abels <newsgroups debain org>]

Am Mittwoch, den 20.04.2005, 15:01 -0400 schrieb Sean Middleditch:
> > But if we don't have window borders, how we can close the window ? ;)
> > Yeah, just  kidding... Just noting that it (maybe) would be harder to
> > figure out where to "quit" your work with the document.
> 
> All windows should have borders.  Having some windows have borders, some
> windows not have borders, some windows have different borders, and other
> windows having anti-borders just is both confusing and pointless.  What
> purpose is there to removing window borders on document preview windows?
> They are windows, they should have window borders.  I should be able to
> move them around, resize them, minimize them, etc.

I agree that document based applications and non-document based
applications should be consistent. However, borders are not really
necessary for resizing - for example, once you get near the edge of a
window, resize handles could show up, similar to what happens to
selected objects in graphic applications like Inkscape.
Yes, some elements are probably better left visible all the time, like
maybe the close/minimize buttons. Also, for dragging a document around,
a handle needs to be visible.
But while I agree that some controls need to be attached to a window, it
is not necessarily a window border. Even though the "Window" terminology
might suggest borders, I don't agree it is the best term, since it
implys that document applications are not a direct representation of the
document but rather something build around a document.

> Instant save also is not safe for most file formats.  Unless the file
> format itself has built-in undo support, an automatic save feature would
> ensure that you could never undo any changes you make if your
> application crashes or the computer shuts down (power loss).

But this does not necessarily have to happen on the filesystem layer. In
fact, applications best try to figure out the smartest way to do an
"undo" operation themselfes, so the information is already there (if
undo is implemented, which it should be anyway); only that they
currently do not save this anywhere (which could be changed). That's
also more save, because a versioned filesystem would not save you from
losing data in many szenarios where an application crashes. For example,
what happens with "continuous save" (a file stream)? If the history only
provides you with content of the file that was in it before you started
the editor, that may still mean you lost a half day's work.

Of course, streaming the data is not always possible, but it's probably
smarter still to use the "Undo" history rather than a filesystem
provided history.

>  It also
> means that documents will be in an "inconsistent state" while you're
> editing, with no way to let other users/applications fetch the document
> in a consistent pre-edit state.

True, but that may even be what the user expects - when you edit a sheet
of paper it's logical that while you write, it is "inconsistent", a
better terminology is probably "edited", which is in fact /more/
consistent in comparison with the real world.
Also, this is already what we have today when the user backs up data
while writing (and many applications even have a 10-minute autosave
enabled by default).

-Samuel