Re: Off switch blues

In article <barmar-09AB6F.12091901112008@xxxxxxxxxxxxxxxxxxxxx>,
Barry Margolin <barmar@xxxxxxxxxxxx> wrote:

In article <uce-D76880.17284631102008@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Gregory Weston <uce@xxxxxxxxxx> wrote:

In article <barmar-8DFE7A.15223831102008@xxxxxxxxxxxxxxxxxxxxx>,
Barry Margolin <barmar@xxxxxxxxxxxx> wrote:

In article <uce-202D2B.11051431102008@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Gregory Weston <uce@xxxxxxxxxx> wrote:

In article <barmar-6D292D.20524630102008@xxxxxxxxxxxxxxxxxxxxx>,
Barry Margolin <barmar@xxxxxxxxxxxx> wrote:

But it's defeats the object of a quick shut down / restart
cycle
if I have to unplug all usb (and prehaps firewire as well)
devices. I say: it's not a feature it's a bug.

Bugs are by definition unintended behavior. You're describing
intended behavior. The fact that you don't like it doesn't make
it a bug. If you can document that this does more harm than
good
in the general case, the proper term is a misfeature.

What you're describing is an implementation bug.

Not in this case. In this case it's a correct implementation of a
justified design.

What I meant was that when you said that a bug is "unintended
behavior",
you were referring to implementation bugs.

Please don't tell me what I meant. It's quite rude, especially when it
contradicts what I've told you I meant.

Your message was very clear about what you meant, you gave a precise
definition. I was just pointing out that this definition did not apply
in the context, because the previous poster was using the word in a
different sense than your definition.

AKA: A wrong sense. That's why I responded with a correction and offered
alternative terminology. The definition I gave *is* the definition of
"bug" in the context of computers. The fact that some people misuse it
doesn't change the meaning, just as the meaning of "niggardly" isn't

If enough people misuse it, it DOES change the meaning.

Not automatically. Not when the word to whom the people actually matters
*don't* misuse it, and the people to whom the word "bug" really matters
are developers.

Certainly it's true that languages (those in use) are dynamic, fluid
things. That's a very different statement from suggesting that every
word, in every context, is eligible for for arbitrary, whimsical
redefinition. Some words, in some contexts, must mean something or they
have no use. You can go around asserting that a meter is 36 inches and
have the community of engineers for whom that matters go along with you.
You can't, similarly, start declaring that "bug" applies to subjective
user perception issues and have the community of software developers
say, "Oh, okay. That's fine." There has to be a word that means "this
thing isn't behaving the way it should by some formal, definable
standard and it needs to be corrected." That word is "bug."

changed by people who think it's an ethnic slur. As I wrote before, if
you can demonstrate that an intended behavior is in general a net
liability, you can call it a misfeature. There is no term for "doesn't
act the way this one guy in Sheboygan expected it to." Nor should there
be.

So what's the word for "doesn't act the way many (maybe even most) users
would expect"?

Given the importance of predictability to effective and efficient UIs
that could fall into the area of misfeature which you could, if you
like, consider a design bug. But it *has* to be true in general. It
can't be a relative handful of people saying "I didn't guess this would
work this way."

