paul@torch.UUCP (Paul Andrews) (01/11/89)
norman@cogsci.ucsd.EDU (Donald A Norman-UCSD Cog Sci Dept) writes: >...Moving the disk image into the trash can to ejectthe disk >is a violation that bothers many people at first usage, but seems >perfectly natural after just one or two uses... Well this STILL bothers me. I feel extremely unsafe doing this and indeed have witnessed people totally delete a folder because they forgot it wasn't a disk! Less drastic but still annoying in the Mac desktop metaphor is that moving a file from one folder to another sometimes copies it and other times moves it. This one just requires a little thought before doing it but the whole point about a spatial interface is that it isn't supposed to require any thought (like driving a car). While we're on the subject I have always thought that use of the word 'metaphor' to describe the Mac interface is somewhat pretentious. As several people have pointed out it actually resembles a desktop very little. It is just a spatial interface to a computer. Some of us find this type of interface easier to learn and use than textual interfaces. This is because humans have evolved to handle largely spatial problems, text (and abstraction) are relative newcomers to the scene. That said, I have met people who claim to think of things in a textual fashion rather than a spatial one. To use a metaphor (!) how do you navigate when driving? Do you remember street and place names or do you remember a location and how to get there from here? I would be very interested to know if anyone has gathered any statistics on this sort of thing. - Paul.
domo@riddle.UUCP (Dominic Dunlop) (01/17/89)
In article <223@torch.UUCP> paul@torch.UUCP (Paul Andrews) writes: > [Stuff deleted] >Less drastic but still annoying in the Mac desktop metaphor is that moving >a file from one folder to another sometimes copies it and other times moves >it. Yeah. I despair that people still come up with file heirarchies where you can see physical disks (or things which pretend to be them) for no good reason. If the thing's removable then, yes, there's a reason for making the joins visible, but if it's part of the furniture (even of furniture set up by some administrative function before you enter the room -- woops, sorry, wrong metaphor) I maintain it should be seamless. The UNIX analogue to moving a file between folders is the mv command. This indeed sometimes has to copy the file from one physical device to another behind the scenes. But it never results in there being two copies of a file where before there was only one. I suppose it could do, but to do so would be inconsistent with UNIX' metaphor of an hierarchical file system that is as seamless as possible. You really want a copy? OK. Use cp. (Yes, yes, I know that you can get bit if you try to use the other alias for mv, ln, across physical devices -- sorry if you were expecting perfection.) I guess life could be worse: the Mac disks might be called A:, B:... (Probably one of Digital's better ideas for the 1960s. Just a pity that twenty million users are still living with it because CP/M appropriated it in the 1970s.) -- Dominic Dunlop domo@sphinx.co.uk domo@riddle.uucp
mrc@Tomobiki-Cho.acs.washington.edu (Mark Crispin) (01/19/89)
There's one problem with the "seamless filesystem" as exhibited by Unix, and that is that there are sometimes instances when you really do want the seams. Specifically, I've had instances on Unix where I was building/maintaining a parallel filesystem to the boot filesystem and I would have killed to have the function of A:, B: (although I would have used somewhat more imaginative names). In other words, it would have been nice if I could have done: % cp -r /b/*foo* mnt: to copy all files and directories from /b/*foo* to corresponding names on the filesystem that would result if the system was booted from the device labelled mnt:. I eventually decided that the easiest way to do what I wanted was to tar it, cd to the desired base directory, and to un-tar. It isn't necessarily the best solution to allow a co-equal mounting at the root with parallel access based on a syntax such as ":" (although this is undeniably a way to do this). I would rather have something that lets you substitute all or part of the current tree path inside some other part of that path. I agree that forcing co-equal moutning at the root based upon a device boundary is a loss.
hassell@tramp.Colorado.EDU (Christopher Hassell) (01/19/89)
In article <973@riddle.UUCP> domo@riddle.UUCP (Dominic Dunlop) writes:
#sorry, wrong metaphor) I maintain it should be seamless. The UNIX
#analogue to moving a file between folders is the mv command. This indeed
#sometimes has to copy the file from one physical device to another behind
#the scenes. But it never results in there being two copies of a file
#where before there was only one. I suppose it could do, but to do so
#would be inconsistent with UNIX' metaphor of an hierarchical file system
#that is as seamless as possible. You really want a copy? OK. Use cp.
#(Yes, yes, I know that you can get bit if you try to use the other alias
#for mv, ln, across physical devices -- sorry if you were expecting
#perfection.)
Ah but isn't copying an Inherent function that is importantly different
from the idea of "moving"? I think it would be VERY nice if you could
simply turn the pointer into something and VOILA', you pull out "copies"
and set them whereever the heck you please to. If they are on the same
disk let em be! It would be nice if the mac could work up its own
scheme for "backup" and leave symbolic duplication for us to play with.
The idea of "moving/dragging" is overloaded with that of copying. This
is a hole in the paradigm that the mouse provides. I still think that putting
a "copy" to the printer would be a VERY appropriate and intuitive idea, unless
the printer is a xerox machine which takes it and hands it back to you.
There are LOTS of VERY logical and intuitive ways to use the mouse-as-hand
paradigm. I personally think that nearly NONE of the system stuff should be
left to the user. (i.e. if you take a file to the trash, warn you if its the
ONLY "link" left because the system knows where it keeps its duplicates. Maybe
even make a FORMAL diff-format for each application and use that as a
compacted version of "duplication/modification".
Anyone got any ideas one how to show pipes? How about having a palatte or
something made up from pull-down/over/across/out panels and "snapping"
their icons together? How about putting files on either end? Putting
it in the background by closing up *all* the outlets, or finding a place
to put them that would allow them (something like standard error could
have a window to spooge in). In this case a window is ONLY a way
of "opening" a file and the format coming out from a pipeline could
determine what kind of window stuff gets put in (graphics, text, readouts etc..)
I think that there are only too many ideas that people haven't thought about
that *AREN'T* just cute (like moving/bouncing windows!!) but are utile and
finding *specifically* what the problems are with using the more promising ones.
I notice that too few people talk about the *exact* problems they have with
stuff except for the good old keyboard/mouse stuff. These are certainly
valid areas to pursue.
#I guess life could be worse: the Mac disks might be called A:, B:...
#(Probably one of Digital's better ideas for the 1960s. Just a pity that
#twenty million users are still living with it because CP/M appropriated it
#in the 1970s.)
I DO hate it when that happens.
#--
#Dominic Dunlop
#domo@sphinx.co.uk domo@riddle.uucp
### C>H> ###jec@iuvax.cs.indiana.edu (James E. Conley) (01/20/89)
You can do this with UNIX (at least Berkeley UNIX, don't use SissyV much around here). There is a system call called "chroot" that allows you to set a place in the file system as the root of the file system. When we were running Ultrix and needed to run things in a 4.3 environment we justed used a program called "root43". It isn't quite as convenient as A:, B: but it is more powerful in that you can use an arbitrary directory as the new root. James Conley Indiana University Computer Science jec@iuvax.cs.indiana.edu