Re: [Usability] GNOME UI principle: All applications should save internal state?



On Mon, 2004-04-05 at 10:31 +0900, janne wrote:
> mån 2004-04-05 klockan 09.33 skrev Ryan McDougall:
> > Do you agree that all applications should save their state such that
> > they are no different from the time they were close to the time they
> > were reopened? If you agree should this be part of the HIG or similar UI
> > policy? What are the positive or negatives of such a policy, were it
> > implemented? Should there be a unified API/framework for apps to reuse
> > so they can store their state?
> > 
> > As an example of an app that goes a long way to save state in a real
> > spatial or sessional way, see Eclipse's workspaces. Epiphany and Pan
> > also save their current workload state in the event of a crash, but
> > should they *always* save their state (ie: save the current web pages
> > seen, or items queued for download), even if they are terminated
> > normally?
> > 
> > I think they should, and doing so provides a number of UI benefits.
> > Consistent state meshes *especially* well with a spatial design, since
> > the "real world" always has a consistent state. When I leave my papers
> > spread out at work, they are sitting exactly where I left them the next
> > day. I also think there should be a GNOME-wide policy and method to
> > allow apps to save their state data is a consistent and easily
> > manageable way.
> 
> Interesting idea.
> 
> As you point out, though, in many cases it is pretty fuzzy what "state"
> really should mean. Consider a CPU activity monitor applet, for example;
> when you restart, should it remember and display the graph from before
> the reboot? Or if a particular set of network interfaces where active
> before reboot, should they (through the network device control
> application) by default attempt to reconnect using the same parameters?
> 

You have a point. I think that the definition of what "state" is should
be defined on a app-by-app basis. Although its obvious that apps with
trivial internal state, or which simply display the state of other apps,
should refrain from wasting resources by saving state unimportant.

As for apps that manage resources they do not directly control or have
implications beyong GNOME, such as system state, should not save state
since this represents obvious system management headaches (as you
alluded to). However as you know, we do have a way to save system state
usually called init-scripts and config files. ;)

Cheers,
Ryan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]