Suppose the specifications for a word processor say that the Edit->Copy
command should cut, and Edit->Cut should copy. If you're the programmer
and you implement this, you haven't done anything wrong. But whoever
wrote that specification certainly did. Few users would expect these
commands to behave this way. This is clearly a bug in the specification
(except maybe in some exceptional cases, like the program is intended as
an April Fool's Day joke).

Yes. Clearly it is. Because it would hit *every* user in the entire
world that has used a graphical UI for more than 5 minutes. Again,
different from one guy in Sheboygan.

There are other types of
bugs, for which that is not the definition. A design bug could be
defined as unwanted or unexpected (by the user) behavior.

You're using a very loose definition of the term "bug" when you start
talking about deviations from user expectation. It largely depends on
how well-founded the user's expectations were in the first place.

Yes, the word "bug" has a loose definition.

But it doesn't. It means unintended behavior.

The dictionary on my Mac says "an error in a computer program or
system". There are lots of kinds of errors.

But going with your definition, who decides what's intended?

The designer of the system. Often based on formal specifications for the
components that designer is using. Hopefully also based on significant
amounts of usability study.


It
obviously didn't do what the OP intended. When I put my laptop to
sleep, close the lid, and unplug the keyboard, it's because I intend to
STOP using it. I don't intend for it to wake back up until I open the
lid. It doesn't wake up if I unplug it in the first few seconds (while
it's still in the process of going to sleep), but if I wait too long
(when it actually achieves sleep) it wakes back up. That makes me think
that the designers didn't really intend that unplugging a keyboard
should always wake up the computer.

If I use a hammer to pound in a wood screw it's not going to work as I
intended. Is that a bug in the hammer or the screw? No. It's user error;
I'm using the system in a way for which it wasn't designed. User needs
and expectations certainly *inform* the design, but that doesn't mean
that user desires dictate the design. Users get to approve or reject the
design by buying (or not buying) the product. The reality is all
computers suck today. Optimally we pick the one that sucks least for our
needs and desires. Possibly we feel moved to complain to the vendor if
we feel *really* strongly about some especially large gap between
expectation and reality.

I believe that this is an unintended side effect of the hardware
requirement that the computer wake up to check what kind of USB event it
received.

But as the OP points out, it's certainly possible for the machine to
*completely* ignore USB events. And as you point out it's
technologically possible that the machine could go back to sleep *after*
checking. It seems very presumptuous to assume that at no time in the
last 10 years did a single employee in Apple's computer, OS or
management teams think of these alternatives.


I don't pretend to have perfect knowledge of everything every user or
peripheral developer in the world might want to do in response to some
random system event. Perhaps it's something as simple as wanting to log
the fact that it happened. Considering the range of hardware than can
today be hooked up via USB, let's say I simply don't feel comfortable
pronouncing that there might be some event to which no one could
possibly want to react.

So it logs that it happened and goes back to sleep, like I said.

What's "it?" What happens if "it" (or perhaps a completely different
"it") wants to do something other than simple logging? Again, you're
taking a specific example that doesn't apply to you and then saying the
idea being exemplified doesn't apply to anyone. Maybe I want my notebook
to actually do real work for the next few hours tucked under my monitor
stand. I don't need it to be plugged into anything and I don't need to
see the screen; I just need it to chug along. Tickling the USB with my
thumb (drive) is the easiest way to do that.


The issue isn't that it wakes up (the USB architecture effectively
requires this), the problem is that it STAYS awake, even though the user
hasn't taken any action that could reasonably be interpreted as wanting
to use the computer. He hasn't typed anything, opened the lid, or moved
the mouse.

There's space between "wanting to use the computer" and "wanting the
computer to remain awake for an arbitrary amount of time for some
purpose" as illustrated above. The solution for the machine that wakes
up due to events the user doesn't care about is to configure *that*
machine to sleep after a certain amount of inactivity. Granted sometimes
the machine may fall asleep if the user is "using" it in way that's
fairly passive for an extended period of time, but there's a solution
for that, too; a program that prevents sleep by virtue of running is a
few lines of code. (I know this because I wrote it 6 months ago in
response to someone on Usenet looking for such a thing.) Make it a login
item and as long as you log out when you don't intend to use your
machine it should work as you want. If you need more control, adding the
ability to define and recognize a hot corner to suppress sleep may
expand the source of the program to as much as a whole printed page.


You can always come up with weird cases that 0.1% of the time might be a
reason to wake up, but that doesn't mean it's a good idea to implement
the system that way. Default behavior should handle the normal cases,
not one-in-a-million situations that few users would expect.

But that's the problem. You're assuming that *your* situation is the
normal one. How do you know your situation isn't the weird 0.1% case?
Where's your data that justifies the expense inherent in changing the
current behavior?

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix
.