Who's clueless, the computer or the user?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2.4.2005, space aliens observed muckerheide saying:
>This general problem would seem to be fixed with a straightforward
>solution: Establish a design practice that any icon or other display
>that can be changed by clicking on the icon/value have an image that
>informs the user.
>
>[A nice idea, but such levels of standardization often run afoul of
>different cultural expectations and interpretations. -Adam]

There are already widely accepted user interface conventions for
"clickable" items. I can think of three:

 - an embossed faux-3D effect (like for buttons)
 - an arrow on the left of the text (iTunes actually does that in its
   info field)
 - Underlined text (like on the web)

Not including any hint at all and expecting people to find a feature by
simply trying to click on everything is utterly absurd. I can quite
frankly not understand out how people can defend this kind of interface
insanity or even go as far as claiming it's the user's fault for not
finding a feature which is hidden in such a way.

lucas

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.2.2

iQA/AwUBQk65aLXYdom/dB2cEQKApACgubQ4n0C/X0I7BScAPDXBUBMTTwEAnAn7
lcQHOpsr4K7RctL8L+cY/M0e
=U6U0
-----END PGP SIGNATURE-----

> On 29 Mar 2005, at 20:34 :43, Larry Rosenstein wrote:
>> There's no visual clue that clicking on the time will do anything.
>> How is a user supposed to figure this out except by someone telling
>> them?

But someone does tell them: it's documented here:

<http://www.apple.com/itunes/hottips/>

m.

--
matt neuburg, phd = matttidbits.com, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide! NOW SHIPPING...! (Finally.)
http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/

On Apr 1, 2005, at 8:42 AM, Muckerheide wrote:

> This general problem would seem to be fixed with a straightforward
> solution: Establish a design practice that any icon or other display
> that can be changed by clicking on the icon/value have an image that
> informs the user. This could something like the alias marker, with
> e.g., a tiny option selection up/down arrow image, or a background
> color.
>
> [A nice idea, but such levels of standardization often run afoul of
> different cultural expectations and interpretations. -Adam]

But iTunes already has EXACTLY such a convention! The iTMS links are
little right-facing arrows, and next to the "LCD" time/jumpy-EQ section
is a similar right-facing arrow which cycles the display through
various modes. If they just put one of those little arrows next to the
playlist time display, it would be 100% obvious.

It would also be ugly.

I could also argue that this feature is irrelevant for a large number
of users, and thus can be hidden as a power user trick for those who
want it. It still ought to be documented, but you know how that goes.
:)

--Nik

At 15:24 -0800 UTC, on 2005/04/01, Jochen Wolters wrote:

>> I see a lot of this sort of thing, where people blame the computer for
>> something it can't do or doesn't do or does wrong, when in fact it's
>> the users who are just being too gormless to click the mouse or try
>> something similar.
>
> As others have pointed out in this thread, there is just no visible
> clue at all that tells you that you can change iTunes's time display
> format by clicking on it.

I'm tempted to think a key element to this is "convention".

Experienced users know that in many Mac apps, holding down the Option on
functions changes to a variant of that function. In the case of menu items, a
good app will provide feedback to show the name of the variant command when
the Option key is held. But that double-cliking a folder in the Finder while
holding the Option key will open it /and/ close its container[*], provides no
visual clue. Same for Option-clicking a Window's close box to close all
windows. Yet all this has been in Mac OS since about System 7 or so.

