Re: [Nautilus-list] Inconsistencies and suggestions

[Darin Adler <darin bentspoon com>]

On Sunday, June 10, 2001, at 12:51  PM, Gaute Lindkvist wrote:

> 1. The dialogs in Nautilus sometimes haven't got any "Ok" or
> "Close"-buttons. Instead they apply changes immediately when changed,
> and you just have to close the window using the sawfish-close-button.
> This is not consistent with the normal Gnome-way of doing things, and I
> think (without any proof of course), that people may have difficulties in
> knowing what to do. If the dialog is directly in front of what they were
> trying to change, they may not even know that it has changed, until they
> close the window.

This is something the Nautilus developers did intentionally. The business 
about having to close the window with the window manager is something that'
s simply an oversight. A lot of us were not used to Unix, where the 
controls in the window's title are not guaranteed to be there. In our 
designs for other platforms, the close box was the normal way to close 
windows.

So adding close buttons to dialogs that lack them would be great.

Changing dialogs so they don't have any effect until you say OK is 
something different. We need to discuss this on a window by window basis. 
In many cases, it's easier to understand controls that actually have 
effects. The OK system is fine for modal dialogs, but not so great for 
other windows.

Anyway, we could spend a lot of energy on this debate, but I'd rather not 
unless there's going to be a big benefit for Nautilus users. I have a 
limited amount of time to spend on the project and I want to avoid 
thrashing about if possible.

> 2. The bad inconsistency in Windows, were default action for drag n' drop
> of files changes if you drag it across partitions, is copied in Nautilus.
> I found it horribly annoying in Windows. Have there actually been
> GUI-testing that suggested that this is the right way? For me, I would
> think that users shouldn't have to worry about wether something is one the
> same, or different partitions. Actually IMHO, users shouldn't have to know
> that there is such things as partitions.

Perhaps we can change this. Both Windows and Macintosh share the "bad 
inconsistency" you cite, and there are some reasons for it, but I'm not 
sure I'm prepared to do the whole debate here on nautilus-list. A few 
thoughts.

1) Users don't have to know that there is such a thing as a partition if 
you don't create partitions for them. If you do, then you have to explain 
what is out of disk space, so you can't completely hide partitions.
2) On my computer there is no such thing as partitions (except for /boot).
3) Moving a file across partitions can result in running out of disk space.
 Moving a file within a partition can't.
4) Do we want the same moving/copying behavior when it's not just a 
separate partition, but a separate disk, like when moving from a hard disk 
to a Zip cartridge?

If someone made a complete recommendation of how to change things, I'd be 
happy to think it over. Having the default drag mean copy when I drag from 
my hard disk to a network disk or a Zip cartridge is a real convenience 
for me on my Macintosh, so you'll have to convince me that the 
requirements for Nautilus are somehow different.

> 3. The way of renaming files are different in icon-view and list-view.
> Why?
> To clarify: In icon-view you can choose rename from File or contect-menu.
> In list view you have to go via file preferences. Isn't this just
> confusing and inconsistent?

Yes, it's just a missing feature. It was hard to implement renaming in the 
list view, so we didn't do it, to save time. We'd prefer to have a list 
view that shared more implementation with the icon view. If someone wants 
to make a good renaming-in-place feature for list view, that would be 
great.

> 1. Sidebar-panel for devices. This has been suggested before, but IMHO it
> is such a killer feature that it should definetly be a priority.

I don't exactly understand what the sidebar panel would have in it, but 
that's OK. Someone can just implement it to demonstrate. Doesn't need to 
be built in. A separate sidebar component can be developed, and if we like 
it, we can put it in by default.

> 2. A sidebar-panel for the clipboard. Show files that have been cut or
> copied (vith different emblem), and the possiblity of using it as
> temporary storage with drag and drop.

Sounds OK. Doesn't need to be built in. A separate sidebar component can 
be developed, and if we like it, we can put it in by default.

    -- Darin