Path: utzoo!attcan!uunet!mcsun!cernvax!chx400!unizh!gorgo!schaerer
From: schaerer@gorgo.ifi.unizh.ch
Newsgroups: comp.sys.mac.system
Subject: Re: Opening "foreign" documents in Standard Open
Message-ID: <1990Jul10.154056.28511@gorgo.ifi.unizh.ch>
Date: 10 Jul 90 15:40:56 GMT
References: <8980@goofy.Apple.COM> <1990Jul4.042132.11832@d.cs.okstate.edu> <8996@goofy.Apple.COM>
Organization: University of Zurich, Department of Computer Science
Lines: 63

Larry Rosenstein writes, in response to Robert Minich:
In article <8996@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
>In article <1990Jul4.042132.11832@d.cs.okstate.edu> minich@d.cs.okstate.edu (Robert Minich) writes:
>
>>the Finder instead. I personally think the speed of the finder is pretty
>>bad for picking a file from within an application. The windows clutter
>>the screen terribly and take too long to update. (IMHO, of course.)
>
>Then the Finder should be improved.  
>
>>Perhaps we need to extend std file to include more option similar to the
>>finder like sorting views and multiple selections. What say ye net?
>
>In my opinion, you've got it backwards.  The Finder should be extended to
>provide a fast way to browse the document space (a la Std File) rather than
>extending Std File to include more Finder features.
>
>Note that I don't think Std File will ever be removed, since it is a
>fundamental part of the Macintosh interface.  But if you were designing a
>system from scratch, I'm not sure that you would include a similar
>mechanism.
>
>-- 
>		 Larry Rosenstein,  Object Specialist
> Apple Computer, Inc.  20525 Mariani Ave, MS 46-B  Cupertino, CA 95014
>	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
>		UUCP:{sun,voder,nsc,decwrl}!apple!lsr

I completely agree with Larry (as usually...), but I would go one step
further: If I were Apple, I would at least *try* to eliminate the Standard
File dialogs in the long run, i.e. encourage the application writers *not*
to include "open..." and "save as..." commands.

The Mac's user interface is mostly based on direct manipulation: E.g., the
user selects a document and then performs "open" on it. The implementation
of "open" can be different for different documents and is identified by
the document's type. (Programmers may note that this is an essential part
of object-orientedness -- just another buzzword...)

The Standard File dialogs follow the more traditional "tool" metaphor: The
user selects a tool (a menu command in this case) and then applies it to
his/her data. To make things worse, the dialogs introduce an abstract view
onto the user's data hierarchy that looks considerably different from the
desktop view.

I never liked this inconsistency. As far as I remember, Lisa's user inter-
face was more consistent. There were no "open..." or "save as..." menu com-
mands. Documents were always opened and created (from stationary) on the
desktop. That's the direction I would like Apple to go back. And, as Larry
wrote: If performance is a problem, then the performance should be fixed,
not the user interface.

I agree that the tool metaphor can be useful in some occasions, like for
"unusual" operations, e.g. low-level access to files or resources. (Here,
object-oriented terminology might help again: These cases can be modeled
by inheritance, it might just be necessary to "hide" the ancestor opera-
tions.) But then, I would like to see a *desktop* implementation of the
tool metaphor. Any plans inside Apple?

Comments?
---
Daniel Schaerer, University of Zurich/Switzerland
schaerer@ifi.unizh.ch