(My impression is that the books on Mac OS typically not mention essential UI
conventions like this. But I certainly haven't read them all...)

A new user won't easily discover this without being told by someone. But once
you know, it quickly becomes second nature to use.

If the UI itself should indicate things like this to new users, I think you
risk making things too messy for experienced users. You don't want tooltips
to pop up everywhere all the time (To my taste Mac OS X is doing to much of
that currently).

Possibly changing the cursor (to a pointer with an exclamation mark dangling
from it) could indicate that something exciting will happen when you click at
the current position. But even this won't reach everybody. Some of the users
I train do not notice cursor changes *at all*. Even after I've told them
about it many times. And thus they're always unaware of whether an object can
be grabbed, or is a text field, or can if a rectangle can be drawn, etc.
{sigh}

I think beyond a certain point the only realistic approach is to tell users
to not be afraid to experiment. For thise users who remain afraid still, I
can think of no amount of icons/cursors/tooltips that will change that.

Btw, the UI concept of being able to click text to have it display the same
differently isn't new. You could do the same in Anarachie's transfer windows,
way back. IIRC the old Finder's copy window allowed that too - so you could
have it say the speed in different units, or in total averages vs current
speed. Things like that.

[...]

> _Option_-Click on those iTMS links (the
> little arrow icons) next to a song title, artist, or album, and iTunes
> takes you to that title/artist/album inside the Library.
>
> Why didn't the UI designers make this feature more obvious, e.g., by
> having the ALT-key toggle the menu entry between "Show Current Song"
> and "Show Current Song in Library"?

Agread, the menu should reflect this. In fact it does in the case of iTunes'
Advanced->Convert Selection to MP3, which changes to "Convert to MP3..." (so
you can convert files without having to add them to iTunes' Library first).


[*] I just learned that launching iPhoto while holding the Option key brings
up a dialog to allow you to pick a Library. That means that there's a split
second between the moment the Option key's meaning is sent to the Finder, and
to iPhoto. Seems pretty braindead to me. Apparently the iPhoto team is
unaware of the Mac UI... IMO *this* sort of nonsense is a much bigger hurdle
for new users than 'hidden' functionality such as clickable text. (Not that I
ever liked anything about iPhoto myself.)


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On Apr 4, 2005, at 12:42 PM, Lucas K. Mathis wrote:

> There are already widely accepted user interface conventions for
> "clickable" items. I can think of three:
>
> - an embossed faux-3D effect (like for buttons)
> - an arrow on the left of the text (iTunes actually does that in its
> info field)
> - Underlined text (like on the web)

If none of those, either the cursor should change when moved over it,
or the item itself should hilight or change its appearance in some way.

On 4/4/2005 9:55 AM, "Sander Tekelenburg" wrote:
> (My impression is that the books on Mac OS typically not mention essential UI
> conventions like this. But I certainly haven't read them all...)

Hey, some do ;-) It just depends whether the author is looking at their book
as a way to get users to understand the OS as a whole, or as a way to teach
them individual tips. These are different approaches that are appropriate
for different users.

At 7:42 AM -0800 4/1/05, Muckerheide wrote:
>This general problem would seem to be fixed with a straightforward
>solution: Establish a design practice that any icon or other display
>that can be changed by clicking on the icon/value have an image that
>informs the user. This could something like the alias marker, with
>e.g., a tiny option selection up/down arrow image, or a background
>color.
>
>[A nice idea, but such levels of standardization often run afoul of
>different cultural expectations and interpretations. -Adam]

It's on the right path, but I think it would lead to visually busy
windows, and that, in itself, can be a barrier. However, I think
there are a couple of useful UI behaviours that could be borrowed
from web browsers and the late lamented Hypercard.

1) Many web page buttons sport rollover effects to indicate
clickability. The effects don't have to be garish and they don't
intrude when you're simply looking for something in the window.

2) HyperCard had a great feature which I'd love to see adopted by
web browsers (and other apps): holding down the command and option
keys at the same time caused a small gray outline to appear around
all the active (clickable) elements on the page.

Dave

At 04:58 -0700 UTC, on 2005/04/05, Dan Frakes wrote:

> On 4/4/2005 9:55 AM, "Sander Tekelenburg" wrote:
>> (My impression is that the books on Mac OS typically not mention essential
>>UI
>> conventions like this. But I certainly haven't read them all...)
>
> Hey, some do ;-) It just depends whether the author is looking at their book
> as a way to get users to understand the OS as a whole, or as a way to teach
> them individual tips. These are different approaches that are appropriate
> for different users.

True. Both are valid approaches. But they are immensely different approaches
and it's important to me to know which approach a book takes before I'm
comfortable suggesting it to someone. To me this is the most important thing
to know about a book, but it doesn't seem be mentioned clearly in reviews.
(I'm thinking a description a la a spec: "explains concepts: true/false",
"provides standalone tips & tricks: true/false", much like a software review
would mention "supports AppleScript: true/false" ;))

I once made the mistake of suggesting Mac OS 9 for Dummies, which turned out
to not explain basic concepts. The result was that this user was 'learning'
specific things, without gaining much understanding, which made him fill in
the logic by himself, wrongly. So everytime he had a question that the book
did not answer, he was stuck and had to come to me again and I had to beat
some wrong notions out of his head before I could start to explain how things
really work. (Learning is easy, unlearning is *very* hard.)

