barnett@grymoire.crd.ge.com (Bruce Barnett) (06/30/90)
In article <1990Jun18.223436.7497@Neon.Stanford.EDU> philip@pescadero.stanford.EDU (Philip Machanick) writes: > How about the following redesign: How about resize boxes on all four corners? -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
spencer@osc.edu (Stephen N. Spencer) (07/04/90)
In article <BARNETT.90Jun29155306@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: >In article <1990Jun18.223436.7497@Neon.Stanford.EDU> philip@pescadero.stanford.EDU (Philip Machanick) writes: >> How about the following redesign: >How about resize boxes on all four corners? There was an article in MacTutor magazine, sometime in the last 1.5 years (sorry, they're at home and I'm at work) which described how to design windows with exactly that feature. I believe it was written in Pascal. -- Stephen N. Spencer | "You stepped out of the rain, ACCAD, 1224 Kinnear Rd. | You shook your hat off... Columbus OH 43212 | At the same time you shook me to my soul..."-K.McKay spencer@cgrg.ohio-state.edu OR 71160.3141@compuserve.com
lsr@Apple.COM (Larry Rosenstein) (07/04/90)
In article <1990Jun18.223436.7497@Neon.Stanford.EDU> philip@pescadero.stanford.EDU (Philip Machanick) writes: >more idea... It seems to me that, since MultiFinder was introduced, >graying out names of documents belonging to other applications in the >standard open dialog has become obsolete. How about the following There are no grayed out files in the Open dialog. The grayed out files appear in the Save As dialog, in order to provide some context to the user as to what the folder contains. >1. documents created by current application displayed in bold >- double-click, or click on Open: as before >2. documents created by other applications, but of a type OK to open I'm not sure what the point of bolding these documents would be. I can see providing some kind of filtering, to cut down the number of documents that appear in the list. (For example, some applications have popup menus to filter by file type.) >- OPTION-double-click, or additional button Open into Owner: treat as if > double-clicked in Finder (i.e., either open the application, or > context switch to application and simulate Open) I dislike the fact the the Open command in one application results in switching to another application. >3. documents belonging to another application not possible to open from > here displayed in italics; when selected, display owner name in Open One problem is that in the Open dialog you would see all the documents, with no filtering. It would make it much harder to find the document you were looking for. I think you're attempting to replace the Finder with an extended Standard File, and I'm not sure that's a good idea. I think it's similar to trying to replace the Finder with an extended Apple menu. Both features (Standard File and the Apple menu) are artifacts of the original Macintosh, and both should probably be replaced by something that fits better with the System 7 environment. For example, you really don't need the Open dialog at all; users should just double click on the icon in the Finder. (That doesn't always work today because MultiFinder has to fake out the application. But eventually applications will support the standard AppleEvent to open files.) -- 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
minich@d.cs.okstate.edu (Robert Minich) (07/04/90)
From article <8980@goofy.Apple.COM>, by lsr@Apple.COM (Larry Rosenstein): | I think you're attempting to replace the Finder with an extended Standard | File, and I'm not sure that's a good idea. I think it's similar to trying | to replace the Finder with an extended Apple menu. | | Both features (Standard File and the Apple menu) are artifacts of the | original Macintosh, and both should probably be replaced by something that | fits better with the System 7 environment. | | For example, you really don't need the Open dialog at all; users should just | double click on the icon in the Finder. (That doesn't always work today | because MultiFinder has to fake out the application. But eventually | applications will support the standard AppleEvent to open files.) I would scream bloody murder if you took away my standard file dialog!!! Perhaps a way (button?) to "go looking" would allow me to use 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.) Also, it's nice to have the std file box come up situated at the place you left it so you can grab more files in the same place very quickly. I have yet to play with a NeXT, but I suspect the thingy they use to navigate can be very efficient, much in the same vane as std file. 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? -- | _ /| | Robert Minich |Q: Why is the food so lousy, and | \'o.O' | Oklahoma State University |the service so bad? Time traveler: | =(___)= | minich@d.cs.okstate.edu |A:The waiters know in advance what | U | - Bill sez "Ackphtth" |kind of tip they'll be getting.
philip@pescadero.Stanford.EDU (Philip Machanick) (07/05/90)
In article <1990Jul4.042132.11832@d.cs.okstate.edu>, minich@d.cs.okstate.edu (Robert Minich) writes: > From article <8980@goofy.Apple.COM>, by lsr@Apple.COM (Larry Rosenstein): > | I think you're attempting to replace the Finder with an extended Standard > | File, and I'm not sure that's a good idea. I think it's similar to trying > | to replace the Finder with an extended Apple menu. > | > | Both features (Standard File and the Apple menu) are artifacts of the > | original Macintosh, and both should probably be replaced by something that > | fits better with the System 7 environment. > | > | For example, you really don't need the Open dialog at all; users should just > | double click on the icon in the Finder. (That doesn't always work today > | because MultiFinder has to fake out the application. But eventually > | applications will support the standard AppleEvent to open files.) > > I would scream bloody murder if you took away my standard file > dialog!!! Perhaps a way (button?) to "go looking" would allow me to use > 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.) > Also, it's nice to have the std file box come up situated at the place > you left it so you can grab more files in the same place very quickly. I > have yet to play with a NeXT, but I suspect the thingy they use to > navigate can be very efficient, much in the same vane as std file. > 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? > Maybe my original idea wasn't so great; neither is doing everything through the Finder. Maybe we should focus on the notion that both of these things are becoming obsolete, and some better concept could replace both. How about a browser capable of either listing documents belonging to the front application or all documents, with a variety of views (by name, by icon etc.), and a pane to show the first page of a document if the application owning it is "browser smart"? Sort of like the current Finder, but optimized to be as easy to use as the current open, and with a few extras to help you decide if you would _really_ like to switch out of the current application to open a document. Further comments? Better ideas? Philip Machanick philip@pescadero.stanford.edu
lsr@Apple.COM (Larry Rosenstein) (07/06/90)
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
schaerer@gorgo.ifi.unizh.ch (07/10/90)
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
rich@sendai.sendai.ann-arbor.mi.us (K. Richard Magill) (07/11/90)
I have a couple of complaints along these lines too. 1) documents are opened using the application signature. But what do I do with documents for which I do not have the creating application, but do have something usable. Witness the problem of README files which frequently show up as text files with macwrite signatures. I don't have macwrite and don't want it. I do have teachtext. This is extremely awkward to explain to naive users. 2) As a user, there is no (apple provided) way to even find out the signature of a file, much less change it. 3) I often spend far more time navigating around the SF dialog than I do working on the document. In a multi-finder environment, I'd rather have the call to SF pawn off to multi. I'd then have the desktop to navigate around rather than SF (one less unnecessary interface) and I typically have the folders I'm dealing with open somewhere on my desktop anyway.
jwwalker@usceast.UUCP (Jim Walker) (07/12/90)
In article <RICH.90Jul11103521@sendai.sendai.ann-arbor.mi.us> rich@sendai.ann-arbor.mi.us writes: [perfectly reasonable stuff deleted] |3) I often spend far more time navigating around the SF dialog than I |do working on the document. In a multi-finder environment, I'd rather |have the call to SF pawn off to multi. I'd then have the desktop to |navigate around rather than SF (one less unnecessary interface) and I |typically have the folders I'm dealing with open somewhere on my |desktop anyway. I'm just the opposite. I typically have NO folders open, and use files from all sorts of different places in my directory tree at one time. I make heavy use of Disktop and Disktop Launch, and I'd much rather select documents with Standard File + Boomerang than mess with Finder. Even if I did have all the relevant folders open on my desktop, it would be hard to use them on my standard dinky screen.-- Jim Walker jwwalker@cs.scarolina.edu 76367.2271@compuserve.com