Make it quantitative when possible, or at least logical.

28 Aug 2004 - 11:38pm
10 years ago
3 replies
540 reads
Jef Raskin
2004

On Aug 28, 2004, at 8:32 PM, Andrei Herasimchuk wrote:

> On Aug 26, 2004, at 1:33 PM, Jef Raskin wrote:
>
>>> "Initial-user-learnabilty" is a jargon term often used to disguise
>>> an opinion used in meetings to push one's own design politics.
>>
>> On the contrary, it is a measurable quantity. In particular you
>> establish a criterion for success (e.g. correctly uses the command
>> within time t some percentage p of the attempts) and measure how long
>> or how many trials it takes for a statistically significant number of
>> naive subjects to meet the criterion.
>
> Like I said, a fancy term to describe an opinion. What is the
> "criterion for success?"
>
> It tends to go a little bit like this usually: Users should be able to
> to do task in two seconds. (Why? What is so relevant about two
> seconds?) Therefore, I'll create a "initial-user-learnability" metric
> to measure against.

You miss the point. The criterion is chosen to allow you to compare two
or more methods in terms of learnability so that you can see which is
better. How "it tends to go" is irrelevant, as how X or Y does it may
or may not be how it should be done. Could you give me references as
to here you got the "two seconds" from -- I don't think so because you
just made it up.

Setting up a reasonable criterion, which may be from under two seconds
to over six months depending on the task, is part of the experimental
design. Given a particular case, we can choose one that is meaningful
in the context of the task to be done and the resources available.

>
> What about context? What about emotional connection to task
> completion? What about long-term efficiency, where going slower might
> create steadier results and longer term efficiency? What about focus
> and attention, where multiple things might be going on for the user
> outside the current task?

What about them? They are among the other factors to be considered. I
never said that time to learn to use a widget or set of widgets to some
criterion was the only factor. Just because there are many factors does
not invalidate any one of them. I think that your comment here fails to
be logical.

>
>> Efficiency is defined objectively in "The Humane Interface",
>> Addison-Wesley 2000, pp 83 ff. Because you don't know what it is
>> doesn't mean that it has no meaning.
>
> I don't need a lesson on what the term efficiency means.

Then please tell me what it means to you.

>
>> If two methods are otherwise equal, and one sometimes loses
>> information the other does not, the one that loses information has
>> lower efficiency.
>
> That completely misses the point of context and its impact on the
> methods.

Again the fallacy that because a particular measure does not measure
everything it is wrong. Efficiency is one factor among many, and in
some circumstances it is an important one.

>
> You claimed a cut command was inefficient as compared to a move
> command because of the risk from cut in losing information. That risk
> is just a risk, it doesn't make move inherently more efficient.

Of course it does. Higher risk means that more effort is wasted, and
thus the cut-and-paste effort is less efficient. But perhaps you have a
different definition of "efficient", which is why I ask for your
definition. You say you don't need a lesson on what it means, perhaps I
do: educate me.

> Further, as the example Sandeep pointed out, move can sometimes
> impede on the fly work if one's attention gets caught by something
> else to fix. There are many other examples of these sorts of pros and
> cons for both move and cut. Enough that I don't think you can make
> blanket statements about move being inherently better than cut and
> paste.

>
>>> Got it that you think cut-and-paste is badly designed and
>>> troublesome. Got it that you think designers are not asking the
>>> right quetions. That doesn't make cut-and-paste badly designed and
>>> troublesome.
>>
>> But it is. You haven't shown otherwise, and I've given references and
>> methods that show it is troublesome. And most users have had it cause
>> them trouble. You'd have to have your head in the sand to not see
>> this happening.
>
> How is cut and paste badly designed? It does what it was meant to do:
> cut information away. It even uses a word that has dangerous yet
> precise meaning! Is a knife badly designed because one might slip on a
> wet floor and fall on it killing themselves? It happens occasionally,
> so are knives badly designed?

Just because something is dangerous in the physical world does not mean
we have to copy that danger in our interfaces. We can use the
flexibility of software to do better. The knife may or may not be badly
designed, but if you can provide a different tool that gets the job
done and which won't kill you if you fall on it, you should provide
such a tool.

BTW, why does a system need a Cut command when it already has a Delete
key on the keyboard?

>
> Adding a move command to the toolbox is a fine and lofty goal.

Not fine and lofty, just practical and better for users. Have you ever
built a move-and-copy system and tried it on users? I have, and the
preference for it quickly becomes clear. A typical reaction is "why
doesn't everybody do it this way?". You are speaking theoretically, and
I am speaking both theoretically and with some experience.

> A move command has it use and I agree it has strengths. But to use
> the justification for move that cut is badly designed and needs to go
> based on some sort of criteria of intial-user-learnability and
> frequent-user-efficiency jargon is the kind of thing that gets
> designers in trouble in meetings.
>
>> The very best interface cannot be expected to make a broken method
>> work.
>
> You claim that cut-and-paste is broken. I claim that's false.

It is broken because it needlessly causes users to lose material from
time to time. Anything that hurts users when they make a mistake is
broken.

>
>>> In fact, when most designers do push outside of what is familiar,
>>> trying to add new tools that might prove useful, they are usually
>>> shot down by "experts" like Nielsen telling them to do what is
>>> familiar.
>>
>> Don't malign my friend Jakob.
>
> Too late for that. I assume you've never read anything on my web site.
> Further, Nielsen brings it on to himself as near as I can tell. Just
> read the reactions from designers on my articles to see that.