Recently I suggested Robin Williams' Mac OS X Panther book[*], which, judging
by what I read about it, *does* seem to explain basic concepts. I haven't yet
had a chance to see it myself though. Hopefully later this week.

I think an extra reason why I think books should explain these basic concepts
is that that is the sort of thing that works well in book form - something
you can read through from beginning to end, even away from the 'puter. But
for someone who just wants simple guidance on how to achieve a specific task,
you need documentation that can be quickly and effectively searched. I think
a Web site, preferably with QuickTime movies, is more appropriate for that.
Something along the lines of what Apple did at
<http://www.apple.com/pro/training/macosx_basics/>,
<http://www.apple.com/pro/training/fonts/>,
<http://www.apple.com/pro/training/printing/>,
<http://www.apple.com/pro/training/colorsync/>. But there should be more like
that, and for some reason there doesn't seem to be a single page listing all
of them. (I found them once, when they were new and Apple mentioned them on
some announce Web page I happened to keep track of.)


[*]
"The Robin Williams Mac OS X Book, Panther Edition"
by: Robin Williams
publisher: Peachpit Press (March 23, 2004)
ISBN: 0321232968


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

{sigh}

How appropriate:

     +++++ begin forwarded text +++++

To: Sander Tekelenburg <tekelenbeuronet.nl>
Subject: Out of Office AutoReply: Who's clueless, the computer or the user?

        [...]

Hi,
I'm on a course today. Back tomorrow, April the 8th.
Regards,
Torsten Götlind
_______________________________________________________________________
Torsten Götlind E-mail: <mailto:------------------->
SCA Hygiene Products Phone: +46 31 7460240
R&D Feminine Fax: +46 31 7461910
SE-405 03 Göteborg
Sweden

     +++++ end forwarded text +++++

Now who is clueless in this case? The computer or the user?

No matter how easy 'puters are made to use, in the end it is the user's
responsibility to learn to use it. A hammer is easy to use. When someone uses
it for screws, is the hammer to blame?

Of course .vacation is more complicated than a hammer, for most people. But
isn't it the user's responsibility to at least be aware that with a
communication system, doing things wrong might affect other people? Isn't it
reasonable to expect users to only use such systems when they understand them
well enough to use them correctly?

--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On 5/4/2005 4:55 AM, "Sander Tekelenburg" <tekelenbeuronet.nl> spake thus:

> You don't want tooltips
> to pop up everywhere all the time (To my taste Mac OS X is doing to much of
> that currently).

And occasionally tooltips seem to go berserk, at least on my home machine (I
can't remember it happening on the G5 at work, but I may just not have
noticed it). It seems to be Safari that's most at fault for this --- a
tooltip appears then basically gets "stuck" in a sort of flickering mode,
and you can't really do much else until the fit passes, usually after a few
seconds.

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger

At 06:51 AM 04/08/2005 -0700, Sander Tekelenburg wrote:
>Now who is clueless in this case? The computer or the user?

Absolutely the computer. Why is the combination of .vacation and mailing
lists set up so that it's even possible for a vacation response to go to
the originator of a message that came via a mailing list? Simple: because
it grew rather than being designed, and the result of that growth is pretty
mangled. This is a superb example of a clueless computer.

>Isn't it
>reasonable to expect users to only use such systems when they understand them
>well enough to use them correctly?

Let he who is without sin cast the first stone. How many here have only
used software features which they understood absolutely, fully, in every
ramification? I didn't think so. Certainly not me. When the software
advertises that it can do something, it should do it right unless the user
explicitly overrides it.

Sander, basically you are saying it's OK for the computer to do things
wrong until a human stops it. I say the computer should do things right, or
else not at all, unless a human stops it. And it's making the computer do
it wrong that should require thorough understanding.

Edward

Art Works by Melynda Reid: http://paleo.org
Art Works by Melynda Reid: http://paleo.org

At 11:47 -0700 UTC, on 2005/04/08, Edward Reid wrote:

> At 06:51 AM 04/08/2005 -0700, Sander Tekelenburg wrote:

        ["out of the office" bots]

