Project MAC, where we met S at MIT A the Software Arts building where we worked together T and the attic N where VisiCalc was written
Other writings on our personal sites:

RSS Feeds:



Comments from Frankston, Reed, and Friends

Saturday, February 02, 2002

BobF at 5:14 PM [url]:

Pardon me if I repeat myself

Language is based on using a common vocabulary of concepts upon which we can build new ones. A normal conversation is almost entirely repetition with only a few new concepts introduced. We don't rely on just words but also idioms and common metaphor such as, in American English where "sour grapes" refers to an Aesop Fable about the fox (or wolf or some similar animal) who gives up trying to get at grapes which are inaccessible and then convinces himself that they must be sour in order to pretend that he didn't give up.

Of course, when speaking within a small cultural group there is no need for such extended explanations.

But I often find myself having to create new metaphors and idioms on the fly and have built up a store of ones that seem to work well. The problem is that when I have a new audience I resort to this stock just like I would use any normal idiom. But I feel self-conscious about it because I wonder if I'm just telling old war stories again and again. But there is a big difference, as long as I have new audiences, in that I am really extending the space of concepts and not simply repeating myself. I might find it repetitious but it's more like a teacher confronting a new class to whom it is all new.

A closely related concept is that of the "sound bite", the short phrase that is the take-away from a large set of concepts. Reporters are often accused of misrepresenting a speech by capturing just one phrase. But the reporters are no different from any other listeners. If you care about what the listener takes away (hence the term "take-away") from the conversation you need to take responsibility for your own sound bites. Any good speaker knows that getting across even one new concept is a challenge and it cannot be left to chance.

My problem is that I have a lot of concepts that I am trying to explain to an unknown audience so need to resort to whatever I can use to facilitate the process. Thus I try to hone my set of sound bites or phrases and try to use them as if they are common idioms. But I run into trouble when I am too clever and skip over the explanations, especially if I am referring to an obscure story I read years ago. Yet I understand why people are shy about telling me they didn't get it -- even I know the best approach is to usually wait and figure it out by context. It's just like meeting someone you think you know -- is it better to admit your ignorance or to know that you'll get an additional clue later?

One example is that I often like to point out that the Web only works because the Internet is unreliable. The short explanation is that it is like our immune system and unless it is exposed to challenges it doesn't develop. This is a real example of becoming stronger as long as you don't get killed. The full explanation is longer and I can write about that separately but I've already gone on way too long.

I try my best to keep track of my audience and not repeat the same "lesson" more than once to a given audience though when there is a new member of the crowd I may risk repetition. But I have to remind myself, I'm not telling an old story for the purpose of reliving a past glory or an insight, I am doing what is necessary so I can build on the concepts.

Feel free to tell me you understand. In fact, as William Safire pointed out, in New York you show politeness by completing the other person's sentence. This is a very good technique and should not be confused with interrupting. It is a very efficient process of focusing on what needs to be said since what is already agreed upon needn't be repeated. If the listener is correct the conversation can move ahead, if the listener is wrong, then that's where one can focus the discussion. It is too bad that so many people on the other coast confuse it with interruption and consider it rude. Having grown up in New York, I consider it rude to have to waste my time and the speaker's time.

The nice thing about a blog is that it violates all sorts of rules about proper writing such as the excessive use of the "I" word. But while reducing complex concepts to short sound bites is a responsibility, it is also a curse that make it difficult to say anything well. So I will end by both apologizing for the lack of time to write less about this topic while also feeling that I have hardly touched the rich complexity of communicating concepts.

Friday, February 01, 2002

DanB at 9:31 AM [url]:

Web site usability results from UIE

If you are interested in web site design, eCommerce, or just normal usability issues, Jared Spool's User Interface Engineering publishes some interesting results that are worth reading. Their latest one goes through the "sieve" of losing people who are intending to purchase something from a web site as they go from page to page. Most interesting to me was how important the product descriptions are. You need to have a very wide range of information or else you'll lose somebody and those somebodies add up. You can read "The Customer Sieve". The results are applicable to more than just sites that sell. Also, you can sign up to receive their tips by email (they're not that frequent to be a bother).

Tuesday, January 29, 2002

BobF at 4:19 PM [url]:

Connectivity: What it is and why it is so important

In order to keep blog postings relatively short, I've posted a separate essay on connectivity. The summary: By recognizing the need to separate connectivity from applications we have the opportunity to unleash the power of the marketplace that has served so very well in computing and in the Internet.

Read: Connectivity: What it is and why it is so important.

DanB at 12:41 AM [url]:

Benhamou, Glauber, and Schmidt

Monday was a Massachusetts Software and Internet Council meeting. I posted some observations and pictures on my personal web log. See the January 28, 2002, entry.

For more, see the Archive.

© Copyright 2002-2008 by Daniel Bricklin, Bob Frankston, and David P. Reed
All Rights Reserved.

Comments to: webmaster at satn.org, danb at satn.org, bobf at satn.org, or dpreed at satn.org.

The weblog part of this web site is authored with Blogger.