Re: [Usability] tools on the desktop



On Sat, 2005-07-30 at 21:35 -0400, Jason Hoover wrote:
> On Sat, 2005-07-30 at 18:12 -0400, Rodney Dawes wrote:
> > I like using the "Eject" button on the drive. It works nicely. :)
> 
> Really? Linux locks mine, and when I use a screwdriver it throws a
> fit. :/

Because it doesn't work for everyone currently doesn't make it ideal.
If that were the case, then nothing would be ideal unless it was already
the current behavior, so we can just throw all these mail threads out
the window then, since it already works ideally.

> Why does every conversation about fixing the eject situation always
> degrade into one of the following categories?
> 
> 1) Works for me.
> 2) We should fix the way media is mounted anyway.
> 3) Let's add an icon on top of another icon!
> 4) Let's make a panel applet!
> 5) Trash cans don't make any sense...
> 6) Allow eject via trash anyway so people don't get too lost.

Because, the current situation isn't ideal. The ideal solution is a
combination of 2 and 2, maybe allowing 6.

> Personally, my opinion is somewhere around a hybrid of 4 and 6. The
> reasons being (per category):
> 
> 1) It doesn't work for joe-point-and-grunt, and you're assuming everyone
> can right click (tablet PC's), or worse, is smart enough to look there.
> I've seen cases where people have used screwdrivers on the floppy drives
> (With Mac OS) because they were so desperate.

You're also assuming everyone is smart enough to drag an icon to the
trash can to eject it. Because some people use right click and some
people use the trash, doesn't mean one or the other is perfect.

> 2) Okay, we'll just send an e-mail to the Free BSD kernel people, Sun,
> and Linus, and politely ask them to make all media removable with no
> consequences for every kernel version in existence, like windows! Or
> even better make a VFS method!

This is not how Windows works. It in fact does require you to "unmount"
some certain devices. It just happens that the most common use case is a
cd-rom, which cannot be written to anyway, so Windows already does the
right thing for the user there. Mac OS is not perfect currently either.
And, mount behavior in the desktop, does kind of have to corelate with
the mount behavior in the OS that it's running on top of. Windows and
Mac OS at least have the advantage of only having to support ONE
operating system.

> 3) I have a hard enough time with my trackball and IBM nubby thing as it
> is, imagine aiming for something that small when it's scaled down for an
> 640x480 screen on some embedded thing. (Think compact flash here, or
> something) Even worse, think about a11y.

The icon thing is broken. Icons themselves should not be interactive
like that. I didn't suggest it. I replied against it. so please don't
attack my rebuttal in that way. An emblem to indicate that it needs to
be unmounted might be useful, but requiring the user to unmount with
that icon, is just broken.

> 4) I'm actually behind this one quite a bit, if it's done in a way that
> it makes logical, obvious, and fast (no more than 2 clicks or 1 drag).
> Currently, right clicking is not obvious, which is a problem for the
> trashcan as well. Maybe we could clean up the drive mounter applet a
> bit?

So the user can have duplication between the panel and the desktop? And
how is a 24px tall panel any easier to click than the icon suggestion
that initiated this thread? This is in fact, how Windows works though.
There is a "stop devices" thing in the systray, and you have to open it
and stop the device that you want to remove.

> 5) No, they don't. But neither do doorknobs, knobs are usually pulled,
> not twisted. Some homes use levers, which are easier and faster, but
> most have knobs. We currently use a button hidden under a secret panel
> down the hall.

This just makes no sense at all. Your analogy is a bit off. There are
knobs on all of my stereos to adjust the volume. One of those stereos
also has a knob for tuning radio stations. My desktop machine has a
little knob to adjust the cpu fan speed too. The floor lamp in my living
room has a knob to turn it on and off, with two levels of brightness.
Many older CRT display monitors also had knobs to adjust display
settings. A knob is one of the most intuitive user interfaces there is,
in the real world. They don't translate well to application UIs though,
as there is no physical feedback through screen, and you can't grab and
twist or turn them. Knobs tend to twist or turn in both directions as
well, though, those that don't, do not tend to vary in the direction
they do turn.  However, levers in fact, are usually pushed or pulled,
and not twisted or turned. Levers on doors are initially confusing, as
they are not door knobs, and there is no indication if it is to be
turned, or pushed, or pulled. They also do vary a lot between different
doors, or devices.

> 6) This is my personal opinion, see number 5. Maybe we can give them a
> lever (see number 4, a panel) by default and let them use a knob
> (trashcan) if they insist.

The panel already does too much. The only way to add or remove things
from the panel is through your button under a secret panel down the
hall. We should however, just eject when dragging media to the trash.
Popping up an error is just dumb. We can do the right thing there, so we
might as well do it.

> Am I missing any of the other typical outcomes of this discussion? If my
> logic is wrong, please don't hesitate to politely point it out and
> correct me. This isn't aimed at anyone's personal opinion about it,
> these just seem to be the discussions and comments that are brought up
> every time, and the end conclusions that are drawn. I'd love to see some
> new ideas thrown at the issue.

A new idea might be to try and work toward doing the right thing, rather
than just giving the user more ways to discover they can use to work
around the wrong behavior. If there are issues in the kernel, or mount,
or whatever, then those issues should get fixed, not used as excuses for
maintaining the same crappy path of existence. :)

-- dobey






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]