Re: [Usability] Re: Spatial nautilus - fantastic - but what about the rest?
- From: Thorsten Wilms <t_w_ freenet de>
- To: usability gnome org
- Subject: Re: [Usability] Re: Spatial nautilus - fantastic - but what about the rest?
- Date: Mon, 24 May 2004 09:49:04 +0200
On Mon, May 24, 2004 at 08:04:36AM +0900, Jan Morén wrote:
> mån 2004-05-24 klockan 02.44 skrev Reinout van Schouwen:
>
> 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.
I think there's a problem here with the concept of files. You both
seem to think strictly in terms of files. But it should rather be about
working with documents (like saving versions of _one_ document in several
files). Seen this way, the user has to deal with a filesystem concept (files),
allthough he might rather think in terms of documents.
BTW, I'm currently working an such concepts for the design of a complete
user environment. It's for my ergonomics course (I'm studying industrial
design, but I'm very interested in interface and interaction design).
So you might hear more from me :-)
> 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,
If we have peristent (no need for explicit save) documents, such
rollback/versioning could be dealt with by something like a bookmarking
system for the documents state. There's need fo a edit history for undo
anyway, and this would be part of the same system.
> > > 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?
I see no reason to not have an export option in a documents menu.
Ther could be an option to keep an exported version in sync with
further edits of a document.
---
Thorsten Wilms
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]