Of Content and Content deliverers.

Last weeks Rant was all about Listening: Natural progression would be to talk about the yang of that Yin. Which brings me this week to "Content and How to deliver it so folks would listen".

Let me start with some examples from current events:

1) Google created a Web Browser from scratch and released it with a COMIC STRIP this week. They spoke through a comic strip.

2) RNC (Republican National Convention) kept the media/analysts away during their speeches, so the Content would not be sliced and diced in real time.

While listening is more of a passive role, meaning you listen to what is being said or deliverd, Delivering content appears to be very dynamic and often times takes ingenuity. Take this scenario:

Back in the 80's the guys at the Xerox Palo Alto labs, wanted machines to talk, so here is what they came up with:

CSMA/CD Carrier Sense Multiple Access / Collision Detection: The low level network arbitration protocol used on Ethernet. Nodes wait for quiet on the net before starting to transmit and listen while they are transmitting. If two nodes transmit at once the data gets corrupted. The nodes detect this and continue to transmit for a certain length of time to ensure that all nodes detect the collision. The transmitting nodes then wait for a random time before attempting to transmit again thus minimizing the chance of another collision. The ability to detect collision during transmission reduces the amount of bandwidth wasted on collisions compared with simple ALOHA broadcasting. (1995-02-23)

In every sense, we converse very much like the Protocol but still are in a state of conflict, are we creating protocols better than we can humanly interact?. When will human communications and interaction learn from switching, multiplexing, compression, stateless and stateful packet filtering?

Why is this relevant? We create in our likeness, so pay close attention as I dissect this using a metaphor approach. On the left is What is our creation and the right side is Human perception.

1) Protocol = grammer

2) Ethernet = Language

3) Nodes = People

4) transmit = deliver content.

5) Collision and detection = from a transmitters point of view, eliminate noise

What is missing appears to be the listening part. Why was that left out?. Perhaps at that time, LISTENING was not important enough to those who developed Ethernet. Circling back to my current events thought from earlier in this post, Google said they created a new browser because things have changed since the first days of the web and the HTTP protocol. So they developed a browser from scratch to meet the new paradigms of today. Quite a concept. So if Ethernet were developed today (again) would the emphasis be on LISTENING? and not so much as TRANSMISSION? Food for thought perhaps which leads us to WE NEED TO VALIDATE OUR TRUTHS OFTEN.

Problem I see with using metaphors to get a point across, is that one can get lost along the way or your reader can loose his way in the maze so the trick is to use these design principles

SIMPLE

DIRECT

VALIDATE the content periodically.

VALIDATING CONTENT , introduces the element of TIME. So the big question is should we validate our TRUTHS from time to time? and when it comes to LISTENING and SPEAKING, do our concepts need validation? Most probably.

Circling back one more time to the RNC convention mentioned above: Quite a few half truths were presented to make the point that we should vote for the Mccain/Palin ticket. Lots of innuendo's, and an approach of instilling FEAR was evident in most of the speeches. The CONTENT and the DELIVERY can be a powerful way to sway our perception even if they are half TRUTHS.

I have rambled on about the other half of the equation that makes up a CONVERSATION today. Not sure if it is a cohesive set of arguments. I will leave you with that for now.

Remember VALIDATE your TRUTHS frequently. The result might surprise you.