>>Now who is clueless in this case? The computer or the user?
>
> Absolutely the computer. Why is the combination of .vacation and mailing
> lists set up so that it's even possible for a vacation response to go to
> the originator of a message that came via a mailing list?

But I'm not claiming it was wrong to target the originator. IMO it would be
just as wrong to target the mailing list. Sending either one an "out of the
office" message is useless. And it's annoying to the recipient. (It also
doesn't take a rocket scientist to figure out that the more people do that,
the more it affects email usability as a whole.)

> Simple: because
> it grew rather than being designed, and the result of that growth is pretty
> mangled.

I agree that that is part of it. OTOH autoresponders may have grown along (I
don't know - I've never had a need to use one). AFAIK they tend to already
know they shouldn't be sending the same "out of the office" message to the
same address within a certian time span. And I would think that they should
even be able to recognise a mailing list (assuming mailing lists can offer
some sort of ID, such as the List-ID header that TidBITS-Talk carries).

But not every computer or every program works/behaves well. It will always
remain up to the user to pick the right tool - which means he'll have to be
prepared to bother to understand some of what matters.

> This is a superb example of a clueless computer.

Maybe. But if you get down to the bottom of it, 'puters *will* be clueless
about 'right' and 'wrong'. 'Puters are things that do what they're told to
do. Thus it will always be up to the user to know/understand enough to tell
the 'puter to do the 'right' thing. (If computers would know 'right' from
'wrong', then things like spam or viruses or even trojans wouldn't be
possible.)

Is the 'puter to blame when you embed 30 100KB images in a single HTML
document? Is the 'puter to blame when you send your text as an attached
".doc" file, instead of embedded text? Is the 'puter to blame when you never
make back-ups? Is the 'puter to blame when you hit reply, type "me too" and
not trim any part of the previous message?

Computers are just tools. Users need to (bother to) learn to use them.

If only because otherwise things just will never ever work reliably. The ease
with which today's society accepts "computer error" as a reasonable
explanation for just about any problem never seizes to amaze me. Until people
start realising that computers are just tools, made by and used by people and
therefore a "computer error" will always essentially will be a "human error",
things will only go wronger and wronger.

>>Isn't it
>>reasonable to expect users to only use such systems when they understand them
>>well enough to use them correctly?
>
> Let he who is without sin cast the first stone.

Hehe :) OK, I phrased that a bit too strong :)

But what I meant to address was that while there are certainly many aspects
of today's computers that can be improved upon so as to make 'puters easier
to use, the user will still always carry some responsibility to use the right
tool for the right job correctly. The only way to rid us of /that/
responsibility would be for computers to be able to both read our minds and
be aware of how an action would affect others and whether or not that is
considered 'right' or 'wrong'.


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

On 8 Apr 2005, at 12:47 :48, Edward Reid wrote:
> At 06:51 AM 04/08/2005 -0700, Sander Tekelenburg wrote:
>> Now who is clueless in this case? The computer or the user?
>
> Absolutely the computer.

No, it's the user. Or it's A user. vacation(1) has known how to
deal with mailing lists properly for on towards 10 years now. It is
moronic implementers of outdated or poorly designed .vactions that
are at fault. Or you can blame Microsoft for their piss-poor
implementation in their mailers.

> Why is the combination of .vacation and mailing
> lists set up so that it's even possible for a vacation response to
> go to
> the originator of a message that came via a mailing list?

If you use vacation and a properly configured list, then, from the
man page:

        nor
        is a notification sent if a ``Precedence: bulk'' or
``Precedence:
        junk'' line is included in the mail headers.


Many lists, however, use Precedence: list instead of the proper
Precedence: bulk, which does take patching vacation. However, it is
something the admin of the machine should do on any system that
allows vacation to run.

> Simple: because
> it grew rather than being designed, and the result of that growth
> is pretty
> mangled. This is a superb example of a clueless computer.

Not in the case of vacation(1) it's not.

In the case of MSFT's mailers, then yes, it is the computer (or the
feeble programmers)

On 4/11/2005 7:54, "Sander Tekelenburg" <tekelenbeuronet.nl> wrote:

> But I'm not claiming it was wrong to target the originator. IMO it would be
> just as wrong to target the mailing list.

