CommunicationProtocols


Communication Protocols

 

shorter URL: http://ttk.me/w/CommunicationProtocols

 

In short:

My communication preferences, in short:

See what I'm up to on tantek.com, and please consider contacting me via:

  1. IRC channel on the topic: #indieweb, #microformats (including HTML5 / semantic markup)
  2. Have we met? Then: iMessage tantek at tantek dot com or FB messenger
  3. Twitter: DM @t (public @-replies/mentions get lost in the noise)
  4. Book me to speak on open web standards, HTML5, microformats, IndieWeb:
  5. These CommunicationProtocols are non emotional and don't apply to family or close friends. If we're that close then you already know me better than what's written here.

 

Are we close friends? Then please also consider:

 

Lastly, as of 2014 I've stopped carrying a phone number. See: how to drop your phone number.

 

Need to send me something longer? Read on.

  1. Communication Protocols
    1. In short:
    2. Summary
    3. Background
    4. Disclaimers
      1. preferences vs absolutes
      2. work in progress
      3. Non emotional
      4. Emotional
    5. Related Projects
    6. Preferences
      1. Methodology
      2. Preference Order
        1. Read Me
        2. Communicating content
        3. Notification
    7. Etiquette
      1. Web
        1. Photo sharing
          1. DO
          2. DON'T
          3. PROTOCOL(S):
      2. Text in general
      3. Instant messaging IRC
        1. DO
        2. DON'T
          1. Don't presence query
          2. Don't busy query
          3. Don't underask for time
          4. Don't ask if you can ask
          5. Don't ask get back
          6. Don't beg votes
          7. Don't emo-hijack
      4. Twitter
      5. Email
        1. Summary Response
      6. Telephone
        1. Calling
        2. Voice Messages
    8. Reference
      1. Books
      2. Past Projects
      3. Others Communication Protocols
        1. Others contact preferences
      4. Discussion Elsewhere
      5. Related Articles
        1. 2008
        2. 2007
      6. Historical Documents

 

Summary

I've found reading what people are up to, writing to people, and notifying people to work very differently. Here's a summary of current thoughts:

 

 

This prioritization shapes the design of my ContactCard.

 

 

Background

I'm capturing and collecting some notes on my experiences with human to human communication protocols and mediums from my perspective, i.e. when others are trying to communicate with me, what works well and what doesn't work so well, and why, in the hopes of maybe helping to uncover and define more efficient habits for purely factual communication between humans.

 

I've recorded things here ranging from seemingly obvious to esoteric and even odd. My hope is that by documenting it publicly (per communicating content preference #1, wiki), errors will be found and pointed out more quickly, and maybe some may find aspects they can reuse themselves in the pursuit of improving communication, in particular factual communication.

 

Many of these discoveries, insights, and principles have resulted from incremental persistent adoption of much of David Allen's Getting Things Done book (GTD).

 

Disclaimers

preferences vs absolutes

Personal preferences mixed in with reason Often something will "feel" right or wrong about a communication protocol long before any reasoning can be developed to explain why. Sometimes it turns out those feelings had no generally applicable reasoning about them but were merely reflecting some personal preference. Despite the name "Communication Protocols" implying universal applicability for everyone, there's a lot here that's more like "Communication Preferences" that will make sense only to some, a few, or perhaps even just one person (well hopefully at least two, otherwise it's a preference that's counterproductive to communication).

 

Read and evaluate everything here for yourself. Just because some things make sense doesn't mean everything will make sense, and conversely, just because you find one thing (or a few) that makes no sense, you might still find something that does make sense.

work in progress

