5. Positive Space

15 Tuesday Sep 2026

Posted by petersironwood in creativity, design rationale, love, nature, psychology, Uncategorized, user experience

Tags

aesthetics, art, beauty, books, Christopher Alexander., Design, freedom, greed, growth, HCI, life, nature, pattern language, Patterns, politics, psychology, responsibility, usability, user_experience, UX

5. Positive Space

(This is the fifth in a series of 15 blogs that explore Christopher Alexander’s “Fifteen Properties” of good design, natural beauty, living spaces, etc.).

Life is a dance on the edge between chaos, on the one hand, and sameness & repetition on the other hand. Repetition without variation or change is not life. On the other hand, endless random variation without any pattern or principle is also not life. Planet Earth is sometimes said to be a “Goldilocks Planet” — not too hot and not too cold — to support life. Most of the life forms on planet earth themselves exhibit a “positive shape” — a shape that wants to expand and fill out — and yet, there are limits because of circulation, gravity, communication etc. so that growth is typically not unrestricted. The tension between trying to grow and having to stick close enough to form creates positive space.

Life may not always be “a bowl of cherries” but nonetheless, a bowl of cherries does illustrate the property of “positive space.” The bowl connotes living things trying to expand right up to the boundaries possible. A bowl that is filled with cherries and even slightly over-filled but without inducing a fear of spillage, to me, connotes life being vigorous and healthy. To me, a single cherry sitting all alone in a large bowl seems to exhibit positive space much less — at least at the scale of the bowl.

When I look at an individual cherry, I also see positive space. The cherry is not a perfect sphere, featureless and smooth. If it were, to me, it would be a much less positive space. The fact that there is a stem and a noticeable indentation where the stem goes provides a kind of center. So too does the slight asymmetry of the cherry. It appears as though it might have developed as two halves that tried to circle a space at the same time from two different directions – clockwise and counterclockwise. They met and merged to form the almost spherical cherry.

The lobes of this red pepper show positive shape.

The cherry is not the only natural food that has this kind of positive space. Think of corn on the cob. Each kernel seems to have tried to grow as large as it can. It pushes up against and into other kernels. Each kernel seems therefore to be “bursting with life.”

Consider a cucumber. It’s roughly cylindrical. But “roughly” is important here. To me, it would seem much less an example of “Positive Space” if it were literally a cylinder. It tapers at the ends and it bulges at the middle. That seems more “positive.”

To a person who doesn’t understand that life is primarily a cooperative endeavor among all the parts of the vast tree of life, but instead sees the world only as a zero-sum game, it must seem as though the positive living space of a cucumber makes the space around the cucumber less positive and less living. But this is not true! The space around the cucumber’s slightly rotund shape is much more positive and living than the space around a perfect cylinder.

Think of a tree trunk compared with a telephone pole. They are both made of wood and they are both approximately cylindrical. But a tree trunk feels much more alive to us than a telephone pole. I don’t think this is simply because we “know” a tree is alive. It looks more alive and if you allow yourself to “tune in” to it, it feels more alive. And, importantly, not only does the space that the tree inhabits seem more living. So too does the space around it! A long line of telephone poles may exhibit “Levels of Scale” and “Alternating Repetition” and such a picture may make us feel some life to it.

But a single telephone pole does nothing to stir life in me. In that sense, it’s nothing like a tree. It’s flat and it kills the space on either side as well. The columns in the Parthenon are roughly cylindrical and obviously not literally alive. But they, unlike a telephone pole, have positive space and create positive space around them. Life is not fundamentally a zero-sum game. The bee does not “steal” the flowers pollen and thus damage the flower. The bee helps the flower. The flower helps the bee. Positive space in an object does not steal from or detract from the space around the object. It enhances it!

Similarly, the “competition” for space among the kernels of corn on a cob of corn shows that competition can be a beautiful thing. I like to see the kernels pushing against each other. All of them seem living and positive. Imagine instead a cob of corn in which one kernel had grown like a giant spider of orange cancer and took up 98% of the cob. Aside from this one ultra-greedy cell, there were only a few widely spaced and shriveled up kernels. Would you pick that from the pile of corn? Would you want to slather it with butter and bite into it? I sure wouldn’t! And to me, that is exactly what cruelty, unfairness, and greed look like. It might seem positive — after all, the dictator is trying to “grow.” That is true but he’s rigged the game. Competition is no longer beautiful when the game is rigged. Competition is no longer beautiful when your tennis opponent slices off your leg before the match starts or pays off the chair umpire to call everything you hit out.

I don’t think there’s anything particularly special about cucumbers or cherries or corn. I just happened to have been washing vegetables before writing this. These radishes also exhibit positive space. And, although their shape is not the same as a cherry or a cucumber, the radishes also enhance the space around them. And, so does the avocado. An avocado that is just past ideal ripeness begins to flatten irregularly and the “pebbles” of the skin also flatten making a less positive space. The pebbles of a perfectly ripe avocado are themselves tiny positive spaces that add to the overall impression of vigor.

Flowers provide numerous examples of positive space. And, so far as I can tell, the positive space of flowers invariably also enhances the positivity of the space around them.

Animals also generally exhibit positive space. Their shapes, after all, come about through a struggle among different tradeoffs that have been “learned” by each species over four and a half billion years. But whether you look at the leg of a turtle, the leg of a turkey, or the leg of a polar bear, you will see positive space. The shapes are quite different because their histories are quite different. But in every case, the shape is determined by the history and each of those histories is the same length — 4.5 billion years. The fact that each of these shapes comes about through the dance of trying to survive and thrive in all their various habitats makes every one of them beautiful in its own right — even those whom most of us don’t particularly like to interact with such as rattlesnakes or lions. Even if we don’t wish to come face to face with a lion or grizzly bear, we do recognize their beauty. And, I would claim that as those animals walk through any landscape, they will not only exhibit their own positive shape; they will also enhance the positivity of the shape around where they are walking. Think how many times photographers and painters have put an animal in the foreground of a landscape. Of course, doing so makes the scene immediately more living, more interesting, and more beautiful.

Photo by Anastasia Shuraeva on Pexels.com

What does this have to do with the user’s experience on a computing device? I would have to say that most interfaces on most devices do not do much to bring the interface “alive” including having positive space. The tool bar icons on this version of my Mac are very slightly “bulging” like a living cell (or kernel of corn). Even more subtly, the windows have slightly rounded corners.

It’s an entirely different story with many games though. It seems to me that some of the game artists are among the best artists in the world. They have created many very beautiful games. Could they be more beautiful still if game designers consciously thought about using Christopher Alexander’s “Properties” in general, and “Positive Space” in particular? I think so, but for many games, such as Horizon Zero Dawn, many of the elements are copied so closely from nature that aspects such as “Positive Space” are mostly already taken care of by evolutionary bias toward the beautiful. (Yes, I do think there is such a bias, but it will have to be the subject of a different post.)

What about other applications and systems? Do you think you’ve seen good examples of “Positive Space” in such systems? How could you see incorporating “Positive Space” in UX?

At a more societal level, it seems to me that freedom is closely related to “positive space.” Each individual should be free to expand, grow, experiment, so long as it doesn’t impinge much on those around them. Imposing overly strict boundaries makes life less interesting and less lively. Growth without any sense of balance or notion of how a particular piece of life relates to the whole is called cancer. A society which allows or even encourages theft, rape, fraud and other felonies under the banner of “freedom” is doomed to ultimate failure with lots of pain along the way.

————————————

Winning by Cheating is Losing

Life Will Find a Way

Math Class: Who are you?

Life is a dance

Myths of the Veritas: The Forgotten Field

Cancer Always Loses in the End

When GREED is the only creed

The After Times

After All

Somewhere a Bird Cries

The Dance of Billions

Some recommended books —

The Winning Weekend Warrior focuses on the mental game for all sports using examples from tennis, golf, baseball, and other sports. It covers self-talk, imagery, mental practice, strategy, tactics, & sportsmanship. http://tinyurl.com/ng2heq3

Turing’s Nightmares explores the implications and ethics of Artificial Intelligence through fictional short stories. http://tinyurl.com/hz6dg2d

Fit in Bits shows many ways to put more fun, variety, & exercise into daily chores and habits to help with strength, flexibility, fitness, and balance. http://tinyurl.com/h6c7fce

Tales from an American Childhood recounts early experiences mainly in the American Midwest in the 1950’s and relates them to contemporary issues and events. https://tinyurl.com/y9ajvz9j

Dream Planet. Where do you run when the whole world is crumbling under the weight of human folly? When the lethal Conformers invade 22nd century Pittsburgh, escape becomes the top priority for lovebird scavengers Alex and Eva.

https://www.barnesandnoble.com/w/dream-planet-david-thomas/1148566558

4. Alternating Repetition

14 Monday Sep 2026

Posted by petersironwood in creativity, design rationale, HCI, leadership, management, nature, psychology, Uncategorized, user experience

≈ Leave a comment

Tags

aesthetics, architecture, art, beauty, Design, diversity, HCI, human factors, leadership, order, repetition, UX, writing

(This is the fourth post in a series of 15 which aim to examine the fifteen properties of natural order postulated by Christopher Alexander. I wonder whether the property of “Alternating Repetition” could be more frequently incorporated into User Experience and what the pros and cons might be).

4. Alternating Repetition

In nature, whether we look at clouds, waves, mountain ranges, forests, plants, the leaves of plants, or almost any animal, we see alternating repetition. Such natural repetition is almost never a precise and complete replication. Just as every reproductive act of life introduces an element of recombination as well as the possibility of mutation, so too the repetitions we see in life are not mathematical. We indeed see patterns repeated in a line or in a circle, but the instances in living things show variation. Similarly, human artifacts made with the hands; e.g., weaving or poetry or rock walls or tennis strokes show repetition but with slight and subtle variations.