It is. The responder shouldn't respond to lists at all. I'm not even sure
that Microsoft Lookout Express can even be set up to check that (its mail
rules--filters--are "somewhat weak" from the viewpoint of one versed in
Eudora or Mailsmith or Mail.app rules...forcing us to some warning header
designs we'd rather not use). Not to mention procmail, but the number of
users of procmail is statistically insignificant.

Most mailing list software deals properly with most half-way reasonable out
of office responses. List admins tend to deal with the rest by
unsubscribing the offender (and some admins bar them permanently for a
second offense).

  --John

At 11:58 PM 04/08/2005 +0200, Sander Tekelenburg wrote:
>But I'm not claiming it was wrong to target the originator. IMO it would be
>just as wrong to target the mailing list.

I totally agree. vacation programs/features should not respond at all to
mailing list traffic. (In fact it's only happenstance of historic
implementation that private email and mailing list traffic occupy the same
stream. But that's another conversation.)

>'Puters are things that do what they're told to
>do. Thus it will always be up to the user to know/understand enough to tell
>the 'puter to do the 'right' thing.

Aye, but there's the rub. Why the user? OK, "user" is a rather general
term, but I'm distinguishing between end users (who I call "users") and
those who are responsible for programming and setting up the computer: the
software engineers (we used to be programmers) and system administrators. I
include us as part of "the computer" (though at times we are end users
too). We are the ones responsible for the way the computer behaves.

Yes, computers do what programmers and sysadmins tell them to do. It's our
job to make sure we tell them the right things so that the end user can do
hisser job and not spend a lot of time figuring out the computer.

I expect my car to start when I turn the key, stop when I press the brake,
turn right when I turn the steering wheel right. While it's true that I
need some skill to use these features effectively, I don't expect to have
to understand basics. If the car doesn't stop when I press the brakes, I
take it to a mechanic.

At 09:26 AM 04/09/2005 -0600, Google Kreme wrote:
>It is
>moronic implementers of outdated or poorly designed .vactions that
>are at fault. Or you can blame Microsoft for their piss-poor
>implementation in their mailers.

So you agree, it's the clueless computer, not the end user. Where
"computer" includes the software engineers, system administrators, etc, and
what we create -- those of us who are supposed to be making the computer
work for the end users.

Absolutely, computers are designed and programmed by humans. We who do
these tasks are the ones who should be protecting the end users. We have
met the enemy, and he is us.

>Many lists, however, use Precedence: list instead of the proper
>Precedence: bulk, which does take patching vacation. However, it is
>something the admin of the machine should do on any system that
>allows vacation to run.

See above. "The computer" includes administrators. It's the clueless computer.

>Not in the case of vacation(1) it's not.

I never blamed 'vacation' alone, but rather the combination of elements: I
specified 'vacation' and mailing lists, and by implication included
software engineers and system administrators. The end user doesn't give a
rat's patoot which piece is to blame: it's a clueless computer.

Edward

Art Works by Melynda Reid: http://paleo.org

At 14:36 -0700 UTC, on 2005/04/11, Edward Reid wrote:

[...]

> I'm distinguishing between end users (who I call "users") and
> those who are responsible for programming and setting up the computer [...]

Agreed.

> Yes, computers do what programmers and sysadmins tell them to do.

No :) Programmers and sysadmins *define how* the computer does what the end
user tells it to. It's still the end user telling it what to do.

And there's just no way that programmers/admins will ever be able to
anticipate completely what an end user might do with the 'puter - users
*will* show unexpected behaviour. (We shouldn't even want to anticipate it
all. Creativity is vital. (And the only way to allow for creativity is to
allow rrom for user errors.))

> It's our
> job to make sure we tell them the right things so that the end user can do
> hisser job and not spend a lot of time figuring out the computer.

Agreed. I just don't think that that ever *can* mean that end users won't
have some level of responsibility for how they interact with 'puters. I think
it is unrealistic to view this as a black vs white issue. There's an immense
ocean of grey there. Both the engineers/programmers/admins and the users each
have their responsibility.

This is why I 'advocate' both points of view in this thread. Neither is
right. Both are right.

> I expect my car to start when I turn the key, stop when I press the brake,
> turn right when I turn the steering wheel right. While it's true that I
> need some skill to use these features effectively, I don't expect to have
> to understand basics. If the car doesn't stop when I press the brakes, I
> take it to a mechanic.

A problem with such comparisons is that most (all?) other machines are made
to do 1 thing whereas a 'puter is built specifically to do 'anything'. Thus a
user *will* be confronted with choices, which require him to be capable of
making those. Making things easier for the user requires lessening his
options to only the ones he wants/needs. This of course is already being done
by vendors on the level of different hardware, different operating systems
and different configurations. But that still leaves the user having to choose
the operating system and configuration that is right for him.

The computer industry enforces this tension by advertising computers as "can
do everything you want". Yes, they can, but that's exactly what bites a lot
of users. If it can do what someone somehere wants to do then it can do
something you do not want to do, but will be confronted with. (At the same
time it is too easy to blame the industry/ads. Many people don't want to
investigate what system would be best for them.)

Another difference is that a car can be seen, touched, heard. The only thing
people 'see' of a 'puter is the screen and keyboard (most people consider the
monitor "the computer", even when there's a loud monster uinder the desk).
Nothing about what the 'puter does is anywhere near as real as what a car
does. Some of the brightest people just become instantly 'stupid' the moment
they have to deal with a computer. There is something about the abstraction
level that they can't seem to grasp. While I strongly feel that there is a
lot of room for improvement (I consider Macs great in the sense that
everything else is much worse), I do not think it's realistic to expect that
computers will ever be so 'good' that users can't make mistakes anymore.

[...]


--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>

At 12:44 AM 04/12/2005 +0200, Sander Tekelenburg wrote:
>And there's just no way that programmers/admins will ever be able to
>anticipate completely what an end user might do with the 'puter

The case in point was sending 'vacation' replies to mailing list traffic.
There is no conceivable valid reason that an end user would ever do that.

>A problem with such comparisons is that most (all?) other machines are made
>to do 1 thing whereas a 'puter is built specifically to do 'anything'.

Only from a programmer's point of view. The typical end user acquires a
computer for specific purposes, typically email, the web, writing papers,
and (more and more) photography. And a variety of niche applications, such
a genealogy. It can "do anything" for the end user only in the sense that
they can buy software to do things, if they know what software to look for.

>Some of the brightest people just become instantly 'stupid' the moment
>they have to deal with a computer.

And how exactly does that differ from cars?

Edward
Art Works by Melynda Reid: http://paleo.org

On 4/12/2005 10:36, "Sander Tekelenburg" <tekelenbeuronet.nl> wrote:

> And there's just no way that programmers/admins will ever be able to
> anticipate completely what an end user might do with the 'puter - users
> *will* show unexpected behaviour. (We shouldn't even want to anticipate it
> all. Creativity is vital. (And the only way to allow for creativity is to
> allow rrom for user errors.))

Somehow, I'm reminded of the story, real or otherwise, of the support call
which ended with the support tech saying, paraphrased, "Pack up the computer
and take it back to the store. Tell them you're too stupid to have a
computer."

  --John

Sander Tekelenburg wrote:
>there's just no way that programmers/admins will ever be able to
>anticipate completely what an end user might do with the 'puter -
>users *will* show unexpected behaviour.

I've seen this stated as, "There's no way to make anything foolproof,
because fools are so damned ingenious."

Carl

At 5:26 PM -0800 2005/03/28, Matt Neuburg wrote:

>I'll start the ball rolling with one of mine. Since Mac OS X first came out,
>one thing that has driven me crazy is .dmg images that contain multiple
>files. Why? Because it isn't enough to drag everything they contain onto my
>hard disk: first I have to make a folder on my hard disk and then drag the
>stuff from the dmg image into that, so as to keep it all together.
>
>Last month, after years of inwardly complaining, I discovered there's
>another way: Option-drag the proxy icon from the dmg window title bar onto
>the hard disk. Presto, it makes the folder for me and copies its contents,
>in one move. D'oh! m.

        I read about this over a year ago, but (perhaps because I
misremember the key) it doesn't always work. What does always work is
Command-up, which shows me the list of all volumes, and I can then
drag the volume to the sidebar.

        Today I (again) noticed that you can't drag a volume (SMB in
this case) into the sidebar, just folders. That's dumb. Even dumber
is that you *can* drag it into the (right side of the) Dock.


                                                Chris
--
Chris Pepper: <http://www.reppep.com/~pepper/>
Rockefeller University: <http://www.rockefeller.edu/>