Re: [Usability] Re: Spatial nautilus - fantastic - but what about the rest?

[Jan Morén <jan moren lucs lu se>]

mĺn 2004-05-24 klockan 02.44 skrev Reinout van Schouwen:
> On Fri, 21 May 2004, Jan Morén wrote:
> 
> > gnumeric, for instance, you either need to keep "Save As" or make the
> > equivalent operation (make a copy, and continuing editing the copy)
> > _really_ obvious.
> 
> This shouldn't be difficult to perform from within nautilus. Ctrl+drag (or
> the much more cumbersome copy+paste), activate, you're in business.

That's exactly what I wouls mean is not obvious at all. Instead of a
keypress, followed by entering the name - all without leaving the
application window or leaving the keyboard - you want the user to leave
the keyboard, leave the application window (or leave the current work
context, if talking about applications seems wrong to you), do a
copy-rename operation, then come back.

And you do not get the effect that the application now should be editing
the renamed copy, not the original.


> > Juggling a tree of several variants when doing something complicated is
> > not that uncommon - and needs more than just reliable rollback. Also,
> 
> Could you elaborate?

What this really is used for is as a sort of manual version control
system. Every "Save" is a tag in preparation of a set of operations you
may want to discard as a group, and every "Save As" is a branch when you
want to do a series of such groups of operations.

The point is not just rollback, in other words, but the ability to
return reliably to a known, good, state. If you rely on only undo
functionality, you need to keep in memory before which operation the
last good state was; "tagging" it with an explicit save removes that
burden. Similarily, when you branch your document with "Save As" you are
now free to do a series of (likely) experimental edits on it, tagging
intermediate states as you go, knowing you have the "original" - ie. the
last save before the branch - tucked away.


> > you will still need a Save operation in many apps anyway, as you
> > frequently want to save a file in a different format than the default
> > (Ok, call it "Export"if you want but we all know it is "Save as" with a
> > format list).
> 
> You're thinking too much application centric. It has been proposed here
> before that each program could register the formats it can handle with the
> desktop environment. In that situation, most of the required converting
> work could be done below the surface - imagine a case where the user has a
> scanned image in TIFF format and wants to insert it into a document being
> edited with Abiword, which doesn't support TIFF natively. The drags the
> TIFF image to the document area, Abi asks the environment to convert it to
> PNG or somesuch, and it Just Works! Below the surface, Gimp or ImageMagick
> has been called to perform the conversion.

I have a document written - in Abiword, say. I want to save it as a Word
file. I open "Save As", and write the name "MyNiceDocument.doc" and it
will save it as doc format. I could also choose Word format from the
drop down list if I want. Easy, clear, quick. As I continue editing,
this is the document and format that is being saved.

Instead, you want me to exit abiword, find the temporary document, drop
it onto a panel applet (which I need to have running - which means I
need to have a panel at all times), which will (not) give me the same
drop-down list (see below), which I choose. Then, All i have left to do
is rename the document to the name I avctually wanted it to have, find
the original I never wanted, throw it into the trash, and empty the
trash.

That dropdown list will be large. Since every WP app will need to
register their file formats, and since, in general, format X (Word, or
XHTML, say) will not be produced the same by every app, the user really
needs to be able to choose between all of them. For graphics file
formats, the situation becomes fuzzy. Should Gimp, ImageMagick or NetPBM
register all of its file format conversion variants - and when does it
stop being file conversion and starts being image manipulation?


> > laptop users nuts. Constant kicking of the HDD is a sure way to deplete
> > battery life (and ruin the sense of absolute quiet you otherwise can
> 
> Good point, but there are more cases where special handling of laptop
> situations is needed. We could have some sort of meta-laptop-theme for
> this perhaps?

But that means essentially branching the desktop. You want all
application writers to support both ways of working, but now with a
switch to selectively turn them on or off. And I'm not entirely sure I
like the idea of having significant interface shear between my desktop
and laptop, for the same OS and desktop version.

Of course, if we are going to have both implemented, we could also just
have both active as well. Let people use the Save and Save As
functionality if they want - it's already there - and treat the other
way just as a reliable autosave for those who want it.



Note: I'm not really against this idea in principle. For devices where
it can be pulled off (like the Palm), it tends to work fine. They tend
to work, because they are fairly restricted devices, and people use them
for a narrow range of tasks. I do think that the general desktop is too
diverse - both in usage patterns as well as in device capabilities and
in application variability - to use this to good effect.

-- 
 
Trust the Computer. The Computer is your friend.
 
Tel.    +46-046 222 8588             Dr. Janne Morén (mr)
Home:   +46-046 211 4973             Dept. of Cognitive Science
Fax:    +46-046 222 9758             Kungshuset, Lund
                                     S-222 22 Lund, Sweden