If you look at modern industrial society, you see many examples of exact repetition. It’s true that if you looked at 10,000 examples of the same brand and model pen, or notebook, or scissors, or streak knives under a microscope, you could likely find small differences. To the naked eye, however, they would appear identical. Seeing 10,000 pebbles, leaves, or waves you would always see slight to moderate differences. To me, it makes a difference in terms of beauty. Handmade items and human actions naturally show more variation than things produced by machines.

The various “elements” of a User Interface generally have the feel of something made by machine. The size of all the application icons on the tool bar, for instance, are the same. They are all almost the same exact shape and size. On my tool bar the icons for Finder, Launchpad, Mail, Safari, Chrome, FaceTime, Messenger, Maps, Photos, Contacts, Calendar, Reminders, Notes, System Preferences, Keynote, Pages, Preview, and News are the same. However, the Kindle icon is slightly larger and more square. The Zoom icon is very slightly rounder. [NOTE: This is no longer true in 2026]. The icon for Facebook is still circular, however. In other words, there is some slight variation, but mainly the icons are the same in outline, but different inside. But the set of icons on the tool bar has no sense of “harmony” whatsoever–at least, not to me.

Note that the tool bar is both abnormally homogeneous in terms of positioning and size but completely disconnected in terms of the images which differ in a random disharmony seldom exhibited in nature.

Instead, each icon seems to scream out its individuality without regard to its neighbors. (Which reminds me of things like not masking, getting vaccinations, or telling the truth, for instance, because you don’t feel like it so who cares what the consequences to others are). Anyway, the layout of the toolbar, to me, it’s reminiscent of driving down the highway and seeing a sequence of billboards, each advertising some random product or service in no particular order. Often, each billboard is the same size but they are independent of each other. The one exception I can think of were the “Burma Shave” signs along the highway. Each sign was a small rectangle with several words on it. About a quarter mile down the road, another sign would appear. They were meant to be seen in a specific order and together, they made a kind of “story” which usually rhymed. Typically, the signs touted the joys of the product — “Burma Shave” — or, provided public service announcements about safe driving.

In the early days of computing, putting in “variation” might have been insanely wasteful of space and processing time. This is no longer true. Yet, the “look and feel” of User Interfaces remains, for the most part, quite “mechanical” or “mechanistic” rather than “natural.” Sometimes modern computer games include naturalistic looking variations in how repeated plants, rocks, clouds, etc. are represented. Look at the palm trees and you will see variations among the trees that are reminiscent of the real palm trees I see every day in the San Diego area. In addition, each tree contains a number of fronds that repeat a generic theme; yet, each front is somewhat different. The fronds themselves each contain alternating repetition, just as do real palm tree fronds.

We might consider whether it would make sense to put more natural looking alternating repetition into the more utilitarian aspects of user experience. For example, could it be both more beautiful and more useful to allow more variation in the way files are represented visually? Will Hill, James Hollan, Dave Wrobleski, & Tim McCandless suggested (in a CHI ’92 paper) that physical documents such as manuals naturally show wear in places where they are most used. They suggested that the visual representation of computer documents might be altered slightly to show which documents have been used or edited more and also that such cues within a document might also be useful.

Hill, William; Hollan, James; Wrobleski, Dave; McCandless, Tim; “Edit Wear and Read Wear,” Human factors in computing systems: Striking a balance. Proceedings of the 9th annual conference. SIGCHI ’92 Proceedings (Monterey, CA), Addison-Wesley, 1992, pp. 3-9.

One of the few cookbooks I use with some regularity is entitled, Fat Free and Flavor Full. The recipe I’ve used many times is the black bean salad. If I open the physical book, it naturally falls open to that particular recipe. “Open Recent” I find a very useful features of the Pages application, but I don’t see a way to look at files based on overall frequency of use. It could be the case that there are some applications for which you would want specific files to be easily found depending on the season or the date. The authors of “Edit Wear and Read Wear” were mainly talking about the utility of encoding information about a file into its visual representation. There might well be aesthetic reasons to do so as well.