Incomplete Work In Progress This page is very much both incomplete (is merely being filled in as examples are found and/or experienced) and a work in progress (communication protocols will be incrementally improved over time). Yes this means there are likely some mistakes here too. If you find something which seems wrong (or doesn't make sense - see above), I'd like to know about it. Even publicly. I'm also ok with private feedback on any errors found - feel free to use the protocols themselves, or directly contact me via a method listed on my ContactCard.

Non emotional

Mostly non-emotional For now, most of this page is not about emotional and other high bandwidth personal communications which typically have very different requirements (interactivity) and different ideal solutions (e.g. face to face) than purely factual communications.

Emotional

 

Related Projects

 

Preferences

Methodology

Communications should maximize:

 

Communications should minimize:

 

Preference Order

Read Me

 

Communicating content

Communicating content and the state of information in general is best done via one or more pages on the Web referenceable by URL.

Use the following.

  1. wiki - easiest to incrementally collect state and state changes, in an open manner that others (the community) can help iterate. Organizational/capturing cognitive load is shifted more towards the writer than the reader, and thus is overall more community-efficient since typically more readers (and reading) than writers (and writing). Check The Wiki Wiki Wiki Wiki. Note special cases:
    1. consultant/client communications (e.g. contracts/designs). Any documents or specifications of a transaction/commerce nature will likely require strict datetime versioning and both access and editing controls so that the expectations are set and persisted as agreed to, based on the reality that clients frequently try to change the specifications for work (designs, etc.) after contracts have been signed.
  2. specialty sites - e.g. Flickr - greatly simplified interface for capturing data-type specific state information (whether attending/watching an event, photos) and communicating it to those that have expressed an interest without me having to bear the cognitive load of who to tell etc. everytime I make an event attendance/interest decision. Ideally these would be represented using data-type specific microformats which could be published on a blog or wiki, thus reducing the number of places to check/publish-to.
  3. blog (including Twitter) - permalinks to content help encourage more efficient discussions about the content

Obsolete. The following communication methods are in general obsolete and should be avoided for communicating content or state information.

  1. email - cognitive load of figuring out "who" to inform, what "subject" to use, noise from ".sig" etc. email signatures. See EmailEfail for more. See EmailHandling if you really want to know how I might be handling email. Warning, you might not like it.
  2. fax - can't index/search it
  3. printed letter - high latency
  4. voicemail - read-time constrained by write-time, unnecessarily slows down consumption of content to the rate that it was recorded at, often has unnecessary higher cognitive load (the effort required to listen and remember what a person is saying is greater than reading and being able to easily re-read a word or two as necessary by moving one's eyes rather than having to rewind/replay a voice message). Regularly checking only about twice a week when in the US, may check once every 2 weeks when traveling. DO NOT leave voicemails for anything needing a response in a week or less.

 

Notification

Good:

  1. IRC channels - empowers/enables the distribution of simple request handling load. archived channels ideal, especially if archived with semantic HTML and permalinks for each statement
  2. instant messaging - brief FYIs re: URLs are good
  3. iMessage txts - reader can receive on multiple devices, UX is cleaner, more focusing than Twitter DMs. 
  4. Twitter dms (direct messages) including URLs - relieves the sender of needing to decide how the reader wants to receive it (above txt because: Twitter dms have been reasonably reliable for 12+ months as of 2009-03, yet from flakey internationally (e.g. England) to sometimes more reliable than txts, above email because Twitter dms are sent as email in addition to the notification method of recipients choice).
  5. txt (SMS) - works well with smartphones with decent browsers, especially those with IM clients as well for copy/paste sending such URLs back to a desktop client. Device/provider dependent and thus unreliable if I'm traveling, or misplace my phone.
  6. emailing - UI requires more clicks to get at the content, and more contextual noise as well. Regularly checking once a day on home weekdays only. Email sent on weekends or while I am traveling will likely not be read until the first weekday after returning home from traveling. DO NOT email for anything requiring less than 24 hour response.

Reviewing:

  1. phone - phone calls are *incredibly* intrusive and thus almost always rude and undesired. Almost. See the Telephone section below for exceptions. Also device/provider dependent and thus unreliable if I'm traveling, or misplace my phone.

Obsolete:

  1. voicemail - again read-time constrained by write-time, any URLs need to be retyped (rather than just clicked). Regularly checking only about twice a week or less when traveling. DO NOT leave voicemails for anything needing a response in a week or less.

Dropped:

  1. MSN Messenger / AKA Microsoft Messenger. Due to MSN Messenger being too broken to bother using, I have removed everyone from my MSN Messenger buddy list and am not going to bother logging in to check it any more. They were the worst of the IM services (AIM, YIM, GTalk), and just like annual Microsoft personnel (HR) reviews, last place is fired (actually they just strongly encourage departure, truly firing someone from Microsoft is a very difficult, lengthy process).

 

Etiquette

Web

Photo sharing

DO

 

DON'T

 

PROTOCOL(S):

SEE ALSO:

 

Text in general

DO: keep it direct, short, and to the point. Thank Twitter for educating and encouraging folks to do this more and more.

 

DON'T: request to use a less efficient communication method. E.g. avoid:

 

Instant messaging IRC

DO

Do immediately mention in initial message the general topic area / URL that you want to FYI / ask a question about or discuss.

 

DON'T

Don't presence query

Don't just make generic presence queries / greetings without context, because the receiver of such a query has no idea whether they have the time to interrupt what they are doing to bother with what your real request is, and thus have no choice but to deprioritize your interruption to an extremely low level (effectively being ignored). Expect that IM windows (or IRC /msg windows) opened with the following will simply be immediately/reflexively closed due to the zero-content/stateless nature of the message.

Ask yourself this, would you ever direct message (dm) someone one of the following? Obviously not. So why is it ok to waste time IMing such a query? It's not. IM like you would dm.

Avoid (as in don't even bother wasting your time with starting an IM conversation with) any of the following (regardless of capitalization)

 

If I'm busy I'll just close the chat/message window. If this is your first time making this mistake, I may copy paste the following permalink:

 

http://tantek.pbwiki.com/CommunicationProtocols#InstantmessagingandIRC

 

See Also:

 

 

Don't busy query

Everyone is implicitly busy doing something at all times, thus the question of whether or not you are busy is a waste of time, as the answer is (or certainly should be) always yes. It's entirely the wrong framing. E.g. avoid:

A better approach is to consider *how* busy someone is. Of course that doesn't lead to a good line of questioning either. Instead, just condense the *actual* question you have down to a simple sentence and ask it. If it helps, assume the person *is* busy, and use that as motivation to reduce your question to the simplest possible form that will still provide an actionable answer.

 

Don't underask for time

At best these greetings are often used as substitute salutations, similar to the above. Thus, similar to the above they will be ignored. At worse such greetings bely a woeful lack of actual time estimation and/or euphemistic admission that an unknown amount of time is demanded. Avoid:

Instead, if you actually need a specific amount of time, note the topic and provide at least a rough (like you will attempt to keep it to just that much) time estimate, as opposed to an obvious underestimate.

Don't ask if you can ask

Again, often another variant of salutations, they deserve about the same level of response. Avoid:

Possible flippant replies:

Don't ask get back

Don't just make generic get back to me requests without context or specific purpose, they will be ignored. E.g. avoid:

Instead, make a *specific* request regarding a specific topic or project.

 

Don't beg votes

Don't IM me to ask me to promote something on a voting site, e.g. avoid:

Instead, beg publicly, on Twitter, your blog etc. Or just don't beg at all and make something awesome that's worthy of organic discovery and promotion, not spamming/pestering your friends to promote. Don't be that annoying marketing person.

 

Don't emo-hijack

This is a tough one (as any emotional communication in text can be). IM, since it is quieter and less interruptive than a phone call, can often be used for some emotional support when in need. This is quite valuable, and IMHO a good use of IM. However, it can be abused, and one of the abuses which I've seen happen once in a while, are vague communications of emotional dissatisfaction, often simply just to get attention. These are bad, not just because they bely a very self-centered and emotionally immature state, but also because they are likely to emotionally-hijack the recipient and make them feel vaguely bad, in a way which they can't do anything about! It could even be considered low grade emotional abuse. Here are some examples. In particular, try to avoid *only* IMing something like:

Instead, if there really is something serious that you want/need emotional support about, try to write just one complete sentence about it. Just that act will help you focus and say something more precise/actionable/supportable, and the friend you are IMing will be much more likely to offer you good support.

 

Twitter

Things to avoid:

 

Email

Latest: see EmailEfail, EmailReduction, EmailHandling, in that order.

 

Summary Response

Suitable for dropping into email responses (reconsidering...)

 

I'm reducing my use of email. Please see https://tantek.com/w/CommunicationProtocols .

 

Not so sure about this. It seems too short and perhaps a bit rude and discouraging of communication in general. For those with whom I might want to discourage communication with, I would hope there would be a better/nicer way of doing so.

 

Removed or left out:

 

Telephone

Calling

First, note that I almost never pick up the phone. Because:

 

Exceptions. There are a few (very few) cases where phone calls *may* make sense (even then most of the time txting works better).

 

 

Voice Messages

First of all, avoid voice messages if at all possible due to the read-time-constrained-by-write-time problem. Use IM or Texting instead.

 

However if you must leave a voicemail (e.g. you are unable to type/text, perhaps you are driving, maybe you shouldn't be talking on the phone and driving though) then:

 

DO keep your message under 30 seconds and identify:

 

DON'T:

 

Reference

Books

 

Past Projects

 

Others Communication Protocols

 

Others contact preferences

Various subsets (e.g. preferred means of contact) and/or analyses of communication protocols

 

Discussion Elsewhere

Most recent first.

 

Related Articles

Most recent first.

2008

July

 

April

 

March

 

February

 

2007

October:

 

August:

July:

 

See also EmailEfail, EmailReduction, EmailHandling for more.

 

Historical Documents

The following article documents various historical communication habits and differences across a variety of late 20th century cultures and examples:

 

Old shortlink: http://tr.im/comms

 

Return to ProjectsList or FrontPage.