# Marken uncertainty; customers

**URL:** <http://discourse.iapct.org/t/marken-uncertainty-customers/6744>\
**Category:** CSG1994\
**Created:** [June 3, 1994, 2:11pm UTC](http://discourse.iapct.org/t/marken-uncertainty-customers/6744 "1994-06-03T14:11:05Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![\_Martin\_Taylor](http://discourse.iapct.org/letter_avatar_proxy/v4/letter/_/a9adbd/32.png) [@\_Martin\_Taylor](http://discourse.iapct.org/u/_Martin_Taylor)\
**Post date:** [June 3, 1994, 2:11pm UTC](http://discourse.iapct.org/t/marken-uncertainty-customers/6744/1 "1994-06-03T14:11:05Z")

</div>

[Martin Taylor 940603 09:30]

> Rick Marken (940602.2100)
> 
> > Martin Taylor (940602 2020) --

> > I'm usually dealing with the uncertainty of the state of the real  
> > world given a perceptual signal.
> 
> Then this uncertainty cannot be controlled, becuase it is not,  
> itself, a perceptual signal. This uncertainty is clearly a side effect  
> -- something you can notice about what a person is doing (like  
> noticing that there is a frequency distribution of keypresses over  
> the different keys on the keyboard) -- but that is neither  
> perceived nor controlled.

That's correct. This uncertainty is perceptible only to the analyst  
who can measure both the perceptual signal and the state of the outer  
world. This is the uncertainty that I am working with when I talk about  
information theory descriptions of the actions of simple (or complex)  
control hierarchies.

Don't confuse the uncertainty used by the analyst with the uncertainty  
currently under discussion when we look into Paul Revere's head. If  
Paul is to perceive uncertainty, and to control that perception, he  
has to have an ECS whose input function provides a signal that is the  
level of uncertainty in some other perceptual signal about its CEV.  
That "uncertainty-control" ECS cannot use at all the same inputs as  
the analyst would, and it probably will not get the same results the  
analyst would.

> Now I only wonder why ANYONE (besides a few crazy scientists) buys PCT.

Because it works, FOR THEM, when explained in their terms. Ask Ed Ford.  
And Bill Cunningham. The customers' terms are not PCT terms, but their  
problems can be handled using PCT at least as well as using any other set of  
principles, because PCT deals with everything people do.

So the PCT-consultant's job is to show how to solve their problems better  
than they can do without PCT, AS WELL AS to explain to them what is happening  
in language they can understand. Sometimes, ad-hoc solutions work fine,  
but then there's not much for a consultant to do anyway (but don't tell  
the customers that).

> Could you explain to us what you explained to your customers?  
> What is useful about PCT to your customers? I think this would  
> be very useful information to have.

It depends on the problem. Let's say you have a machine like a VCR for  
which you want to design an interface. What does everyone say about VCRs?  
It takes a Ph.D. specializing in VCR programming to use one properly?  
That's bad human factors. Now look at it from a PCT viewpoint. What  
does the user want to perceive? Let's say that there are a set of things  
possible, including that a particular tape contains a recording of a show  
to be broadcast at a time the user will not be in the house. The designer  
must think of others possibly desired perceptions. If the user is to  
be able to control for this perception to achieve its reference value,  
certain other perceptions are necessary, some of which can be facilitated  
by the VCR designer, and some not (such as labelling and filing of tapes).

Next stage: what different sets of perceptions might provide the desired  
top-level perception? That there is a tape, for one. Is the VCR design  
such that the user can easily see that a tape is installed? That there  
is a selected program--channel, time, duration. Can the user see that  
the desired program is selected? Now we have VCR codes on programs, so  
the perceptions channel, time, duration may be all compiled into the code.  
But this is a perception prone to error--23156 is easily misread as 21356--  
so the designer has to recognize that the code has to be turned into  
something more likely to be perceived as being what was wanted or as being  
in error and needing correction. Does the VCR code presently allow this?  
I don't know, but if it does not, then to use it is a poor substitute for  
a well designed VCR interface that eases the user's ability to perceive  
the states of the recorder relevant to the top-level perception.

When you start talking about interfaces this way, people often say "yes,  
that's what I see." But when you deal with what people "do" (i.e. output  
action) with the interface as the primary factor, things get complicated.  
It is hard to deal with: "Set the program record channel, time, and duration  
and install a tape; to set the program time, push button X and then Y and  
then enter the desired time in 24-hour clock mode..." The designer who  
thinks that way builds interfaces like the VCRs we see on the market today.

Martin