Re: [Usability] File type system redesign

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Oct 17, 2001 at 03:54:41PM +0200, Reinout van Schouwen wrote:
<snip>
> Before taking a decision on this, I suggest having a good look at how
> OS/2's Workplace Shell handles this type of issues.
>
> Many of Seth's ideas come a long way in the direction of the WPS approach,
> but I'll first briefly explain this approach as good as I can and let you
> judge yourself. If there are more (ex-) OS/2-users on this list, please
> correct me if I forgot something.

I was thinking the same. I was also thinking along much the same lines
and only realized the OS/2 connection a moment before I started reading
this thread.
 
<snip>
> Now, imagine a scenario where the user browses the file system and
> encounters a Xyz document which he wishes to open. Two things can happen:
> 
> 1) the user double-clicks the Xyz document icon. The document is opened
> with the default(*) application for this class.
> 
> 2) the user right-clicks the document icon. A context menu pops up. The
> top menu item is 'Open' and it has an arrow next to it indicating
> a cascading submenu. The user moves the mouse cursor to 'Open', clicks,
> and the submenu shows all applications that are capable of opening this
> document. The default(*) application is indicated with a small diamond
> drawn next to its name. The user selects the application he wants to use
> to open this document.

It is worth noting that OS/2 manuals devote a subsection to the standard
object pop-up menu. (On OS/2, everything is an object in the interface
sense; I don't know about their programming style.) I can't find the quote
at the moment, but basically they say, "Everything has a pop-up menu. Try
pressing mouse button 2 everywhere and anywhere. Even the desktop has one!"

> Another scenario. The user has an Xyz document that he never wants to
> edit, but only view from time to time. So it is preferable that, when this
> document is opened, not the full-blown editing application is started, but
> just a viewer. There is a viewer application installed on the system that
> has registered itself as capable of viewing Xyz files. This is where the
> document -> application association kicks in.

I think we may go one better and provide editing and viewing on the menu.
This is a probably a bad example, but something like:

  +--------------+
  | _Open      ->| +-----------------------+
  | _Edit        | | <MIME App1> (Default) |
  | _View        | | <MIME App2>           |
  | _Settings... |   ...
  |--------------| | <MIME AppN>           |
  | _Copy        | +-----------------------+
  | _Move        |
  | Create _Link |
  +--------------+

> The user right-clicks the Xyz icon and selects 'Properties' from the
> popup menu. He goes to the tab where associations can be edited. There, a
> list of registered applications for this type/class is shown and also a
> possibility for manually entering another application exists. The user
> changes the default application *for this single document*.

Well, my OS/2 manual says "Settings..." not "Properties...",
but it's quite old. :-)

<snip>
> - The document -> application association settings are a bit too
> well-hidden within the file properties pages. Seth's mock-up already shows
> that associations in his design are easily discoverable under an Actions
> tab.

The only thing OS/2 used more than objects was notebooks. :-) And these it
used for many things. The biggest problem I had was that I'd forget that
some notebook pages had sub-pages. The File page was actually three pages
but you'd miss the other two (which had more advanced items, iirc) if you
just used the notebook tabs. Notebook tabs were consistently on the 
right-hand side and there was a graphic on the left resembling wire-binding;
they almost looked (and felt) like real notebooks.

<snip> 
> A final note: I don't like the text 'Open this file and other PNG images
> with:...'. When I change file properties I change them for that file
> alone! Forcing the change to be global feels too much like a windoze
> straight-jacket. (sp?) A checkbox to apply this change to other files of
> this type *could* be useful, though.

I concur here, but am subject to persuasion. If I'm changing something in
an object property window, it should be the properties of the object and not
the class of objects. If class properties can be changed from the object
property editor, that should be hidden behind a disclosure device.

Cheers,
Greg Merchan