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

[Diego Moya <turingt gmail com>]

> On Fri, 2005-04-22 at 17:37 +0200, Daniele Levorato wrote:
> > 6 - Instant save deserves several drawbacks... the discussion would be
> > too long but basically in my opinion it's really better to leave to the
> > user the decision about when saving changes or discard them totally:
> > full history or undo-lists are too high requirements for every
> > application-development.
> There are some rough technical challenges to overcome for more complex
> document types than plain text, but from a usability point of view, I'm
> very sure that instant save is the way to go.

I agree. The Save button should be replaced by universal access to a
versioning system, provided by the OS. That way a user could say "save
a snapshot of this document as a new version" in any application. So
you don't *force* users to create versions in order to make their work
persistent, it is auto-saved.

This doesn't need full undo to work. An extra benefit is that you can
recover any previous version, not just the last one.


On 22/04/05, Daniel Borgmann <spark-mailinglists web de> wrote:
> On Fri, 2005-04-22 at 17:37 +0200, Daniele Levorato wrote:
> > 1 - applications do exist and I have to install them when I configure
> > the system. You can't really hide the concept of application or you
> > should provide a default set of application, hidden to the user (really
> > inapplicable)
>
> Obviously system administrators have to know what programs are (and that
> includes home users who want to extend the capabilities of their
> computer), but that has nothing to do with how those capabilities are
> represented in the user interface.

I would propose a system based around "services" instead of
"applications". The programmed functions should be available as
services to all objects, no matter where they're located in the
system. In current applications, the provided functions can only be
used on the objects which are "open" inside the application, not on
any document.

For example the Gimp tools, if provided as services, could be used to
edit any image contained in any document, not just the images open in
the special "Gimp image window".


> > 3 - Complex GUI cannot be simply "attached" as toolbar (or something
> > else) to the document. Just think about Gimp or Cinellera! it's really
> > impossible. There're some tasks (like video/image/text editing) that
> > need a complex GUI infrastructure so that it's impossible to "hide" the
> > application concept.

You could still have "work benches" that hold together many common
tools and views. The difference with an application is the one I said
before, you still should be able to use those tools *outside* of the
work bench window.

There even could be other possible containers (even the old "window"
container to manage task-based activities). The difference is that the
tools available should not be determined by the container, just by the
object type.


>
> > Finally, but this is my opinion, an environment where applications feels
> > like applications is better because is more "task oriented", more
> > natural. A "mixed" scenario would only clutter the desktop semplicity.
>
> We already have this mixed scenario: Spatial Nautilus is purely document
> based (and I love it).

GUIs should be "goal oriented". Ok, a Desktop GUI goal is "solve all
my problems" but it can be decomposed into four high-level goals or
"modes": information retrieval (search), review (browse&read),
manipulation, and production. The Desktop environment should optimize
to support this four goals, whatever the particular current task is.