[Usability] Re: Re: Spatial nautilus - fantastic - but what about the rest?
- From: Alban Browaeys <albanbrowaeys oreka com>
- To: Usability gnome org
- Cc:
- Subject: [Usability] Re: Re: Spatial nautilus - fantastic - but what about the rest?
- Date: Sat, 29 May 2004 03:35:23 +0200
Le Mon, 24 May 2004 09:49:04 +0200, Thorsten Wilms a écrit :
> 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 would 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.
"Save" becoming Rename, "Save As" copy would not hurt and fit well within
a file menu isn't it ? Sure that will conflict with the edit "copy" if
this could be renamed yank i'll loved it. (who ever handcopy a piece of text ,
don't we rewrite it )
> 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.
>
Versioning really do not fit with desktop paradigm. It eventually
conflicts with the spatial way. Directory being document versions's
container or document container is ubiquitious for the least. Could
versioning be achieved globally (ie for al applications even those not
aimed at versioning - gedit)? Are you talking about incremental
versioning or version snapshots ?
I have nothing against user centric paradigm except them being like
computer one"s . Document vs hierarchical filesystem are unable to fit in
a desktop layer. They are application or os centric. What about the
"File", the abstract one with content header, meta data.
Global Versioning could fit in a filename.index. Overcrowding
the directory. Hidden files are hidden , why not versions
Directory ? They are file that s all. Adding .version files inside ala "."
which is aimed at directory properties (/home/user/.configs aka user
configs).
Then problems . What about if i move the working file, will it move
versions ...
Only Way around is version container of its own. Back to the document
concept . It will not fit with file or directory as filesystem object.this
could be a tar file with all the version and a version files, or anything
better.
>> 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.
A "snaphsot version" bookmark widget would fit everywhere . That s great !
How could it be done for incremental verion without rewriting most
applications that i don t get.
>> > > 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.
Wher would this document area will be ? THose data could be use by the
clipboard to test whether the destiantion application support the format
or else propose the nearest matching format.
>> 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.
>>
>
> I see no reason to not have an export option in a documents menu.
It is unintuitive, useless in the open source world. That s for
undocmented/alien data format. Most of the time to show that this
conversion loose informations.
Fist it really deserve a new name: "Convert" ? This new name lead to the
why not in OSS world: we can split format converters from apps to libs
available to other aplpications. Every application binding to each libs,
choosing one which could be not feet our need. There this conversion layer
is missing.
A wild case : an eos document with pictures . I want ot export it to.abi
with pictures as png. Will I have to save each pictures as png the
export/import test, replace all this... I always saw export as this mess.
Convert could be in the file menu convert as export, in the contextual
menu a copy to clipboard, convert to new format, the paste. We could even
have a document menu with a "convert all pics to" ,then "convert document
to".
Alban
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]