unity-design team mailing list archive

[Gregory Merchan <gregory.merchan@xxxxxxxxx>]

On Sun, Jun 24, 2012 at 3:31 AM, Andrea Corbellini <
corbellini.andrea@xxxxxxxxx> wrote:
> Hello,
>
> Thank you for your analysis. Here is some feedback from myself, I hope
> you'll find it useful.
>
>
> On 24/06/12 09:35, Jonathan Meek wrote:
>>
>> *"Open with [default program here]"/"Open With >"
>> Why do we have these two items? If the user wants to launch with the
>> default program they can just launch it by normal clicks. The expanded
>> "open with >" option is all that is really necessary at this point in
>> time in case a user wants to launch the file/program with a non-default
>> action.
>
>
> For me, the "Open with <name>" has been useful to know which application
> would have been opened by default. Dropping it from the menu is fine for
me,
> but what I do need is the ability to recognize the default application
under
> "Open With >". Making it bold should be fine.

At a minimum, the separator between "Open With Foo" and "Open With >"
should be removed.

Right-clicking on a folder on the desktop, I see:

Open
----------------------------------
Open With Files
Open With Other Application . . .
----------------------------------
etc.

The name of Nautilus is "Nautilus", not "Files" and if I say any more it
will be vulgar.

Why are folders different from everything else here? It might make sense if
commands to open an icon view, a list view, or some other kind of folder
view were presented, but it looks like the default option is presented
twice. Oh, and Nautilus becomes two different programs once a folder is
opened: according to the folder window it has become "File Browser"
(despite me using what's left of spatial mode), and according to the menu
bar it has become "Home Folder".

One possibility I don't mind, but which HCI studies may have shown to be a
bad idea, is a mix between a regular menu item and a sub-menu. These were
used in OS/2 in the mid-90's and IceWM. Here was some discussion from 1999:
https://mail.gnome.org/archives/gtk-devel-list/1999-January/msg00015.html

They were called "conditional cascade" menus and looked something like this:

+---------------++-------------+
|   Open    | > ||   Option    |
|               || @ Default   |
|   etc.        ||   Option    |
|               ||   etc.      |

The @ was a black diamond which indicated the default. The submenu order
did not change if you changed the default. The bar between "Open" and the
sub-menu-indicating arrow both indicated that the item was not just a
sub-menu header and indicated the region you must enter to open the
sub-menu. Pressing Ctrl also opened the sub-menu, I think.


>> *Cut/Copy
>> Not much to say here, need to keep an eye on where there is duplication
>> of effort, however.
>>
>> *Make Link
>> I would argue against the need for this item, but can see its
>> usefulness. I say keep it for now, but keep an eye on how useful it
>> remains.
>
>
> I personally use the dash to look for my files and folders. But Unity and
> Gnome Shell are great at showing the files you are looking for. So, in my
> opinion, there's absolutely no need to create links to make navigation
> faster.

It's about not navigating, not making navigation faster. I have many
different projects I'll work on for different stretches of time. Of, say,
30 projects, I may be working on 4 this week. Next week one of those may be
gone, but two others are now "current". I keep links on the desktop to both
current projects and important projects. I control the phasing in and out
of things on the desktop because I know the difference between what's
important, what's current and recently used, and what's current and hasn't
been used in a long time. The computer never will until there's a way to
mark precisely that.

All that said, the way Make Link works right now is awkward.


>> *Rename
>> Necessary, but same deal as Cut/Copy.

I hadn't noticed until now that you can no longer start renaming files by
clicking on the names. I think I prefer that without the menu method, but I
know people often accidentally rename that way. As somebody else mentioned,
there is the property panel.


>> *"Copy To >"/"Move To >"
>> These two are a mild convenience that I don't think is worth the wasted
>> space. Besides, I can't, as a user, define a new place to add to these
>> categories. And that picture I right-clicked on? No option to send it to
>> /home/ME/pictures, so these items sort of explain themselves out of the
>> picture in my eyes. I quick drop to /home or /home/me/Desktop isn't
>> really worth those two lines. (Also, weird bug I noticed: for some
>> reason the move to sub menu was unshadowed and caused the right-click
>> menu to expand. Not sure if just me or what.)
>
>
> Never used such options and, as you already said, they are too limited to
be
> useful.

Yup. It might make sense if recognized devices like memory sticks were
added to the list, but they are not.


>> *Move to Trash...
>> I couldn't live without it.

I wouldn't go that far, but OK.


>> *"Resize Icon"/"Restore Icon's Original Size" [DESKTOP ONLY]
>> Why do these even exist? Nautilus' desktop is already unruly enough
>> without having this absolutely useless feature. How many people actually
>> resize any icons on their desktop? (Another bug: After testing what
>> Resize did, I went to click the restore option which appeared
>> insensitive, but allowed me to click it anyway. Will need repro.)

This left over from Eazel days may have untapped potential.


>> *Revert to Previous Version...
>> Will someone please tell me why this option is there for me? I do NOT
>> have Deja Dup set up. Yet it's decided to hook into my menus and ask me
>> if I want to revert a file that it isn't versioning? I think Deja Dup
>> needs to have some thinking of when to expose such functions to users
>> instead of just sticking it in because it is there.

Seen that. Been afraid to click it since I know I'm not doing version
tracking or back-ups.


>> *Compress...
>> Useful in my eyes. Would love others input on this one.
>
>
> Very useful for me too. Also, the tool for the compression is really tiny
> and uncomplicated.

Useful. I use it to compress completed projects and things I'm sending to
other people.


>> *"Ubuntu One >"
>> So singularly focused. Are we proposing with this behaviour everyone
>> should just drop their own items into the menu? If I've a dropbox and U1
>> account, will my menu be another usless item? OS X, from what I can tell
>> handles this situation much more gracefully with its "Share..." option.
>> I think it would be much better to have this and have programs hook into
>> that instead of populating my menus. Share covers the gamut from social
>> to cloud.
>
>
> Personally, I'd prefer to manage all my sharing settings from a generic
and
> centralized 'sharing tool', rather than from Nautilus. (With 'generic' I
> mean service-independent.) This would give me both more control and more
> information about what's going on, as I take privacy seriously. However
> that's probably out of the scope of this thread...
>
> It should be noticed that folders have already a 'Sharing Options' item
> inside their context menu. But it's very unintuitive: there are no
> information about where the share will be published, who will see it and
how
> to use it. If I remember correctly, that option creates a Samba share,
but I
> may be wrong.

I'm a dinosaur. I put things in ~/Public which is symlinked from
~/public_html. (I used to reconfigure Apache to recognize ~/Public instead,
but haven't bothered since setting up this laptop.) I only recently started
using Dropbox.

An overview of sharing sounds like a good idea for maintenance, but I think
sharing folders named for their services should be the basic interface. If
the shared item is in flux or has another purpose, I just put a symlink or
a hard link to the original.

"Sharing Options" on folders should just open the "Share" tab in the
property panel for the folder. Since that only saves one click, it should
probably just go away.


>> *Send To...
>> I'll be honest, i've never used this and upon clicking it to test what
>> it was, I still have no idea what the hell it is. It can't be too
>> terribly useful? Input needed.
>
>
> I was aware of the existence of this option and its effects, however I
have
> really never used it. For me, it's a waste of space.

Never use it either. I always drag it to the drop target in whatever I'm
sending with.


>> *Properties
>> Axe it! Oh, wait, nevermind.

Don't joke! They might!


>> Whew, quite a bit there... What are we looking at now?
>>
>> Open With >
>> ---------------
>> Cut
>> Copy
>> Move to Trash
>> ---------------
>> Make Link...
>> Rename
>> ---------------
>> Compress...
>> ---------------
>> Share...
>> Properties
>>
>> Fewer submenus, less noise, more usefulness. Of course, with the
>> "Share..." option requiring more work than less, I doubt that one will
>> come to fruition, though I do find it much more graceful. I'd appreciate
>> feedback on those areas my post has been lacking. And before we start in
>> on the "I use this feature, so it has to stay" think first if we have it
>> elsewhere, how many others will really use it (hence why Compress is an
>> iffy option), how hard it is to do elsewhere, versus cluttering the menu
>> further, etc.

Folders at least have some different options. The "Open With" submenu seems
to be for items that might be opened with more than three known
applications—up to three, they are listed in the menu.

Extensions can add more items and need to be considered.