[cap-talk] getting authorization from the user and the great insight

[Jed Donnelley]

On 10/4/2007 4:13 PM, Ka-Ping Yee wrote:
> John Carlson wrote:
>> My question is, is every action the user makes authorization?  For
>> example, does drawing a line give the system authorization to change
>> an image?  Or does opening the image give the user the authorization
>> to draw a line?   What draws the line between something that requires
>> authorization and what doesn't?  Or is authorization something that
>> is inherent in the design?
> 
> I'll weigh in here.

Thanks Ping, I was hoping you would.

> Every action the user makes is a command.

That far I'm with you.

> In an ideal design, commands and authorizations are the same thing.

Interesting.  I think perhaps I can see how you may be
interpreting "authorization" loosely enough to make the
above sentence make sense.  I don't generally interpret
it that that way, but perhaps I need to have my horizons
(definition?) broadened.  I'll state my viewpoint
below where it seems more appropriate.

> For example, suppose you have a personal assistant who takes care of
> things for you.  You say, "Please return these library books for me."
> This is a command and also an authorization -- it is reasonable that
> this authorizes your assistant to take possession of the library books,
> since that is inherently required by the command.

I can see that.  However, in my experience for the vast
majority of actions I take on computer systems I do
not intend them as authorizations and I hope they
won't be interpreted that way (e.g. "harvested"
for such a purpose).  More below.

> Jed wrote:
>> It seems to me that any effort to "harvest" all
>> (or even only some not explicitly designated user
>> actions) for authorizations is that it would create
>> a seriously conflicted and confusing situation with
>> regard to how users view their actions.  For example,
>> I don't want to have to worry that drawing a line
>> from one project icon to another in a project
>> management program might inadvertently cause some
>> potentially unwanted authorization to happen.
> 
> Whether it's a good idea to "harvest" knowledge from user actions
> depends on what you mean by "harvest".  In Jed's example, the action
> of drawing a line seems arbitrary and unrelated to authorization.

Exactly.  Let me mention a few more.  All the typing of
text in this message that I'm typing.  Almost any other
set of actions intended to do "editing" (e.g. text,
multimedia, etc.).  My example above was intended to
be intermediate between such purely graphical editing
and something at a slightly higher level (e.g.
picturing projects).  Moving a slider up and down
on the side of a browser window.  Moving a window
from one position to another on my desktop.  Adjusting
the volume or contrast in an application. ...

The examples of actions that I hope are not considered
as authorizations goes on and on.  It is the ones that
are interpreted as authorizations that I hope are few
and well understood.

However, ...  I can understand a possible interpretation
of the term "authorization" to include the above.  For
example, my pressing of the "a" key that resulted
in the entering of that "a" into this text could be
interpreted as an authorization for my email client
to insert the character "a" at the above point where
the cursor was pointing.  To me such a general
interpretation of the term "authorization" makes
that word almost meaningless.  The working definition
that I am using for the term "authorization" is the
act of granting a running program (active object)
access to something (the ability to take some action)
that it didn't previously have.

> But what is the context of the action?  If the line represents a
> relationship that inherently requires an access grant, triggering
> authorization doesn't seem so farfetched.  What if the diagram is
> a depiction of projects and subprojects, and drawing the line from
> X to Y means that the purpose of subproject X is to achieve a
> subgoal necessary to project Y?  Then perhaps the team working on
> project Y should gain access to the documents in subproject X.

To me this feeds directly into the point I was trying to make.
It is vitally important to me as the user to know the difference.
Most of my actions at a computer I assume (hope to know) are
not to result in "authorizations" in the sense I defined
at the end of my last paragraph.

If some of my actions are to be interpreted as authorizations
in the above sense then I have a potentially higher vested
interest in making sure the program responding to my actions
interprets my actions as I intend, so I want to be sure I know
what those actions are and how they will be interpreted.

> In other words, it all comes down to mental models.  It's not so much
> whether "harvesting" is taking place as whether the authorization fits
> the user's model of how interactions are being interpreted.

- which for me means it is that much more important to
insure that the user's mental model of what authorizations
will correspond to which of their actions and the authorization
actions of the program responding to the user's actions
coincide.

I definitely do not want programs that may be aware of
my actions that I do not consider authorizations to
be "harvesting" some of those actions and interpreting
them as authorizations.  I just moved the slider on
my email window down.  I don't want that to result in
an authorization any more than I want this typing to
do so - at least with my interpretation of the term
"authorization."

What I want is clarity of the model.  I want to know
exactly which of my actions the program that responds
to them will consider as authorizations and for what.

I think the CapDesk example:

http://video.google.com/videoplay?docid=-7961423532989255419#20m16s

is particularly good in this area:

1.  If I double click on an object, it makes sense to me
that the application associated with an object of that
type will be given access to the object (e.g. a file).

2.  If I drag an object over and drop it on an application
icon (or window), it makes sense to me that the program that
is initiated (or is running) would be given access to that
object.

3.  If in a "Power Box" open object (e.g. file) dialog
window I grant access to some object to an application
named in the window (as in the CapDesk example), it makes
sense to me that I would be granting the application
access to the object.

4.  If I copy and paste a link (capability, reference)
to an object into an application window or onto an
application icon (e.g. into the "location" window in
a capability browser), it makes sense to me that I would
be granting the application access to the object.

5.  If one object contains the rights to other objects
(e.g. as a directory object might contain rights to
files or other directories within it), it makes
sense to me (though others might have to learn this model)
that by granting an application access to the container
I'm also granting the application access to what's
inside the container.

For me actions like the above are all I've ever needed.
I can certainly imagine other possibilities, but I'd
want to be very clear just which actions were going
to be interpreted as authorizations and what authorizations
would take place in response to those actions.

I believe in the KISS principle, particularly when
applied to something like authorizations (in the
sense I've used it - possibly more narrow than your
intended meaning?)

I get very concerned when somebody tells me that they
want to "harvest" all my actions and interpret them
as authorizations.

Please tell me why I shouldn't be concerned, but rather
should learn to love such a harvester implementing the
great insight.

--Jed http://www.webstart.com/jed/