Newsgroups: comp.os.ms-windows.advocacy
Subject: Re: How MS could annoy Apple
From: feijai@endor.byu.edu (Sean Luke)
Date: 21 Nov 92 17:14:12 -0700
Reply-To: sean@digaudio.byu.edu

In article <9+21tnr@rpi.edu>  writes:
>In article 1172@yvax.byu.edu, feijai@endor.byu.edu (Sean Luke) writes:

>>I think that NeXT realised early-on that it had to consolodate the  
>>Workspace Managers' window system to avoid window-itis, like the Finder  
>>typically has. (You know, 30 windows open to get at the file you need).
>
>My hard drive is not organized THAT badly. :) I never have to open more
>than 4. Generally this doesn't happen tho as I can just hold down the  
option
>key and then whenever I open a folder, the window I double-clicked in
>to do it closes. 

Well, here at BYU's Computer Consultation Center, we have a Novell file  
server with about 200 user accounts and huge numbers of applications,  
utilities, and information files.  To organize it in an intelligent  
manner, you're dealing quite typically with 10 subdirectories to go  
through before you find the thing you want.  Aliases help, but not for the  
amount of stuff we're dealing with here.

This is actually pretty typical for shared file systems.  Might I guess  
that your machine is pretty much stand-alone, perhaps even a home  
computer?  In that case, the Finder works great.  But for situations like  
mine, it's not so good anymore.


>Or I can use list views to put more than one level in
>one window. 

If you think about it, this is pretty similar a notion to what the NeXT is  
doing with its file viewers.


   
>Is there a way to do this more conviniently that the default I've seen,
>namely that you must explicitly ask for annother window to get one?  
(which
>introduces a several-second delay, at least when Ive seen it used)

Unfortunately, no.  NeXT assumed NeXT users would never have teeny file  
systems.  Of course, we all know what happens when you assume.  :-)



>I see. The "big file system" is the key here I think; on the mac you  
don't
>need to have a deep file system, and that seems to make quite a  
difference.

Well, it depends on what you do.  For *personal computer* users, you  
certainly have no need for a *deep* file system, but I find that even more  
than, say, 4 or 5 window-opening exercises gets to be a pain.  And I think  
quite a few users have that situation regularly.  If your work is broad  
enough, aliases aren't as useful as they would be normally, since you  
can't have aliases for *everything*.  :)



>>The Finder is more intuitive, but it suffers when you get into large,  
>>highly hierarchial file systems.
>
>How large does it have to be to trip it up?

No, the question is, how large does it have to be to start being a pain?   
I think 5 folders deep is about right.


[referring to option-clicking etc.]
>I never found these tricks hard. And why the need for particularly
>extreme speed here? Can't you just hold down the option key- and keep
>it that way till you've got where you're going?


Because they're tricks.  Wasn't the Mac a machine that didn't require  
tricks?  There should be a more intuitive way.


[Referring to the Finder not being like its predecessors]
>Its already a long way from there. Of course things have changed- apple
>has added some of the shortcuts we are describing, plus things like
>heirchial list views, nested folders, desktop icons and aliases.
>
>Todays finder is not the same critter that the 128k used. That it seems
>the same is undoubtably intentional- Apple seems to like continuity.


You'd be surprised how similar it is, when comparing it against, say, the  
Workspace Manager.  Try using it on a big file system like I described  
above and you'll understand what I mean.  As these become more prevalent,  
we'll be seeing more of a need to do something like NeXT did, at least for  
big stuff.



--

Sean Luke
Brigham Young University                   MILK:  It Comes From Cows
sean@digaudio.byu.edu  
NeXTmail and nifty Mac stuff welcome
Xref: sparky comp.os.ms-windows.advocacy:2723 comp.sys.mac.advocacy:2709