The wooden blinds shown below exhibit alternating repetition in several ways. First, there is the matter of perspective. Some variation almost always presents itself simply by virtue of the fact that I typically view the blinds at an angle and some are closer to me than others. This means that the size, and the retinal shape are slightly different. Second, there is variation caused by slight changes in the angle of the slats relative to vertical. Third, each slat is made of wood. The wood itself shows rings (or more commonly a planar projection of the concentric cylinders.

The wooden blinds, because they are illuminated from the outside by tree-filtered sunlight also show further variation; however I don’t think that is typically “alternating repetition.” Perhaps not coincidentally, although I find it a little interesting, I can’t say I find that source of variation to be beautiful to me. The other three all add to the aesthetics, at least to me.

Is it feasible to introduce alternating repetition with slight variation into User Interfaces? Would it be desirable? What negative side-effects might arise? Do you even agree with Christopher Alexander that Alternating Repetition is an aspect of natural beauty and beautiful design? One thing that occurs to me is that if some element of the UI is more variable in outline etc., it may mean that the actions upon that object must deal with that variability. If designed greenfield, that might not be too difficult. But if, for example, the code for dragging and dropping was written under a presumption of zero variability, that might be problematic. What do you think?

——————-

Discussion of Alternating Repetition with additional visual examples can be found here:

The Fifteen Fundamental Properties of Living Structure. 4. Alternating Repetition

Because Christopher Alexander wrote a book, about the 15 properties, his examples are mainly visual. But alternating repetition as an element of beauty is also clearly present in music and in dance. There is a little of it, it seems to me, in culinary arts as well. I am also reminded of the smelling actions of my dog, Sadie. As she watches an animal without charging it, she waves her nose back and forth quite deliberately in a kind of “sampling” of the surrounding air. A bear will sometimes move sideways with alternating repetition to provide better depth perception of a far away target (like me!). But that’s a story for another time.

Use Diversity as a Resource

The Tree of Life

Life is a Dance

Take a Glance; Join the Dance

Piano

Turing’s Nightmares explores the implications and ethics of Artificial Intelligence through fictional short stories. http://tinyurl.com/hz6dg2d

Fit in Bits shows many ways to put more fun, variety, & exercise into daily chores and habits to help with strength, flexibility, fitness, and balance. http://tinyurl.com/h6c7fce

Tales from an American Childhood recounts early experiences mainly in the American Midwest in the 1950’s and relates them to contemporary issues and events. https://tinyurl.com/y9ajvz9j

https://www.barnesandnoble.com/w/dream-planet-david-thomas/1148566558

3. Boundaries

13 Sunday Sep 2026

Posted by petersironwood in Uncategorized

≈ Leave a comment

Tags

beauty, boundary, Design, ethics, greed, HCI, life, limit, nature, privacy, truth, usability, user_experience, UX, writing

3. Boundaries

Here are a few thoughts about “Boundaries” and how they apply in User Experience.

I decided to gift a copy of of Volume One on The Nature of Order to my daughter earlier today. I logged on to Amazon and looked at my address book. I am aware that she moved fairly recently. So, I was scrolling through my earlier text conversations with her to see whether she had told me of her new address. I couldn’t find a text about her new address so I texted her to get the new address.

Suddenly, a popup window appeared from SIRI. It had her new address. I hadn’t said anything aloud. I thought of SIRI as a voice-activated service on my iPhone. It was disconcerting to have it “notice” my text message and then suggest an answer (which turned out to be correct).

Last week, after physical therapy, my therapist & I began to discuss the time for my next appointment. I pulled up the calendar application on my iPhone and went to a particular day and began to type in her name. After the first two characters were typed in, the “type-ahead” function suggested three possible “completions” the first of which was the time we had been orally discussing (which was not a common time nor the time of any of my recent appointments with her). It also filled in her complete name and the purpose of the appointment, but that was more understandable.

One sense of “Boundaries” in User Experience connects with a notion of “boundaries” that is much discussed in contemporary mental health. We are advised to “establish boundaries” with co-workers, family, friends, and strangers. We don’t necessarily want to share personal information with everyone or let everyone touch us in any way they choose to. If intimate details are shared in a recovery group or group therapy, it is generally agreed that such details will not be shared with others.

We sometimes extend the idea of informational boundaries to written materials as well. If, for instance, we keep a personal diary, we do not expect other people to “search for it” or to read it. In the short story, “Jennifer’s Invitation,” (link below) about my shy attempt as a third-grader to invite my girlfriend to my birthday party, I relied on my expectation that she would read a paper I “accidentally” dropped on the sidewalk. But she was so protective of my privacy that she wouldn’t even glance at my paper. I lost track of Jennifer, but I’m pretty sure she never became CEO of an IT company.

On the other hand, if we write and publish an autobiography, then we can expect that other people will feel justified in discussing the contents. To me, it would seem odd for an author to feel “violated” if people start talking about the contents of their autobiography (or their blog).

When it comes to modern interactions with computer software however, the boundaries are invisible — and sometimes non-existent. It can feel as though I write a private diary on paper; lock it up in a safe immediately; and then — without any sign that the safe has been broken into, I suddenly find details of my personal life revealed!

There appear to be boundaries between applications, and certainly between devices but these boundaries may be illusory. I find that troubling and confusing. I think the first application of “Boundaries” as a property of UX is that apparent boundaries should be real. There may be exceptions for exceptional circumstances; e.g., the police may get a search warrant to search your house if there is reasonable suspicion that you have committed a crime.

When a social media site analyzes your reactions, relationships, and word usage to determine what to try to sell you and what type of approach is most likely to succeed, that does not strike me as a reasonable response to an “emergency.” As most readers know by now, such information is not only used to try to sell you more stuff; it was also used to manipulate public opinion; for example, to convince some US voters to stay away from the polls on election day in 2016; to convince voters in the UK to vote for Brexit; to convince people not to get vaccinated.

Living things do have boundaries. Breaching those boundaries is typically something to be avoided. We call such breaches by names like “bites”, “wounds”, “diseases”, “gunshots”, “parasites.” Living cells typically have a cell wall. Within the cell are tinier organelles such as the mitochondria. The mitochondria have boundaries. The nucleus of a cell has a boundary. Within the nucleus, the nucleolus has a boundary. Larger structures often have boundaries. Motor neurons have a myelin sheath which allows neural impulses to travel faster. Almost our entire body is covered in layers of skin which serve for us a boundary.

The formation of boundaries does not stop with our physical body. Organizations of humans — nuclear families, clans, nation-states, counties, cities, townships, teams, corporations — they have boundaries. A bank, for instance, might have a safe for the money, but the building itself also functions as a boundary — not an impermeable boundary — customers are allowed to come in during banking hours. There are also legal boundaries. If you have “an account” at a bank, you will be allowed to do things that non-customers cannot. Similarly, if you are an employee of a company or a member of a sports team, you will be allowed to do things and go places that you couldn’t if you were outside that boundary.

All boundaries are semi-permeable. Boundaries change over time. A thorn tears your skin. Your boundary is broken. If you’re not careful, bacteria can get in and cause an infection. Your white blood cells destroy the invading bacteria. Your body heals. If the cut was bad enough, you may get a scar and the scar is now part of your “boundary.” It isn’t only at the level of the body that changes occur. Your social boundaries change too.

You get married. You get divorced. You are born. You join a team. You quit the team. You sell your house and other people buy it. Now, you are no longer allowed to come into the house without an invitation. Meanwhile, you buy another house. You have acquired new boundaries. Or, perhaps, you have no home. You are homeless and your boundaries are not so secure.

Most of our possessions have clearly defined boundaries. Your hammer is separate from your saw which is separate from your drill. They come from an earlier time and the “boundary” of such objects are determined by their shape. More recently, such tools (and nearly everything else!) comes packaged in bubble wrap which forms an additional boundary. This makes it harder for people to hide one under their clothes and walk out without paying. Such packaging has the added advantage that it will require time and energy on your part before you can actually start using the tool for its intended purpose. Not only that — such packaging helps pollute our world beyond the pollution required by “old style” tools.

Once you have separated your new tool purchase from its packaging, if you have any energy left, you can saw a board, or drill a hole, or hammer a nail. But you do not expect (not yet, at least), the saw to “communicate” behind the scenes with your drill. Or to communicate with you. You’d be surprised if it piped up and said, “Gee, Gene, you just sawed a board. Now, you have taken up the drill. Would you like suggestions on how to build a dog house?” (That’s what Clippy would do).

(Link to Wikipedia article on “Clippy” and how it was parodied). https://en.wikipedia.org/wiki/Office_Assistant

Clippy tried to be helpful. But it didn’t really have enough information about my tasks, goals, and context to actually be helpful. But today’s behind-the-scenes information sharing with dark forces is not trying to be helpful. It’s trying to get you to change your behavior for someone else’s benefit — and you don’t even know who those someones are.

Notice that if you buy a house (which typically comes with doors and keys), you can lock the house and the default is that it keeps everyone else out — except those you’ve given a key to or those who have rung your doorbell or otherwise asked for permission to come in. Typically, if a rare visitor comes to your house, you make arrangements for a time and a place. The piano tuner comes to tune your piano. You might let them use your bathroom or even offer them something to drink. But you don’t expect the piano tuner to redecorate your study or to spend the night uninvited.

That’s kind of what does happen in the electronic world though. In many cases, you cannot visit a website or use an application unless you give permission for the “guest” to rifle through the choices you make. Just to be clear, these “choices” are not only explicit choices; your “choices” can include how long you linger over a particular message or video clip. In many cases, you have not just given a key to a specific vendor, application, or website — in many cases, you have also given them rights, essentially, to make as many copies of your front door key as they care to make and hand them out to whomever they like.

These are missing boundaries, not so much in the user interface design, but in the socio-technical context in which we use our technology.

In the physical world in which we evolved, invasion of privacy typically involved symmetry. If I can see your eyes, you can see mine. Conversely, if I can’t see anyone, chances are that they can’t see me. Of course, this isn’t literally true. A tiger’s camouflaging stripes may mean that they can see the gazelles even though the gazelles cannot see them. The astounding eyesight of the eagle allows them to see a mouse on the ground and start their deadly dive before the mouse can see the eagle.

In the electronic world, it isn’t genetically coded asymmetries of information that allows other people to invade your boundaries — in many cases without your permission or even knowledge. It is an asymmetry that comes from money and time. You don’t have anything like the fortune that rich companies have. They can hire experts at subverting your boundaries. They can hire an entirely different set of experts to convince you that it’s all okay. They can afford to hire still other experts to defend themselves in a court of law should you seek redress for any particularly unethical behavior. They can afford to (and do) hire politicians as well in order to make laws to protect their unfettered access to your data. You typically cannot afford to hire politicians to protect your right to privacy.

You probably don’t have 10,000 to 100,000 people working for you. Companies not only have the money to spy on you. They also have to time to collect and analyze your behavior & make sense of it. You don’t. Perhaps, every once in a while, you take the time to wade through a “privacy policy.” In most cases, since experts were hired to make the text as incomprehensible as possible, you likely didn’t see much value in reading the document.

The Nature of Order is about aesthetics, not ethics. And, this post was meant to be about aesthetics, not ethics.

The poem by Keats, Ode on a Grecian Urn,

https://www.poetryfoundation.org/poems/44477/ode-on-a-grecian-urn

ends thusly:

“Beauty is truth, truth beauty,—that is all

Ye know on earth, and all ye need to know.”

Life includes differences in sensory capability. And life includes camouflage. Generally, however, when you get to the end a cliff and step off, you have a pretty good idea what’s going to happen. The boundary is visible to you, to a bison, to a mouse, to a lemming, to an eagle.

When we walk through the woods in northeastern USA where I lived for many years, we run the risk of being attacked by a deer tick. The dear tick makes a hole in you and starts sucking your blood (oh, while they’re at it, they may inject a large does of Lyme disease bacteria into your blood stream). You don’t notice it, because the deer tick is “kind enough” to administer a local anesthetic so you don’t feel any pain from this invasion of your person; this breaking of boundaries. It’s a one-sided breach. The deer tick is well aware of the invasion. It’s the whole point! But you do not perceive the breach. At least, I didn’t. Twice. Thankfully, I don’t seem to have any long-lasting effects though I have several friends who are still suffering from the effects.

A one-sided boundary breach, doesn’t seem “aesthetic” to me. Nor does it seem “truthful.” The little orange deer tick, is, in a very real sense, lying to me. It uses its narcotic to tell me, “No worries! There’s no wound here! There’s no deer tick sucking your blood. There’s no deer tick injecting a serious disease into your blood. No, no. All is well!” It seems the opposite of beauty and the opposite of truth.

I suppose if I had been born a deer tick, I might view things differently.

———————-

Myths of the Veritas: The Orange Man

Pattern Language for Collaboration and Teamwork

Jennifer’s Invitation

Your Cage is Unlocked

What Line?

Roar, Ocean, Roar!

Stoned Soup

How the Nightingale Learned to Sing

Some recommended books:

Turing’s Nightmares explores the implications and ethics of Artificial Intelligence through fictional short stories. http://tinyurl.com/hz6dg2d

Fit in Bits shows many ways to put more fun, variety, & exercise into daily chores and habits to help with strength, flexibility, fitness, and balance. http://tinyurl.com/h6c7fce

Tales from an American Childhood recounts early experiences mainly in the American Midwest in the 1950’s and relates them to contemporary issues and events. https://tinyurl.com/y9ajvz9j

https://www.barnesandnoble.com/w/dream-planet-david-thomas/1148566558

https://www.goodreads.com/en/book/show/222376640-enshittification

Strong Centers

12 Saturday Sep 2026

Posted by petersironwood in Uncategorized, psychology, creativity, nature, design rationale, user experience, HCI

≈ Leave a comment

Tags

aesthetics, architecture, art, beauty, Christopher Alexander., Design, HCI, human factors, usability, UX

This is the second posting in a series of fifteen which examine Christopher Alexander’s “Fifteen Properties” of natural beauty and suggests how these properties might apply to user experience design.

Photo by Dominika Greguu0161ovu00e1 on Pexels.com

2. “Strong centers” is probably one of the most overlooked properties of design in UX/HCI. Often, what exists for the user, from their perspective, is a “sprawl” of functions, tool bars, and icons with no obvious overall or subsidiary organization. A better design would allow the user to quickly find a “home base” from which, it would be obvious where to find subsidiary home bases. There is some sense in which hyperbolic trees, fisheye lenses, and home pages partly begin to address this issue.

Instead of “strong centers”, the impression I often get in looking at applications for word processing, organizing photos, searching, or dealing with settings is that the designers are given or generate a long list of functions to be supported. Which ones are related to which though? Which ones are central? In many cases, UX practitioners give users (or, more often, potential users), a set of cards with one function each and ask the users to sort these into piles. I am not against such studies, but they are unlikely to lead to a coherent design with a strong center. The users are not, in most cases, professional designers. In many cases, an application is supposed to support many different specific actions. For example, I use word processors to write essays, poems, and fiction. I also use a word processor to proofread something, to re-organize ideas, to “jot down” a bunch of ideas, or to write an outline. These are very different tasks, at least to me. If asked to sort cards, I would do it differently depending on which type of task and which type of material I’m thinking about.

As I type this, I glance at the “Pages” tool bar which includes: Pages, File, Edit, Insert, Format, Arrange, View, Share, Window, and Help. None of these seems like “home” to the task of writing an essay. I know from experience that if I want to write any kind of material, I must go to the “File” menu even though, as best I can recall, my initial impression of this label was that it would be something to do after I was “done” with the tasks of composing and proofreading. The toolbar gives no impression of their being any “center” at all, let alone a “strong center.”

In my native language (English), I read from top to bottom, left to right. In that sense, the Apple Icon is first and the “Pages” item is next and it is in bold print. That could be considered a subtle clue that it’s the “most important.” In a way, the items on the “Pages” menu are “meta-items.” In that sense, I suppose you could argue that they are “important” — though as a writer, none of the items seem that important. In fact, if we get right down to it, nothing in Pages really seems designed to support the actual writing process. And, I’m not trying to single out Pages because it’s the only one or the worst one. Lack of a “strong center” seems true of nearly all applications.

Different people use different processes for writing — and I myself use different processes for different types of writing, so perhaps trying to organize the features and functions so that there is a “strong center”reflective of the “strong center” of the task of writing is just not feasible. I am certainly not advocating for resurrecting “Clippy.”

Ideally, it should be possible for users to “know where the action is” upon entering an application or a web page.

In another interpretation, “strong centers” refers more to underlying architecture and points to the need for a core of functionality that transcends a specific release or even a specific application. A good underlying architecture will communicate this essential center (related to central purpose or style) to the user.

All too often, the processes involved in developing an application or system themselves have no “strong center.” If the development process is itself a hodgepodge political process of accommodating to a portfolio of features and functions that are advocated for by diverse and uncoordinated stakeholders, then, what one has are a long, unorganized list artificially shoved into menus and sub-menus and toolbars. It should not be surprising then, that the user finds it difficult to know where to begin when first encountering an application — even if the user knows exactly what they want to accomplish.

Compare and contrast most menu structures and user interfaces with the “strong centers” that are extremely common in life forms. Here are some examples of butterflies.

The central axis includes the head, the thorax and the abdomen. These are in a line in the strong center. Typically, they are colored differently from the wings. The bilateral symmetry of the wings as well as the overall shape reinforces the strong center. Wing patterns, and even the antennae and legs lead the eye back to the strong center.

Most people think of butterflies as beautiful — and I agree. When asked, however, most people will say they are “brightly colored.” Some are; some are not. But “bright colors” don’t necessarily give rise to beauty!

Strong Centers doesn’t just apply to butterflies. Look at most birds, fish, mammals, insects and you will see how the symmetries and smaller centers reflect and strengthen the major center. Indeed, Strong Centers are not limited to the animal kingdom. The trunk of a tree provides a strong center. Each branch is itself a center and the connection of the branches to the trunk reinforces the strength of the central trunk.

Even single cells often exhibit strong centers (and many of the other 15 properties, by the way).

It would love to be able to provide you with a process or checklist or formula so you could design user experiences with “strong centers.” I cannot really do that. Nor can anyone else. If you keep it in mind, even at the back of your mind, you may see opportunities to help make that happen with regard to whatever you’re working on. I’m curious to hear your thoughts about “Strong Centers.”

One technique that may be of some use was shared at a workshop by someone who worked at a car company. In the design of a specific car, the team decided the car would reflect “a professional soccer player out for a night on the town.” This is obviously not a “formula” or “checklist” but it offers a metaphor that designers of car interiors, exteriors, and the drive train could all relate to. A similar method is sometimes used in film — some specific person is responsible for the artistic integrity of the whole.

There is no one way to produce strong centers. Here are some examples from flowers.

———————

Here we see that each flower has a strong center and the central stem provides a strong center for the entire plant.

Some useful links to more information, discussion, and examples relevant to “strong centers” or to the fifteen properties.

Christopher Alexander – Fundamental Property 2: Strong Centers

https://www.archdaily.com/626429/unified-architectural-theory-chapter-11

Roar, Ocean, Roar!

Imagine All the People

The Dance of Billions

Somewhere a Bird Cries

How the Nightingale Learned to Sing

Piano!

Unite!

Fifteen Properties of Natural Beauty & UX/HCI

09 Wednesday Sep 2026

Posted by petersironwood in Uncategorized, psychology, creativity, nature, design rationale, user experience, HCI

≈ 1 Comment

Tags

architecture, art, books, Design, gratitude, HCI, human factors, mindfulness, photography, Travel, UX

This is an introduction to a series of blog posts on the “Nature of Beauty.”

Christopher Alexander was an architect and city planner. In his MIT dissertation, Alexander took a very mathematical approach to design. In our studies at IBM Research on the “Psychology of Design” I first ran across that work (Notes on the Synthesis of Form). Later in his career, however, he took a quite different approach to design. With an international team, he visited many different parts of the world to see what “worked” in terms of architecture and city planning. The results were documented in the form of a “Pattern Language.” In this sense, a “Pattern” is the named solution to a recurring problem. A “Pattern Language” is a connected lattice of Patterns that together, “cover” a field.

Others (including me) have emulated his approach for other fields such as pedagogy, organizational change, object-oriented programming, software development processes, and human-computer interaction. A few years ago, I suggested such Patterns for collaboration and teamwork. Here’s a link to the introduction of that effort. Here’s a link to the index of those Patterns.

Still later in life, Christopher Alexander embarked on a project called The Nature of Order. This work is documented in a series of four books. In the first book, he proposes fifteen properties of good form in nature — and in beautiful artifacts. Explication and example will be needed to appreciate what these properties mean. In this post, I list the fifteen and will attempt to explain the first one with respect to UX and Human Computer Interaction.

First, you might be wondering what relevance these fifteen properties of nature might have to interface design. After all, can’t the designer just test out their ideas empirically until a UX design is shown to be usable, learnable, and perhaps enjoyable as well? Well, sure. Ideally, every possibility could be explored and tested empirically.

But how many possibilities are there? Without any guiding principles, there are not only more possibilities than can be tested by you. There are more possibilities than there are atoms in the universe. Imagine a very simple interface on a small mobile device. Let’s say there are only ten screens in your whole application. The iPhone 12, for instance, has nearly 3 million pixels. 24-bit color allows over 16 million colors per pixel. If you literally tested out every possible arrangement, this would mean 16 million to the 3 millionth power for each of the ten screens!! The number of atoms in the universe is estimated to be between 10**78 and 10**82. Obviously, this is far less than 16,000,000**3,000,000 !!

Of course, I’m not suggesting that anyone would attempt a pixel by pixel test of an interface, but the general point remains: you need some way to limit testing to reasonable alternatives. The notion of using these fifteen properties is not that they dictate a particular design nor that you don’t need to do any empirical testing. Rather, the fifteen properties could be used to help guide design. The properties could be thought of as reducing the search space.

Here are the fifteen properties:

Levels of Scale
Strong Centers
Boundaries
Alternating Repetition
Positive Space
Good Shape
Local Symmetries
Deep Interlock and Ambiguity
Contrast
Gradients
Roughness
Echoes
The Void
Simplicity and Inner Calm
Not-separateness

Perhaps the names themselves might resonate with your own sense of aesthetics for design and composition, but let’s review them one by one.

The first is “Levels of Scale.”

When it comes to natural beauty, a few moments reflection may provide you with many examples. Christopher Alexander claims this property is also present in traditional art and architecture across many cultures. As you see something such as, e.g., the Taj Mahal or the Parthenon in the distance, you see a beautiful shape. As you approach it, you will see more and more levels of scale. By contrast, many modern buildings are largely featureless between the overall shape and the texture of the building material.

If your design has multiple levels of scale, it will be easier for your user to orient themselves; to know “where they are” in the application and therefore easier to take appropriate action. Not only are you making their “task” more doable, you are providing a kind of entertainment. If it works well, they will be thinking of the building and perhaps its significance the entire time they approach the building. By contrast, if I approach a modern no-scales building, I bore quickly and, like most people, there are a whole host of things waiting to be thought about. So, I’ll mainly be thinking of one or my problems and largely ignoring your building and what it stands for. Reflect on your own experiences and see whether you agree. Lincoln Memorial, Winchester Cathedral, Temple in Kyoto: they are completely different from each other and yet in this way, they are all the same: they keep your attention focused on the moment. In other words, they help you be fully alive and awake. In the best circumstance, they also elicit some awe and gratitude not only for the geniuses who designed but also for the many laborers who found and mined the materials, constructed something from it, and even those whose taxes paid those workers.

Levels of Scale is something to keep in mind with respect to your design — whether hardware, software, documentation, story, or a building.

How could you use or see “Levels of Scale” as a desirable property of what you are doing right now?

———————————-

Some references to Pattern Languages in HCI.

Pan, Y., Roedl, D., Blevis, E. and Thomas, J. (2012), Re-conceptualizing Fashion in Sustainable HCI. Designing Interactive Systems conference. New Castle, UK, June 2012.

Thomas, J. C. (2012). Patterns for emergent global intelligence. In Creativity and Rationale: Enhancing Human Experience By Design J. Carroll (Ed.), New York: Springer.

Thomas, J. (2012). Edging Toward Sustainability. CHI Workshop Position Paper for Simple Sustainable Living. CHI 2012, Austin, Texas.

Thomas, J. (2012), Enhancing Collective Intelligence by Enhancing Social Roles and Diversity. CSCW Workshop Position Paper for Collective Intelligence and Community Discourse and Action. CSCW 2012, Bellvue, WA.

Thomas, J. (2011), Toward a pattern language for socializing technology for seniors. Workshop position paper accepted for CSCW 2011 workshop: Socializing technology among seniors in China, Hangzhou, China, March 19-23.

Thomas, J. (2011). Toward a Socio-Technical Pattern Language for Social Systems in China and the World. Workshop position paper accepted for CSCW 2011 workshop: Designing social and collaborative systems for China. Hangzhou, China, March 19-23.

Thomas, J. (2011). Toward a Socio-Technical Pattern Language for Social Media and International Development. Workshop position paper accepted for CSCW 2011 workshop: Social media for development, Hangzhou, China, March 19-23.

Bonanni, L., Busse, D. Thomas, J., Bevis, E., Turpeinen, M. & Jardin, N. (2011). Visible, actionalble, sustainable: Sustainable interactin design in professional domains. Workshop accepted for CHI 2011. Vancouver, B.C., May 7-12.

Thomas, J. (2011). Focus on Ego as Universe and Everyday Sustainability. Workshop position paper accepted for CHI 2011 workshop: Everyday practice and sustainable HCI: Understanding and learning from cultures of (un)sustainability. Vancouver, B.C., May 7-12.

https://www.researchgate.net/publication/2242380_A_Pattern_Approach_to_Interaction_Design

Click to access dearden-patterns-hci09.pdf

https://www.mit.edu/~jtidwell/common_ground.html

Thomas, J. C. (2018), Building common ground in a wildly webbed world: a pattern language approach. Journal of Information, Communication and Ethics in Society, 16 (3), 338-350.

——————————-

Some recommended books:

The Winning Weekend Warrior focuses on the mental game for all sports using examples from tennis, golf, baseball, and other sports. It covers self-talk, imagery, mental practice, strategy, tactics, & sportsmanship. http://tinyurl.com/ng2heq3

Turing’s Nightmares explores the implications and ethics of Artificial Intelligence through fictional short stories. http://tinyurl.com/hz6dg2d

Fit in Bits shows many ways to put more fun, variety, & exercise into daily chores and habits to help with strength, flexibility, fitness, and balance. http://tinyurl.com/h6c7fce

Tales from an American Childhood recounts early experiences mainly in the American Midwest in the 1950’s and relates them to contemporary issues and events. https://tinyurl.com/y9ajvz9j

https://www.barnesandnoble.com/w/dream-planet-david-thomas/1148566558

The Walkabout Diaries are photo-essays inspired by walks in nearby neighborhoods, gardens, and parks.

The Walkabout Diaries

Query By Example

08 Tuesday Sep 2026

Posted by petersironwood in AI, design rationale, HCI, leadership, management, psychology, science, Uncategorized, user experience

≈ Leave a comment

Tags

AI, Artificial Intelligence, expertise, HCI, human factors, IBM, leadership, QBE, research, technology, usability, UX, writing

This is part of a series on experiences in my career in Human Computer Interaction and some lessons learned.

I joined IBM Research on the winter solstice of 1973. I had earned a Ph.D. in Experimental Psychology from the University of Michigan and for the previous few years, I had managed a research project at Harvard Medical School on the “Psychology of Aging.” At the time, I was married and had three small children. I mention this because I was funded by so-called “soft money” which basically meant that my salary depended on a research grant. I helped write a renewal of the grant but the decision was “deferred”; that is, it was neither funded nor unfunded. Then, it was deferred again. This meant that if the grant were not funded, I would only have a few weeks to find a new job. That seemed far too short so I began to look other places for a job.

Lessons Learned: #1 If you want continuity of personnel in your laboratory, make sure you have overlapping and multiple grants or other sources of income.

In this case, the grant actually was ultimately approved, but by that time, I had already agreed to join IBM Research. That turned out to be fine, by the way. It was a wonderful place to work.

One of the reasons that I got the job at IBM was that I already knew something about computers. I had taken several computer science courses in grad school along with the needed psych courses. More importantly, our “Psychology of Aging” study was run by a PDP-8 and I had programmed the computer to run our suite of experiments and to do data analyses on the results. I had taken a week-long course at DEC in Maynard, Massachusetts on the assembly language, another week-long course on the machine language, and another week-long course actually tracing the circuitry with a probe and oscilloscope. I felt I “understood” the PDP-8 at a fairly deep level.

At IBM, I did not have that familiar machine. Instead, I was connected to a mainframe via a dumb terminal. The first day at IBM, I got my userid and tried to log on to APL (A programming language I had not used before). I tried following the manual but I could not seem to get logged on. After hours of trying, I finally gave up and went down to the computer room and found someone willing to help. I showed him the logon instructions I was trying to follow and he immediately said, “Oh, yeah, that doesn’t work any more. We changed that months ago. Here’s how you need to do it now.” The manual I had may have looked new, but it was out of date.

Lessons Learned: #2 Manuals can be wrong. These days, most are online. But they can still be wrong.

Lessons Learned: #3 Someone who knows how to do something can save you hours with a few minutes of their time.

Of course, it’s more respectful, efficient, and a better learning experience if you can figure it out on your own. But sometimes you can’t. My stumbling block was not due to an error in logic, or a lack of in-depth knowledge. It was simply that the computer center administrators had changed something arbitrary so that the documentation I was given about how to log on for the first time was no longer accurate.

In order to teach myself APL, I wrote a very small program to “predict” how long I was going to live “based on” some behaviors that I was interested in controlling. My main goal was to learn APL. My secondary goal was to motivate myself, for instance, to exercise more, lose weight, and not drink too much alcohol. I had no intention or pretensions of making this prediction “accurate.” If I had been doing a consulting gig for an insurance company setting life insurance rates, for example, I would have given far more attention to see precisely what the real data were and incorporated many more variables into the regression model.

Here’s a link,

https://www.death-clock.org

by the way, to a more accurate model than the one I used, but it’s still simple to use. Note that my goal was to motivate myself and so I intentionally exaggerated the impact of those behaviors I was trying to change. I had programmed it. I knew how “bogus” the calculation was — nonetheless — here’s the interesting thing though:

Lessons Learned #4: Even an over-simple model that the user knows is over-simple can still motivate change.

At last we come to the actual project I worked on — the usability and learnability of Query By Example. One of my colleagues, Moshe Zloof, invented the language for relational data bases. He had designed the language but not yet implemented it. I did not immediately test the design; first, I sought to understand it. In seeking to understand it in depth, prior to testing it, the two of us had some sense-making discussions. Moshe improved the design; in particular, our discussions uncovered some ambiguities and inconsistencies that were not at all obvious when he simply gave talks about the design. This brings me to the next lesson learned which has proven true in nearly every study of early stage designs that I’ve been involved with over the course of six decades.

Lessons Learned #5: Don’t just accept a surface description of something; understand it as deeply as you can before designing a study.

In this particular case, it was possible for me to understand it in some depth. Relational data bases and second order logic are things I was capable of understanding. If it had been an interface to running a nuclear reactor or using the artificial heart that Moshe had designed earlier in his career, that would have been a much more difficult task for me.

I wanted to understand, not just the “logic” of Query By Example, but also possible contexts of use. For instance, my manager & I visited Burlington, Vermont to talk with IBMer’s who actually used query languages to understand what was happening in chip production lines. At one point, a particular production line that had been producing nearly 100% perfect chips starting having a much higher error rate. Using their query facility, they were quickly able to diagnose the cause of the change which was a supplier of one of the raw materials using a different source. In turn, this meant a slightly different profile of trace impurities in the substrate. Of course, this is only one example, but to me, understanding something in depth means not only understanding its internal logic but also understanding real users, their real tasks, and their context of use.

Photo by Chokniti Khongchum on Pexels.com

I won’t go into all the details of the pencil & paper study or the results. High School students and then college students were taught the basics of the language and then given a simple relational data base and a set of questions stated in English which they had to translate into Query By Example. Briefly, the bottom line was that Query By Example was easy to learn and easy to use. However, there were still questions that people had difficulty with. In analyzing the data and doing some further experiments, the difficulties that people tended to have, stemmed not so much from Query By Example per se, but from what I much later came to call “labelism” — that is, confusing a label with the thing that label refers to.

Here’s a simple example of the type of confusion we saw. In Query By Example (and other query languages) there is usually an OR operator and an AND operator. (These operators can be important for doing advanced queries with search engines as well). If you are interested in getting a list of pets you might adopt and you’re willing to adopt dogs or cats, you might ask for “cat OR dog.” If you only want long-haired cats, you might ask for “cat” AND “long hair.”

English, however, can be tricky.

If you and I (as opposed to you and a query language) are having a conversation, you might say, “I hear there are many pets that need to be adopted.”

I say, “Yes, there are all kinds of pets. There are snakes, dogs, turtles, rabbits, cats…”

You say, “Let me stop you right there. I’m only interested in adopting cats and dogs. Those are the only animals I’d want to adopt.”

See what you said there? You exact words included: “…cats and dog.” If you put “Cats AND dogs” into a query against the data base of available pets, however, you will get the null set (that is, nothing) back. There are no animals who are both cats and dogs! (Though my part Main Coon cats, Luna and Charles Wallace, can play fetch like dogs).

When people were presented with an English statement that included the English word “and” — regardless of the actual syntax and context, some of them had difficulty using the OR operator. If instead, the query in English had set up like this: “Oh, I don’t want reptiles. I’d be happy with adopting a cat or a dog, however” then, they’d have no problem translating it into the OR operator in the query language.

Lessons Learned: #6 Sometimes the difficulty people have in using a product, a service, or a prototype is not due to the interface details but with the structure of the task, their background, and their training.

By analogy, you will not allow me to beat Carlos Alcaraz or Jannik Sinner at tennis by giving me a better tennis racquet! (Although if you gave one of them a toothpick for a tennis racquet, I might have a shot).

That sounds obvious and even absurd, but I promise you, some companies get so greedy that they want you to design a system that allows people who do not understand the task and have minimal background and training to nonetheless be able to perform that task. And, to be fair, it isn’t just the companies who are greedy. They are steered into thinking that they can get away with this absurdity because some outsourcing companies (and more recently, AI companies) tell them they can do it.

One example you may have encountered is having “help desk” personnel who have no understanding of a product go through a script to help you “solve your problem.” Sometimes, it works. But many times it doesn’t. When it does not work, you might not be able to “fix” the system by making the interface to the scripts easier to use for the help desk folks. The problem is much deeper (in some cases). Yes, a really bad interface can make it difficult even for a really knowledgeable and capable person to do the job. But often, even a really great interface cannot always substitute for actual expertise.

——————————————————-

Essays on America: Labelism

“The Psychology of Design”

22 Wednesday Jul 2026

Posted by petersironwood in creativity, design rationale, HCI, management, politics, psychology, science, Uncategorized, user experience

≈ Leave a comment

Tags

AI, creativity, Design, education, HCI, human factors, IBM, leadership, research, technology, UX

“The Psychology of Design”

I worked at IBM, all told, about 28 years. During that time, management put increasing pressure on us to make our work “relevant” to the business. In fact, the pressure was always there, even from the beginning. Over the years, however, we were “encouraged” to shorten evermore the time gap between doing the research and having the results of that research impact the bottom line. This was not an IBM-only phenomenon.

I was a researcher, not a politician, but it seemed to me that at the same time researchers in industrial labs were put under pressure to produce results that could be seen in terms of share price (and therefore payouts to executives in terms of stock options), academia was also experiencing more and more pressure to publish more studies more quickly — and to make sure “intellectual property” was protected to make sure the university could monetize your work. This was about the same time that, at least in America, increasing productivity and the wealth that sprung from that increased productivity stopped being shared between the workers and the owners.

In the late 1970’s, the “Behavioral Sciences” group at IBM Research began to study the “psychology of design.” For the first few months, this was an extremely pleasurable & productive group, due mainly to my colleagues. Over the next few blogs, I’ll focus on some specific techniques and methods that you may find useful in your own work.

In this short recounting though, I want to focus instead on some broader issues relevant to “technology transfer”, “leadership” and “management.” Even if you are or aspire to be an expert in UX or HCI or design, I assure you that these broader issues will impact you, your work and your career. I wouldn’t suggest becoming obsessed with them, but being aware of their potential impact could help you in your own work and career.

It is telling that, almost invariably, whenever I told someone inside IBM (or, for that matter, outside IBM) that I was studying the “psychology of design,” people responded by asking, “the design of what?” So, I would explain that we were interested in the generic processes of design and how to improve them. I would explain that we were interested in understanding, predicting, and controlling these processes to enable them to be more effective. I would explain that we could apply these findings to any kind of design: software design, hardware design, organizational design, and (see last post about IBM) communication design. I would explain that design was a quintessentially human activity. I would also explain that design was an incredibly leveraged activity to improve.

Looking back on it, I still think all these things are true. I also see that I missed the “signal” people were giving me that, while I thought of design as something that could be studied as a process, that most people did not think of it that way. To them, it was never the “psychology of design,” but only the design of something.

Don’t get me wrong. I agree that somewhat different skills are involved in designing a great advertising campaign, a great building, and a great application. I agree that different communities of practice treat various common issues differently. I still think it’s worth studying commonalities across domains. For one thing, we may find an excellent way of generating ideas, say, that the advertising community of practice uses that neither architects nor applications developers had ever tried. Or, vice versa.

My own academic background was in “Experimental Psychology.” We were forever doing experiments that we believed were about psychological processes that were thought to be invariant regardless of the domain. It was an axiom of our whole enterprise that studying memory for any one thing also shed light on how we remember every other thing. Similar studies looked at decision making or problem solving or multi-tasking. We came to understand that there were some interesting exceptions to being able to separate content from process. For instance, it is much easier to multi-task a spatial task and a verbal task than it is to multi-task two independent spatial tasks or two independent verbal tasks.

In our Behavioral Sciences lab, we used a spectrum of techniques to study “design” ranging from laboratory studies of toy problems, to observing people doing real-world design problems while thinking aloud. After about 3-4 months of very productive work, we were told that we had to make our work relevant to software development. That one domain should be the focus of our work. We were told that this command came from higher-ups in IBM. That might have been true, or perhaps partly true.

It might also be relevant that someone in our management chain might have been the recipient of a grant from ONR which was specifically focused on software development. So far as I can tell, nothing had been done on that grant. So, our past, present, and future work could have been co-opted to be “results” done under the auspices of the ONR grant.

In any case, regardless of the “reasons,” the group began to focus specifically on software design. In one study, we used IBM software experts as subjects. Each person was given information that was geared toward a specific transformation that occurred in software development. One person was presented with the description of a “situation” that included a number of “issues” and they were asked to write a requirements document. In real life, I would hope that this would be done in a dialogue (and, indeed, in other studies, we recorded such dialogues). Absent such dialogues, what we found was that different software experts — all from IBM research — and all given the same documentation about a set of problems generated vastly different problem statements and overall approaches.

In other parts of the study, other experts were variously given requirements documents and asked to do an overall, high level system design, or given a high level design and asked to design an algorithm, or given an algorithm and asked to code a section. There was always diversity but the initial phases showed the greatest diversity of behavior. The initial stage is also the one that can cause the most expensive errors. If you begin with a faulty set of requirements — a misreading about how to even go about the problem — then, the overall project is almost certain to incur schedule slip, cost overruns, or outright failure.

While the vital importance of the initial stages of design is true in software development, I would argue that it is likely also true for advertising campaigns, building designs — and even true for the design of research programs. We designed our research agenda under the assumption that we had a long time; that we were studying design processes independently of specific communities of practice or the nature of the problems people were attempting to address. We assumed that there was no “hidden agenda.” Although we believed we would eventually need to show some relevance to IBM business, we had no idea, when we began, that only relevance to software design would be “counted.”

—————-

Some of our studies on the “Psychology of Design.”

Carroll, J. and Thomas, J.C. (1982). Metaphor and the cognitive representation of computer systems. IEEE Transactions on Man, Systems, and Cybernetics., SMC-12 (2), pp. 107-116.

Thomas, J.C. and Carroll, J. (1981). Human factors in communication. IBM Systems Journal, 20 (2), pp. 237-263.

Thomas, J.C. (1980). The computer as an active communication medium. Invited paper, Association for Computational Linguistics, Philadelphia, June 1980. Proceedings of the 18th Annual Meeting of the Association for Computational Linguistics., pp. 83-86.

Malhotra, A., Thomas, J.C. and Miller, L. (1980). Cognitive processes in design. International Journal of Man-Machine Studies, 12, pp. 119-140.

Carroll, J., Thomas, J.C. and Malhotra, A. (1980). Presentation and representation in design problem solving. British Journal of Psychology/,71 (1), pp. 143-155.

Carroll, J., Thomas, J.C. and Malhotra, A. (1979). A clinical-experimental analysis of design problem solving. Design Studies, 1 (2), pp. 84-92.

Thomas, J.C. (1978). A design-interpretation analysis of natural English. International Journal of Man-Machine Studies, 10, pp. 651-668.

Thomas, J.C. and Carroll, J. (1978). The psychological study of design. Design Studies, 1 (1), pp. 5-11.

Miller, L.A. and Thomas, J.C. (1977). Behavioral issues in the use of interactive systems: Part I. General issues. International Journal of Man-Machine Studies, 9 (5), pp. 509-536.

——————————

Blog posts about the importance of solving the “right” problem.

The Doorbell’s Ringing. Can you get it?

https://petersironwood.com/2021/01/13/reframing-the-problem-paperwork-working-paper/

Problem Framing. Good Point.

https://petersironwood.com/2021/01/16/i-say-hello-you-say-what-city-please/

Problem formulation: Who knows what.

How to frame your own hamster wheel.

The slow seeming snapping turtle.

Author Page on Amazon.

Walston & Felix Multiple Regression Study

17 Friday Jul 2026

Posted by petersironwood in creativity, design rationale, leadership, management, psychology, Uncategorized

≈ 1 Comment

Tags

art, books, development, HCI, IT, productivity, programming, regression, software, technology, UX, writing

As I mentioned recently, when I first arrived at IBM Research in the early 1970’s I began to work on Query By Example and other schemes to make it easier for non-programmers to interact productively but flexibly with computers. Some of the lessons learned have to do, not with my own work, but with the work of others.

At that time, some researchers labelled their work as “The Psychology of Programming.” There were many debates — and some studies — about structures, syntax, which language was better than others, etc. There were also lengthy discussions about the process that one should use for software development. Doing any kind of “controlled” experiment on large scale code development is prohibitively expensive. It is rare that a company is willing to have two independent teams build the same piece of software in order to learn which of two methods is “better.”

Of course, one such comparison would likely not prove much. It may be that one of the two teams had a “super-programmer” or an extremely good manager. Perhaps, flu broke out in one of the two teams. You would really need to study many more than two teams to properly and empirically study the impact of language, or syntax, or process. Doing reasonable-sized experiments would be far too costly and impractical. Our lab and others did do laboratory tasks in order to test one syntax variant against another and so on. The problems were generally quite small in order for the study to be practical. So, the applicability to real-world development projects was questionable.

Photo by Christina Morillo on Pexels.com

Walston & Felix (See below), on the other hand, were able to find data on a fair number of real-world projects and rather than try to control for languages, processes, etc., they did a multiple regression analysis based on what languages, methods, etc. real projects used and what the important predictors were of actual productivity.

Personally, I learned two lessons from their study.

Lessons Learned: #1 — Sometimes, when it comes to what matters in the real world, controlled laboratory experiments have to give way to other methods such as studying “natural experiments.” Despite the many issues with trying to interpret such findings, no-one will pay for massive controlled experiments that parametrically vary programming methods, programming languages, etc. while controlling for quality of management, experience, complexity of task, etc. Multiple regression studies and in-depth case studies; ethnographic studies; interviews: all of these can provide useful input.

Lessons Learned: #2 — The impact of the variables that our community of people were looking at in terms of syntax, structure, etc. were dwarfed by the impact of organizational variables. For example, Walston & Felix found that the complexity of the interface between the developers and the customers was extremely important.

DeMarco & Lister (See below) claim that, based on their decades of experience as consultants to the software development process, projects almost never fail for technical reasons; when they do fail, it’s almost always for organizational and management reasons.

That conclusion dovetails with my own experience. Many decades later, working for IBM in “knowledge management,” it was amazing how many companies wanted us to “solve” their knowledge management issues by building them a “system” for knowledge sharing.

But…

Management at the company would not provide:

Incentives to share knowledge

Space to share knowledge

Time to share knowledge

Or, commit any personnel to gathering, vetting, organizing, and promoting the knowledge repository.

So — knowledge sharing was something their workers were simply supposed to “do” knowledge sharing on top of everything else they were doing.

They did not want a computer system, IMHO; they wanted a magic system.

These experiences were part of my motivation for attempting to catalog “best practices” in collaboration and teamwork in the form of a Pattern Language. Christopher Alexander and his colleagues looked at “what worked” in various parts of the world when it came to architecture and city planning. What they did for architecture and city planning, I want to do for collaboration.

Naturally, merely creating a catalog is not sufficient. I need to have people who will read it, understand it, modify and improve it, and then promulgate it via actual use. For now, it’s free. Comments and critiques are always welcome.

—————-

C. E. Walston and C. P. Felix, “A method of Programming Measurement and Estimation,” IBM Systems Journal, vol. 16, no. 1, pp. 54–73, 1977.

https://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams

Thomas, J.(2008). Fun at work: Managing HCI from a Peopleware perspective. HCI Remixed. D. McDonald & T. Erickson (Eds.), Cambridge, MA: MIT Press.

——————-

Introduction to a Pattern Language for Collaboration and Teamwork

Index to a Pattern Language for Collaboration and Teamwork

Chain Saws Make the Best Hair Clippers

Author Page on Amazon

Design – Interpretation Model of Communication

16 Thursday Jul 2026

Posted by petersironwood in AI, creativity, design rationale, HCI, leadership, politics, psychology, Uncategorized, user experience

≈ 1 Comment

Tags

communication, deception, experiment, HCI, IBM, life, media, psychology, relationships, truth, UX, writing

In my early days at IBM Research (1970’s), we were focused on trying to develop, test, or at least conceive of ways that a larger proportion of people would be able to use computers. One of the major ways of thinking about this was to use natural language communication as a model. After all, it was reasoned, people were able to communicate with each other using natural language. This meant that it was possible, at least in principle. Moreover, most people had considerable practice communicating using natural language.

One popular way of looking at natural language (especially among engineers & computer scientists) was essentially an “Encoding – Decoding” model. I have something in my head that I wish to communicate to you. So, I “encode” my mental model, procedure, fact, etc. into language. I transmit that language to you. Then, you “decode” what I said into your internal language and — voila! — if all goes well, you construct something in your head that is much like what is in my head. Problem solved.

Of course, people who wrote about communication from this standpoint acknowledged that it didn’t always work. For instance, as speaker, I might do a bad job of “encoding” my knowledge. Or, I might do a good job of encoding, but the “transmission” was bad; e.g., static, gaps, noise, etc. might distort the signal. And, you might do a bad job of decoding. It’s an appealing model and helped engineers and computer scientists make advances in “communication theory” and helped make practical improvements in coding and so on.

As a general theory of how humans communicate, however, that notion is vastly over-simplified. I argued then that a better way of looking at human communication was as a design-interpretation process, not as an encoding-decoding process. One of the examples that pointed this out was a simple observation by Don Norman. Suppose someone comes up to you and asks, “Where is the Empire State Building?” You will normally give a quite different answer depending on whether the two of you are in Rome, Long Island, or Manhattan. In Rome, you might say, “It’s in America.” Or, you might say, “It’s in New York City.” If you are on Long Island, you might well say, “It’s in Manhattan.” If you are already in Manhattan, you might say, “Fifth Avenue, between 33rd and 34th.”

Building on Don Norman’s original example, but based on your own experience, you can easily see that it isn’t only the geographical relationships that influence your answer. If you were originally from Boston, now on your own in Rome, struggling with Italian and homesick and someone came up to you and asked that question in American English with a Boston Accent, your response might be: “Are you joking? But how did you know I was an American. My name’s … “

On the other hand, if you’re a 13-year old boy in Manhattan — one with a mean streak — and someone asks you this question in broken English and they’re looking around like they are totally lost, you might say, “Oh, no problem. Just follow 8th Avenue, all the way north up to 133rd. It’s right there. You can’t miss it.” (Note to potential foreign visitors, most kids in Manhattan would not intentionally mislead you. But they point is, someone could. They are not engaging some automatic encoding process that takes their knowledge and translates into English. Absurd!

You design every communication. I think that’s a much more useful way to conceive of communicating. Yes, of course, there are occasions when your “design” behavior is extremely rudimentary and seems almost automatic. It isn’t though. It just seems that way. Let’s go back to our question-asking example. Suppose you work at an information booth in New York City. People ask you this same question day after day, year after year. You’re seemingly giving the answer without any attention whatsoever. Suppose someone asks you the question, but with a preface. “Look here, chap! I’ve got a gun! And if you give me the same stupid answer you’ve given me every time before, I’ll shoot your bloody brains out!” You are going to modify your answer. It only seemed as though it was automatic.

When you design your answer you take into account at least these things: some knowledge that you communication about, the current context (which itself has hundreds of potentially important variables), a model of the person you’re creating this communication for, a set of goals that you are trying to achieve (e.g., get them safely to their goal, mislead them, entertain them, entertain yourself, entertain the people around you, demonstrate your expertise, practice your diction, etc.). The process is inherently creative. In many circumstances (writing, playing, exploring, discovering, partying), you can choose how creative you want to make it. In other cases, circumstances constrain you more (though likely not so much as you think they do).

Many readers think this is a classic example of a straw man argument. “No-one believes communication is a coding-decoding process.”

Well, I beg to differ. I worked for relatively well-managed companies. I’ve talked to many other people who have worked in different well-managed companies. We’ve all seen or heard requests like this: “I need a paragraph (or a slide or a foil) on speech recognition. Thanks.”

What??

Who’s the audience? Are they scientists, investors, customers, our management? How much do they already know? What are your goals? What other things are you going to talk about with them? The people who have left me such messages were all smart people. And, providing the necessary info would have only taken a minute or two. But it would have substantially improved the outcome. It’s not a straw man argument.

Sit-com plots often hinge on the characters doing poorly at designing and/or interpreting communications. A show based on encoding-decoding? No. What could be funny — indeed what often is shown in comedy — are people failing to do good design and in the extreme case, that can arise by having an actual robot as a character or someone who behaves like one.

People also interpret what was said in terms of their goals, the context, what they believe about your goals and capacity, what they already know, and so on. And, even though this may seem obvious, millions of people believe what advertisers or politicians say without questioning their motives, double-checking with other sources, or even looking for internal inconsistencies in what is being touted as true. In other cases though, the same people will not believe anything the “other side” says no matter what. Just as one can do faulty design, one can also do faulty interpretation.

In any case, I decided that it would be good to “show” in a controlled laboratory setting that the Encoding-Decoding model was woefully inadequate. So, I brought in “subjects” to work in pairs at a simple task about communicating Venn diagram relationships. The “designer” had a Venn diagram in front of them. “The “interpreter” was supposed to draw a Venn diagram. The “designer” was constrained to say something true and relevant. In addition to a “base” pay, the “interpreter” subjects would be given a bonus according to how many relationships matched those of the “designer.” The designer’s bonus depended on condition. In the “cooperation” condition, their payoff would also, like the interpreter’s, be determined by how much agreement was shown in the two diagrams. In the “competition” condition, the designer’s bonus depended on how different the two diagrams were.

Photo by August de Richelieu on Pexels.com

I ran about half the number of subjects I had planned to run when the experiment was ended by corporate lawyers.

What?

IBM had no unions at that time. And, they didn’t want any unions. One of their policies, which they believed would help them prevent the formation of unions was that they never paid their workers for piece-work. Apparently, somehow, IBM CHQ had gotten wind of my experiment. People were being paid different amounts, based (partly) on their performance. They couldn’t have this! People might think were paying people for piece-work!

It hardly needs to said, I suppose, that IBM definitely tried to pay for performance. This was true in sales, research, development, HR, management, and so on. No-one in IBM would argue that your pay shouldn’t be related to your performance. That was exactly — in one way of describing it — was going on here. By the way, these were not IBM employees and each subject only “worked” for about an hour.

Basically, regardless of how irrelevant this experimental set-up might have been to the genuine concern of unions not to pay people in an insanely aggressive and ever-changing piece-work scheme, the lawyers were concerned that it would be somehow misrepresented to workers or in the press and used as evidence that IBM should unionize. In a way, the lawyers were proving the point of the experiment in their own real-life behavior even as they insisted that the experiment needed to be shut down.

Lessons Learned: #1 Corporate lawyers are not only concerned about what you actually do or how you represent your work; they are also worried about how someone might misrepresent your work.

Lessons Learned: #2 Even when constrained to say something true and relevant, ordinary people are quite capable of misleading someone else when it’s to their benefit and considered okay to do.

It is this second aspect of the experiment that I myself felt to be “edgy” at the time. Sure, people can mislead, but I was providing a context in which they were being encouraged to mislead. Was that ethical? Obviously, I thought it was at the time. On reflection, I still think it’s okay, but I’m glad that there are now review boards to look at “studies” and give a less biased opinion than the person who designed the study would do.

I view the overall context of doing the study as positive. As adults, these people all already knew how to mislead. I was letting them, and many other people, know that we know you know how to mislead and we’ll be on the lookout for it.

What do other people think about studies wherein the experimenter encourages one person to deceive another?

2026 Update: I’ve spend a fair amount of time recently “chatting” with ChatGPT and with Claude. It’s clear that the implementers of these systems (or, at least some of them) were quite familiar with the idea of designing and interpreting text. Claude, in particular, seems like a “nice guy” and an honest one at that. It acknowledges some of its own limitations and often praises the questioner. This shouldn’t come as a complete shock. After all, good sales people and advertisers have relied for centuries on “Design and Interpretation.” Nonetheless, I sometimes wonder whether AI systems might be more ethically employed if they were operating on principles closer to “Coding and Decoding.” What do you think?

———————-

References published literature that describes some of the research that was done around that time.

Malhotra, A., Thomas, J.C. and Miller, L. (1980). Cognitive processes in design. International Journal of Man-Machine Studies, 12, pp. 119-140.

Carroll, J., Thomas, J.C. and Malhotra, A. (1980). Presentation and representation in design problem solving. British Journal of Psychology/,71 (1), pp. 143-155.

Carroll, J., Thomas, J.C. and Malhotra, A. (1979). A clinical-experimental analysis of design problem solving. Design Studies, 1 (2), pp. 84-92.

Thomas, J.C. (1978). A design-interpretation analysis of natural English. International Journal of Man-Machine Studies, 10, pp. 651-668.

Thomas, J.C. and Carroll, J. (1978). The psychological study of design. Design Studies, 1 (1), pp. 5-11.

———————

Other essays that touch on communication.

Freedom of Speech is not a License to Kill

Ohayogozaimasu

The Sound of One Hand Clasping

Fool Me

Claude the Radioman

Know What?

The Story of Story, Part 1

The Temperature Gauge

The Destruction of Natural Intelligence

A Little is not a Lot

Try the Truth

Stoned Soup

Turing’s Nightmares

“Wizard of Oz”

15 Wednesday Jul 2026

Posted by petersironwood in AI, apocalypse, design rationale, HCI, leadership, management, politics, psychology, The Singularity, Uncategorized, user experience

≈ Leave a comment

Tags

AI, HCI, IBM, research, technology, usability, UX, Wizard of Oz, writing

(Some Lessons Learned from studies in Human-Computer Interaction/User Experience conducted at IBM Research in the mid-70’s.)

Wizard of Oz

One of the studies I conducted at IBM Research in the mid 1970’s was part of an effort to do “Automatic Programming” — a department under Pat Goldberg. The first level manager I worked with was Irving Wladawsky (later Irving Wladawsky-Berger). His group wanted to develop a system that would allow the owner/operator of a small business to type requirements into a computer in English (or something English-like) and have the system itself produce RPG code to run the business so described.

The underlying motivation from an IBM business perspective was that many small businesses could well afford a computer to do inventory, fulfill orders, etc. but they couldn’t afford to hire programmers to create such a system from scratch. The small business owner in the mid-1970’s did not program! Yet, for the most part, they understood how their business worked. The notion was that a natural language understanding and generation program could dialogue with the user/owner and through that process, understand their “business rules.” No costly programmers needed!

An interesting side note: at that time, we were told that IBM corporate forbade us to use the terms “Artificial Intelligence” or “Robotics” to describe our work because some PR firm had determined that these terms were too scary for the general public. So, IBM had research in “mechanical assembly” but not “robotics.” We had work in character recognition, speech recognition, handwriting recognition, automatic program generation, and compiler optimization. But no work in “Artificial Intelligence.” (Wink, wink, nod, nod).

Labelism: Confusing a thing with the label for that thing.

Another interesting side note: I worked at IBM Research for a dozen years; started an AI lab at NYNEX where I worked another 13 years; came back to IBM Research and several years later found myself working on the same problem! We were still trying to make a system to allow small businesses to generate their code automatically. In my second iteration, rather than using natural language, we were trying to make the specification of business rules in a graph language that was intuitive enough for business owners. This was a different approach, but trying to address the same underlying desire: to bring computing to small business without incurring the heavy costs of programming and maintenance.

Let’s return to iteration one — the natural language approach @ 1975. Well, one issue was that no-one had a natural language program that even approximated being able to do the job. So…how to study people’s interaction with a system that doesn’t exist?

We used an approach that my colleague Jeff Kelly called the “Wizard of Oz” technique; viz., use a human being (in this case, me) to simulate how the system might work and record people’s behavior. In this way, we could discover many of the issues that such a natural language programming system would have to deal with. I had already had plenty of experience interacting with a computer; and I had acting experience. I could “play the part” of a computer fairly well as I typed in my questions and answers.

(Description of “The Wizard of Oz” technique).

IBM Research in Yorktown had roughly a thousand people including not only scientists, programmers, and engineers but also a number of business people (who did not know how to program). I knew some of them from playing tennis and table tennis and we used those folks as initial subjects. What did I find? Good news and bad news.

Dealing with natural language is tricky for many reasons. One of those reasons is that English, including the English that people normally use to describe their business, is filled with words that have multiple meanings; e.g., “file”, “run”, “program”, “object”, “table”, etc. But here is the good news: although it’s true that many English words have many meanings, when these business people described business procedures, almost all of the lexical ambiguity vanished! The program to understand business English would not have to distinguish between a business file and a nail file; it wouldn’t have to worry about distinguishing a run in baseball or a run in stockings from a run of the payroll program; it wouldn’t have to distinguish between the table in a relational data base and the table in your dining room. The domain would mainly constrain! That’s the good news.

The bad news was dialogue management. How can the machine recognize a misunderstanding and how can it correct it? To make matters worse, while business people were fairly consistent in the way they described how their business ran, they were not consistent in how they talked about the communication. If a human being senses that another one is misunderstanding, then, depending on context they might: raise their eyebrows, say “Huh?”, “Come again?”, “What?” “I think I lost you.” “WTF?” “Are you kidding?”, “We’re on different wavelengths,” “I don’t get it.” “But…wait.”

Sometimes, these are referred to as “meta-comments.” Here’s a simple example that took place in the study.

One of the business people told me about various discounts. I had assumed (playing the part of the computer) that he was talking about discounts for items that were being discounted due to inventory management. I recorded all the various percentages and so on. Then, he said, “Now, we also give discounts for various items.”

At that time, most natural language systems of that era simply ignored words like “now” and “also” in this context. Stepping out of my role as a “computer system” and thinking about from the perspective of a human conversational partner though, these words are crucial! What it signals is a change in topic. In the larger context of our conversation, it shows that everything that had just been said, which I thought had been about item discounts, was not about item discounts!

This is just one example, but there were many more. In my more recent experience interacting with various computer dialogue systems, being able to recognize the signals of miscommunication and being able to repair misunderstandings is still not very well-handled more than four decades later.

I’d be interested in any pointers you have to a system that you think deals with meta-communication in a natural and robust manner. I do not think that it is beyond the pale of possibility. The general categories of the ways that people misunderstand each other is not infinite. John Anderson developed excellent tutoring systems for LISP and geometry and those systems worked something like human tutors in that, the tutor inferred the mental model of an individual student and focused instruction on correcting any misconceptions. My intuition is that a generic system built with equal complexity could deal with most of the issues as well as the average human being deals with them; i.e., imperfectly.

—————————————

Lessons Learned: #1 You can test aspects of a system even before it’s built or even completely defined. One method that has been used many times: “Wizard of Oz.”

Lessons Learned #2: Language used by professionals to talk about their domain is much more constrained in terms of lexical ambiguity than is language when considered by all native speakers.

Lessons Learned #3: People in “our culture” (i.e., US business culture) do not have an agreed upon and consistent vocabulary for talking about communication nor a consistent process for dealing with them.

Lessons Learned #4: Speaking of communication errors, I don’t recall why, but it was about this time, that I realized that my notion about how research results would be transferred to other parts of IBM was a complete and utter fantasy. I hadn’t articulated it, but it was basically that I would do research, write the results up for publication in scientific journals for an academic audience and publish Research Reports which would be eagerly consumed by anyone who needed to know. I’m not proud of this. LOL. But that’s really kind of how I viewed it. And, then, after a few years, I realized that it really mainly came about through relationships. That was something that people had been showing me all my life, but which I don’t think anyone ever stated it explicitly enough.

Update for 2026: While the four “Lessons Learned” above still seem apropos, some of today’s chatbots such as ChatGPT and Claude are much better at dealing with connected conversations with humans that were the systems of the twentieth century. Not only that, people are now describing systems in “natural language” and the computer is writing code. That’s the “good news” I suppose.

The bad news? While my impression of most of the AI researchers of the twentieth century is that they were largely motivated by intellectual challenges and a desire to help make people more productive, I get the impression that most of the AI work of today is controlled by people who are already astoundingly wealthy and want to become even wealthier. And, as UN-laudable as we may view that goal, the wealth is only a means to an end and that end is the total enslavement of most of humanity. Even being a trillionaire isn’t enough.

That’s not to say that all the workers advancing AI have those nefarious aims just because those in charge do, but as the surveillance state becomes more pervasive, their private motivations could have less influence over the outcomes.