Re: [Usability] triple mouse click behavior

[Nadyne Mielke <nmielke acm org>]

At 06:41 PM 2/19/2004, Maurizio Colucci wrote:

Since you snipped (without noting) all of my requests for citations, I'm 
going to assume that you are lacking anything even remotely resembling 
evidence to support your claims.

[snip]

> > so they can't find anything anyway.
> non sequitur.  They can, by scanning the list with their eyes, or by 
> narrowing
> the list it by keyword (see below).

It is utterly trivial for a user to not be able to find something in a 
lengthy list.  Haven't you ever missed something that was right in front of 
you?  You can continue to insist that visual clutter is a good thing, but 
you have nothing to back up your assertion.

For visually-disabled users that use a screen reader, a lengthy list 
dramatically increases the amount of time that they have to spend doing any 
task.

> > frustration.
> no frustration. They are learning so they are not concerned about speed of
> execution.

Err, to quote from something you write later in your post:
You can't be serious here.

Do you really believe that a new user isn't interested in completing their 
task in [what they view as] a reasonable period of time?  They're willing 
to deal with a 'learning curve', but any learning curve that is too steep 
will lose the vast majority of users.

> In the learning phase you have to understand what the program can do and
> quickly find HOW TO DO it. Not DO it quickly; quickly find out how to do it.
> There is a big difference. In that phase, scanning a long list is not a
> problem, because you are not concerned about speed of execution. The
> important thing, in that phase, is that it must be obvious WHERE TO LOOK for
> the option. i.e. in which list you will find what you need.

This is nothing more than your opinion, and you have not yet provided 
relevant research (such as a usability study that you have conducted 
yourself) to back up your statement.

[snip]

> What can must be done to fix it? We can use the fact that the idea is already
> in his mind, translated for free into english. We put a flat list with all
> the things that can be done, unstructured, and make it searchable by keyword.
> This way you solve all the learnability problems: 1) the user immediately
> knows where to look for anything (in that list) 2) the user immediately knows
> whether and how a given thing can be done.

This assumes that the user knows the word that you are using for the task 
that they want to perform.  You've brought up the example of burning CDs 
earlier, which is an excellent example.  There are lots of words that the 
user may have 'translated for free into English' [or their native language, 
of course].  They may want to 'burn a CD', or 'create a CD', or 'copy data 
from the hard drive onto a CD', or 'make a CD'.  Your list methodology 
means that either (a) the user has to learn your term for completing their 
task, or (b) you have to have every single way that the user might refer to 
the task in the list.  (b) is, quite clearly, an unobtainable goal: there's 
always going to be someone out there who comes up with a different way to 
describe the task in English.

> To render the searching time irrelevant, the just enters some keywords (which
> he already knows) and the list narrows to show only the actions that are
> related to the keywords (syntactically and semantically of course).

Searching time is never irrelevant.  If the user enters the wrong keyword, 
or makes a typographical error, then the user has to spend more time on 
their task.

> Now, the fact that this is not in your schoolbooks does not imply you
> shouldn't be able to grasp it at the third attempt.

Ahhhhhh.  This appears to be the crux of the issue: you don't trust 
'schoolbooks'.

I am simply asking for proof of your statements.  It doesn't have to be in 
a traditional textbook; in fact, I would question its relevance if it is in 
a textbook, since books very quickly become out-of-date.  A simple 
usability test would be sufficient.  Until such a time that you have 
actually conducted a usability test to test your assertions, then such 
assertions are nothing more than conjecture.

> Your solution (SHIFT+
> ARROWS) has obvious learnability problems I won't even state.

I can't recall ever using the word 'solution'.  I said that shift-arrow is 
the method that is available to do what the original poster wants to do 
(and at the level of granularity that he wants, since he noted issues with 
punctuation and white space).  I asked a few questions about how 
triple-click to select a sentence might work, since it was unclear to me at 
first glance.  (Ultimately, of course, a usability study would be required 
to determine if users prefer sentence+punctuation or 
sentence+punctuation+whitespace.)  Further, I noted that breaking the 
mental model for users who are used to the current triple-click behaviour 
may not be optimal.

> >  > The consequence of this kind of reasoning is that 80% MSWord users don't
> > use styles, but keep formatting each paragraph explicitely.
> > Do you have a citation to back up your claim that '80% [of] MSWord users
> > don't use styles'?
> Sorry, I don't have many schoolbooks.

I'm not asking for schoolbooks.  I'm asking you to explain where you got 
such a statistic, and why you think that this statistic is relevant.  If 
you're going to quote numbers, it is valid for me to ask where it came 
from.  In this case, as with essentially everything else that you have said 
here, the number appears to be nothing more than conjecture on your part.

> > Further, do you have any citations that show that any
> > sizeable percentage of MSWord users actually have a need (whether they
> > realise it or not) to use styles?
> You can't be serious here.

In fact, I am serious.  When I am not serious, I will mark it clearly to 
ensure that there are no questions about my intent.

MSWord is a widely-used application.  There is a pretty sizeable body of 
work that discusses various usage patterns, as well as usability issues of 
various versions of the application.

/nm