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

[Sean Middleditch <elanthis awesomeplay com>]

On Wed, 2005-04-20 at 15:24 -0300, Lucas Meneghel Rodrigues wrote:
> Wow. Some real good stuff here, let's discuss a little bit:
> 
> 2005/4/19, Samuel Abels <newsgroups debain org>:
> > * Add better interaction of the document's icon with the application:
> >    - The icon should be a thumbnailed preview of the actual document.
> >      (This is actually possible today.)
> 
> Yes, we just need to add thumbnail generators for most apps that
> handle different types of content. However, Except for images, I can't
> see why this should be terribly useful, since document previews would
> give you a clue about the document *only* if the size of the thumbnail
> is quite large. We should think on limitations of our current hardware
> (small screens and resolutions).

Thumbails can be very useful on many documents.  Most of my textual
documents have some kind of cover/title page, for example, which even if
not readable I can usually recognize just be the specific
length/style/size/placement of the text.

> >    - When the application is loaded, the document zooms to real size and
> >      the toolbar is attached. There is no real window border and the
> >      controls are kept to a minimum. Basically, the application IS the
> >      paper.
> >    - Consequently, when the application is closed, it zooms out and
> >      becomes an icon again.
> 
> 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.

> 
> > * The above is implicitely also a plea for "Instant Save". If the
> > document IS the paper, it needs to save changes immediately. That of
> > course also means that a history needs to be saved elsewhere, so that
> > when an application crashes the history is not lost. Instant save has
> > also the advantage to let you get rid of the "Save" (and "Save all")
> > button, so even less clutter for the GUI.
> 
> Really really nice, but we must think about the hardware overhead
> (mostly HD acess) this would add, because every action would need to
> be commited to disk. This would make power consumption higher,
> specially on laptop computers, because disk acess are intensive at
> power usage. Maybe someone can think on some smart mechanism to avoid
> excessive disk acess.

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).  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.

-- 
Sean Middleditch <elanthis awesomeplay com>