I have read much of your site. There is even one essay which is
surprised at how good some of his work is. I don't agree with him at
all on many issues, I am not a lover of his use of English. But he's
generally competent.

Have you read my book?

>
>> If you are restricted to current methods and widgets, his
>> recommendations are very good as to how to use them well.
>
> Even when you are not constrained in that regard, Nielsen would claim
> to play it safe and return to the familiar.

That's also my greatest problem with his work. We agree on that.

> Most of what he has written these last ten years has been exactly
> about this point. I don't see how this can be disputed with what
> Nielsen has written for the record.
>
>> As you've put the word "expert" in ironic-quotes to refer to Nielsen
>> and "leader" in ironic-quotes to refer to me I take it you have an
>> animus toward us. Care to explain why?
>
> Just repeating. http://www.useit.com/jakob/

If you use quotes to indicate that you are quoting some source, you
must give the source, otherwise the quotes, as you used them, mean that
you are being ironic. Your misuse of punctuation was the problem here.

>
>> Not at all, that would violate the interface principle of monotony.
>> They should replace Cut and Paste with Move. The details can be
>> looked up, but I am sure you can figure out a good interface design
>> for yourself.
>
> I completely disagree with you. Cut and Paste has its place.

Why? Because Microsoft uses it? Let's have a reason. I have not found
one instance where it is superior or otherwise justifies having a place
in a user interface.

> I also think Move is fine and dandy too. The are many contextual
> issues with both that have to be considered. Sandeep mentioned one,
> another is holding different kinds of data in memory, from words to
> pixels to vectors and pasting each in different apps while crossing
> tasks,

That is an implementation issue, it is independent of whether to use
Cut-and-paste or Move-and-copy.

> another is moving data from one app to another, like from email into
> Word where context of the data and focus might completely switch on
> the user. They both have positives and negatives.

What are the negatives of Move-and-Copy in these circumstances? Between
apps you just select (as with Cut-and-Paste), shift focus to the other
app, choose your spot, and use the Move commands. No negatives I can
see. If you get interrupted in the middle, forget what you were doing,
and start another Move, you have lost nothing, unlike the Cut method.
It's a win in every case.

>
>> But, in this case, if you will recall, I was responding to somebody
>> else's post which used "Initial-user-learnabilty", and was responding
>> in their terms out of courtesy and so as not to muddle the discussion
>> with one about terminology. I do not use that term in my own work, so
>> you are yelling at the wrong party in that particular case.
>
> I missed that message in the thread then, and I apologize for thinking
> you added it.

Apology accepted.

Jef
>
> Andrei
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

Comments

30 Aug 2004 - 10:27am
Dave Collins
2004

>BTW, why does a system need a Cut command when it already has a Delete
key on the keyboard?

Because:
1] delete and cut are not the same function
2] even if they were, not everybody is a keyboard user
3] s/w should provide multiple entries to tasks, like menus, which are
- discoverable
- mouse-activated

>so if the OS gave you, say, 100 clipboard "undos" out of the box, how
big an issue/risk would this still pose?

Would mitigate the prob somewhat, but not an ideal solution. It is
merely providing a way to *recover* a screw up instead of discouraging
it in the first place. Also, once your million dollar idea has now been
dumped into a big pool of clips, it is a whole separate task to find and
recover that specific one - interrupting workflow.

Or more succinctly, _if it's never lost in the first place, it never has
to be found_.

30 Aug 2004 - 5:58pm
Jef Raskin
2004

On Aug 30, 2004, at 9:27 AM, Dave Collins wrote:

>
>> BTW, why does a system need a Cut command when it already has a Delete
> key on the keyboard?
>
> Because:
> 1] delete and cut are not the same function

This is a long discussion, but why aren't they the same? The idea is
that there is something there that you want to remove. To use "cut" and
then "paste" when you really want to just move something is to use two
commands where one would do.

> 2] even if they were, not everybody is a keyboard user

Both delete and cut can be on the keyboard, or both can be on the
screen. I suggest therefore that this is not a distinction between
them.

> 3] s/w should provide multiple entries to tasks, like menus, which are
> - discoverable
> - mouse-activated

Multiple entries to the same task or one entry for each task? I am not
clear as to what you mean here. And (the flip side of what you said
earlier) not everybody is a mouse user.

>
>
>> so if the OS gave you, say, 100 clipboard "undos" out of the box, how
> big an issue/risk would this still pose?
>
> Would mitigate the prob somewhat, but not an ideal solution. It is
> merely providing a way to *recover* a screw up instead of discouraging
> it in the first place. Also, once your million dollar idea has now been
> dumped into a big pool of clips, it is a whole separate task to find
> and
> recover that specific one - interrupting workflow.
>
> Or more succinctly, _if it's never lost in the first place, it never
> has
> to be found_.

This I agree with totally.

Jef

>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>
>

5 Sep 2004 - 3:18pm
Andrei Herasimchuk
2004

On Aug 30, 2004, at 4:58 PM, Jef Raskin wrote:

> This is a long discussion, but why aren't they the same? The idea is
> that there is something there that you want to remove. To use "cut"
> and then "paste" when you really want to just move something is to use
> two commands where one would do.

You have yet to acknowledge the cases where it makes sense to have one
command "remove and don't hold in memory" the data in question and one
command to "remove it and keep it in memory so I can paste it
elsewhere, maybe even multiple times."

Andrei

Syndicate content Get the feed