What makes up a "User" in a Class Object? (was Well factored Objects)

Darius squeakuser at inglang.com
Wed Apr 30 01:16:28 UTC 2003


I enjoyed Richard A. O'Keefe's treatise on name representation in class objects:

"People don't have names.  Instead there is a *relation* between people and 
names."

This touches a little on my concerns about Graphics User Interface 
representation. Please excuse any of my lack of insights for I’ve a psychology 
degree and work as a programmer. [A *real* “Computer Analyst”]   ;)

Why is there no persistent class representing the user in total? 
Shouldn’t there be something at the Kernel level? 
Why is such a person only represented by keyboard strokes and Hand Morphs?
Isn’t the most cherished person in our programming life, the "user", more than 
an I/O port?

A person has memory, a unique place and time, a skill level, a purpose, a 
single focus or locus of attention at any moment, modes of communication across 
devices, learning styles, personality types, and limitations to the above 
(among a few other things...). Every sent communication and every stored data 
element has a purpose for a person or a group which is most often lost in 
today’s data representational systems. A person is also a member of several 
groups for which that person shares an identity an which act as a proxy on 
their behalf.

All this relates directly to the data use and functionality of any application.

People don’t _have_ fingers. Instead there is a *relation” between what people 
want and what their fingers do.

People don’t _have_ eyes. Instead there is a *relation* between what they see, 
what they remember from what they see, what they know. 

They quickly shift their focus or locus of attention over time. They imagine 
half of what they see by filling in from memory. They focus on juxtapositions 
both of what’s similar and what contrasts. They compare what they see to a 
cognitive map or mental heuristics of what they expect. They give attention to 
the information that has an emotional impact on themselves.

Why don’t we create class hierarchies of our GUI’s to match the already 
researched rules of cognitive science?

At this point I should say “But there's also a simple solution." But I can’t. 
The best I can do is refer you to a more detailed exploration of the topic in 
Jef Raskin’s “The Humane Interface” 
http://humane.sourceforge.net/humane_interface/hollands_review.html

Certainly Squeak with its OOP methodology could get us there and gain notoriety 
in the process.

Cheers,
Darius



More information about the Squeak-dev mailing list