| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

CommunicationProtocols

Page history last edited by Tantek 1 year, 10 months ago Saved with comment

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:
    • email tantek at tantek dot com
  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:

  • Is it about something emotional? Let's make time to FaceTime or meet in person. Otherwise:
  • iMessage: my first name @tantek.com (also ok in an emergency) 
  • GTalk / Google Hangout: tantek at gmail dot com (delivery may be delayed; I'll eventually see it)

 

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.

 

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:

  • Read: what I've been up to, working on, and planning

  • Write: proposals, plans, discussions

    • Hire me to speak, teach a workshop, build something, or write/improve open web standards: (I'm happily employed at Mozilla)
    • Book me to speak on open web standards, HTML5, microformats, IndieWeb:
      • email tantek at tantek dot com
    • Otherwise: write your longer message on the web, e.g. on your personal site, wiki, or on a data-type specific website (e.g. your photos on flickr), and then notify me with a short message and URL as follows:

  • Notify: to send a short message or a brief question (anything longer, see Write me above)

    • technical or community questions:

    • personal or private work related:

      • If we are close friends: iMessage: my first name @tantek.com OR FB Messenger

      • Have we met: GTalk: tantek at gmail dot com

      • Twitter direct message (DM) @t - quick question/reply only - not a thread

      • else email (please keep it to a single subject, and brief) tantek at tantek dot com

    • realtime event coordinating - e.g. if we have a pre-existing plan to meetup and are just trying to find each other

      • iMessage: my first name @tantek.com - simplest UI (especially if you've txted me before)

      • FB Messenger

      • FaceTime/Skype call - device/US dependent

    • close personal (catchup or anything emotional), pre-arrange by IM, iMessage, DM to:

      • in-person

      • FaceTime

 

 

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

  • Limited personal capacity. I've found as an introvert I have limited capacity for emotional communications. Thus I've chosen to focus that limited capacity on family and close personal friends, and prefer to use limited, low or non-emotional communications otherwise.
  • Text is bad for communicating emotions. Emotions are often filtered out in text communications and thus difficult to discern. This can be a positive (reduce drama, spreading of negative emotions) or a negative (emotional miscommunication). Especially in personal relationship communications:
  • Text only to arrange a better method of communication. In personal communications, if what we have to talk about has essential emotional context (i.e. anything interpersonal, especially any kind of interpersonal conflict), let's please only use text communications to arrange a better way to talk.
  • Good communication methods for emotional context. Emotional context is best communicated in order: in person, video chat, audio chat. Audio quality is important, as is the realtime nature. Voicemail is perhaps the worst.
  • Beware of  Highly emotional/irrational/unstable behavior is still possible in text communications and thus it is helpful to document how to DefuseEmoCommunications as one of many possible error conditions to handle, if not resolve, at least to defend against.

 

Related Projects

  • CommunicationFilters - communication methods require filtering to maximize signal to noise, usabilty, efficiency, and minimize the propagation of negative emotions and other negative behaviors.
  • EmailEfail - more detailed documentation of how and why email is failing in general.
  • EmailReduction - as one of my least preferred methods of communication, I am methodolically working to reduce my use of email, both necessary and optional.
  • EmailHandling - how can we radically alter how we handle email and still maintain some level of communication compatibility with the result of the email-centric world?

 

Preferences

Methodology

Communications should maximize:

 

Communications should minimize:

  • Emotional errors (difficult to undo / correct)
  • Time length of synchronous communication
  • Time length of voice or other read-time constrained by write-time messages
  • Roundtrip requirements (the number of times you have to back and forth)
  • Intrusiveness
  • Cognitive load
  • Negative reinforcement
  • Latency
  • Ephemeral content

 

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
  • Upload flattering photos of people - everyone likes seeing nice photos of themselves.

 

DON'T
  • Upload unflattering photos of people, unless they specifically ask you to (goofy/funny photos etc.)
  • Upload photos that may compromise someone's expectations of privacy. As this varies quite a bit per person, location, city, event, time of day etc., there are no hard and fast rules. A good guideline is if someone appears uncomfortable at the sight of your camera (or in pointing it their direction), then don't take their picture. When in doubt, consider asking them if you may take their picture (e.g. for uploading to Flickr).

 

PROTOCOL(S):
  • Photo takedown protocols
    • Photo that you are in. If you see a photo with you in it in my Flickr stream that you dislike for any reason, tag it with "YOURNAMEHEREhatesthisphoto" and I will promptly mark it private.
    • Photo of your personal space(s). If you see a photo with some aspect of a space you frequently personally occupy (e.g. your residence, your specific office/cube) that you dislike for any reason, tag it with "YOURNAMEHEREhatesthisphoto" and I will promptly mark it private.

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)

  • "allo"
  • "allo?"
  • "alo"
  • "alo?"
  • "ello"
  • "hello?"
  • "hey"
  • "hey, around?"
  • "hey tantek"
  • "hey tantek, you around?"
  • "hi"
  • "howdy"
  • "ping"
  • "psst"
  • "pssst"
  • "there?"
  • "u around?"
  • "u there?"
  • "ut?"
  • "you there/"
  • "you there?"
  • "yt?"

 

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:

  • "hey tantek u busy?"
  • "u busy?"

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:

  • "got a minute?"
  • "got a sec?"
  • "hey tantek, got a sec?"

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:

  • "can I ask you a question?"
  • "you up for a quick question?"

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:

  • "email me at some point"
  • "Hey, message me back when you get a chance"

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:

  • "Can you please digg/like/+1/tweet if you get a moment? {URL}"
  • "digg/like/+1/tweet please: {URL}"

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:

  • ":("
  • "meh"
  • "sigh"
  • "ugh"
  • "big.sigh"

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:

  • Please don't ask me to follow you (e.g. using one of the other mechanisms above). It's not respectful.
  • Please don't ask me for retweets. I am not your marketing arm.

 

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:

  • "in deference to IM/IRC+wiki". to keep the actual preferences live on the CommunicationProtocols page rather than statically captured in an email.
  • "in order to scale". I think this meaning of "to scale" will only confuse most people.
  • "for how to contact me". If they can't figure out that's what I mean, do I really want them contacting me?

 

Telephone

Calling

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

  • Phone calls are almost always an intrusion into whatever I am doing realtime "in the moment" in front of me, and thus a distraction (efficiency reducer, priority inverter, GTD collect vs process separation failure), and rude to the people I am with in person.
    • Instead: try txting, giving a very clear reason why you think a phone call is necessary (at the moment or later).
  • I'm often in loud areas where phone conversations just don't work.
    • Instead: txt.
  • I'm traveling. Answering phones works very poorly in airports, e.g. checkin, security, loud announcements, distractions, etc.
  • I'm abroad. If I'm in a different country, especially one more than 3 hours off from my current time zone, I will almost certainly not answer the phone.
  • For more reasons to avoid talking on the phone, see: http://gizmodo.com/5477638/10-reasons-to-avoid-talking-on-the-phone

 

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

  • realtime sync for meeting up. When trying to meet up for an event planned in advance (via some other communication method), a short phone call *may* sometimes be more efficient to coordinate than txting back and forth. That being said, try txting first, and only after one back/forth is insufficient, then call.
  • emergency for emergency contacts. Everyone has a short list of folks for which they are emergency contacts, and who know to respect using the phone only when it is absolutely necessary and thus likely to be an emergency of sorts. I'll answer these kinds of calls if possible, but since it's often not possible, even in an emergency, txting may be a more reliable method of communication.
  • local to the city I'm traveling in. When abroad, I may answer phone calls from those local to the city that I'm in, as it may be a more reliable communication method than other options. I will still encourage folks to instead:
    • Twitter direct message (free for the sender and the receiver)
    • Txt
  • emotional context. Just a pointer to the Disclaimers section above.

 

 

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:

  • NAME. who you are
  • ORG. what organization you are with (sets context for the message)
  • TOPIC. about what topic (immediately helps receiver determine whether to process this to-do item immediately/urgently or to postpone)
  • REQUEST. what you need/want - mention a specific request (ditto)
  • BY WHEN. when you need an answer (helps with processing prioritization and relevance as well)
  • CONTACT INFO. leave follow-up contact info (redundancy, in-case the receiving voicemail system does not record the caller-id of the sender, or another medium is preferred for response, e.g. wiki/email/IM etc.)

 

DON'T:

  • pause with "uh"s while collecting your thoughts
  • use impatient, patronizing, condescending or otherwise negative communication tones
  • make general non-specific contact requests (expect these to get deprioritized, just like "yt?" IMs). AVOID only requesting
    • "call me back"
    • "get in touch"
    • "can you please give me a call"

 

Reference

Books

  • David Allen: Getting Things Done (GTD)

 

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:

  • E-mail Faces Deletion (2007-10-12) by Robert Scoble published in BusinessWeek.
  • E-Mail Is Easy to Write (and to Misread) (2007-10-07) by DANIEL GOLEMAN published in The New York Times, Job Market section.

    In contrast to a phone call or talking in person, e-mail can be emotionally impoverished when it comes to nonverbal messages that add nuance and valence to our words. The typed words are denuded of the rich emotional context we convey in person or over the phone.

    E-mail, of course, has a multitude of virtues: it’s quick and convenient, democratizes access and lets us stay in touch with loads of people we could never see or call. It enables us to accomplish huge amounts of work together.

    Still, if we rely solely on e-mail at work, the absence of a channel for the brain’s emotional circuitry carries risks. In an article to be published next year in the Academy of Management Review, Kristin Byron, an assistant professor of management at Syracuse University’s Whitman School of Management, finds that e-mail generally increases the likelihood of conflict and miscommunication.

    One reason for this is that we tend to misinterpret positive e-mail messages as more neutral, and neutral ones as more negative, than the sender intended.

 

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.

 

Comments (0)

You don't have permission to comment on this page.