why_i_do_not_like_im(37) Language: English

Why I do not like Chat/Instant Messaging

----------------------------------------------------------------------[ Meta ]--

name		why_i_do_not_like_im
section		37
description	Why I do not like Chat/Instant Messaging
tags		blog instant messaging chat why opinion
encoding	utf8
compliance	public
lang		en
creation	2018/04/26 19:20:33
version		1.0.3
copyright	Copyright (c) 2018 Ma_Sys.ma.
		For furhter info send an e-mail to Ma_Sys.ma@web.de.

--------------------------------------------------------------[ Introduction ]--

This is an attempt to formulate my very personal opinion about why I do not
use (nor like to use) _instant messaging_ aka. chat aka. Whatsapp (although the
latter is only a common and specific instance of the former).

--------------------------------------------[ Means of Digital Communication ]--

For the purpose of this text, at least the following means of digital
communication are relevant:

Instant Messaging aka. Chat, e.\,g. Whatsapp
   Instant messaging services allow two or more users to send messages to a
   _chat_ which is a list of messages sent by users. Instant messaging is
   _instant_ because it is expected to deliver a message quickly.
   Instant messaging clients often display if a recipient is online or offline
   (so-called _status_) and is designed to allow people to communicate
   interactively as well as asynchronously.
   Modern chat softwares often include telephony capabilities and most
   instant messaging systems are incompatible with each other, the XMPP protocol
   being one of the few execptions. Being incompatible, some instant messaging
   protocols provide unique features not seen elsewhere e.\,g. high level
   of anonymity, decentralization or simple means of finding potential contacts.

   Electronic mail is similar to regular mail: Initial messages often follow
   the same style with an opening, content and then the name of the author.
   E-mail usually has a subject and the same e-mail can be sent to multiple
   recipients. Follow-up messages often include parts (or the whole) original
   content as to provide context.
   E-mail is sent to addresses of form `username@server` where
   `server` is any computer accepting mail for users.
   This is why e-mail is a decentralized service. Additionally, e-mail usually
   arrives quickly but not as quickly as instant messages and is thus designed
   to be used asynchronously.
   Basic text messages are compatible across many e-mail clients but more
   advanced features like HTML messages, encryption or maling list handling and
   threading are not available with all clients (nor always needed).

   Unlike instant messaging or e-mail, telephony is audio-based and real-time,
   i.\,e. synchronous communication between two (or more) people. Unlike with
   instant messaging ore e-mail, it is expected that only one person
   talks at a time.
   Telephony can also use traditional analog means of transmission.
   Telephony systems are one of the most compatible pieces of technology
   available allowing about a hundred years old hardware as well as the latest
   smartphone to talk to each other due to clever handling on the provider side.

None of these are expensive today and none of these are really bound to a
specific device making all of these available to a wide audience.

-----------------------------[ Problems with Digitally written Communication ]--

Some problems are common to all digitally written communication.

   The semantics of a text is rarely exactly clear.
   Context is needed to make text meaningful. With textual communication the
   whole context of emotion is often missing and the rest of the context
   is limited to what was written before.

   Text messages are bad at transmitting emotions. To mitigate this to some
   extent, people have invented smileys and emoticons which can give text a
   happy or sad connotation and thus make its meaning more clear.
   In formal contexts, however, it is often not exactly clear how many
   smileys or emoticons one should use because it might seem childish to
   add too many of them yet it might seem hard or rude to use too few.

Time for writing
   Writing text is a pretty slow means of expression.
   Explaining complex matters in a written fashion takes a lot of time and
   often also needs a lot of text.

Time for reading
   While many people read quickly, especially in these modern times, there
   is still a lot of time needed to resolve ambiguity and find out what a
   given message is actually about. The problem here is not so much with a
   single e-mail or chat message received from a friend but always emerges in
   two similar situations: The first situation is a sort of ongoing discussion
   by at least two other people where one is ``joined'' later e.\,g. by being
   invited to a chat or CC-ed in an e-mail. Due to the different people
   involved and useless descriptions like ``Please have a look into this...'' or
   ``This problem is urgent, see below'' or even just ``FYI'', it becomes
   difficult to actually extract (1) what needs to be done,
   (2) what has actually already been done and (3) whom to contact for more
   information. The second situation happens whenever one has been cut off
   textual communication for some amount of time. What if one were to only
   rarely look at the communication? One might be faced with a lot of similarly
   contentless messages like those mentioned in the previous situation and
   keeping track of what the actual status is _now_ might become very hard to

When to reply
   With the asynchronous nature of all text messaging, it sometimes remains
   unclear when to reply best. Consider you getting an e-mail which should
   have a file attached but has not. Do you ask the sender to submit the file
   or do you rather wait for him to notice that he has forgotten to attach
   the file? How long should you wait? The same issue can arise in instant
   messaging scenarios: Suppose someone sends you an unspecific question like
   ``Do you have time to meet?'' (This is lacking a description about what to
   meet for and it is lacking an interval of time the author would like to meet
   with, it is lacking for how long one would like to meet etc). With that
   text it might happen that the author of the question quickly sends another
   message afterwards explaining the subject. Yet this need not happen leaving
   one to guess or ask back.

Expectations: Imposing work on others
   With digitally written text communication, senders expect their texts to be
   read and processed quickly. In a way, this forces every reader to accept
   work from every sender at any time: Not reading messages quickly, one can
   quickly lose track of e.\,g. the details of a planned event or the results
   of some sort of poll (e.\,g. ``who does what?''-type questions where one
   gets to do the worst if one replies too late).
   Many senders expect receivers to be able to react to updates quickly
   enough to e.\,g. re-schedule an event on the same day or cancel it

Planning ahead of Time
   With the results from the previous point, it becomes clear that planning
   ahead of time becomes impossible: If it is possible to make or cancel an
   appointment just minutes before it happens, one can never be sure how much
   time one will have at a given day.

   To provide the required speed, pepole often get live notifications whenever
   they receive a message. Together with the impossibility to be sure what will
   be done at what time, it becomes very difficult to concentrate on a subject
   for a longer amount of time, because notifications and messages are likely
   to arrive just while one is concentrating on something else.

   To make this even worse, there are also unnecessary messages, often called
   _spam_. While there is a lot of spam from untrusted people when e.\,g. one's
   e-mail address is public, there is also spam from people one likes and knows
   in the context of chat, because there people often share content
   (e.\,g. humor) of questionable usefulness. While that case may seem similar
   to spoken chatting, the sender cannot as easily determine if the receiver is
   trying to concentrate at that time or ready to chat. Even if status codes
   like ``Occupied -- do not disturb'' or similar are implemented, for textual
   messages with multiple receivers, it is often not feasible (nor wanted) to
   check that none of the recipients is ``occupied''.

------------------------------------------------------[ No Instant Messaging ]--

Many of the issues mentioned before, relate to _timing_ of the messages to
some extent. With instant messaging, times between messages tend to become
shorter making the issues worse. Additionally, it becomes more and more
difficult to distinguish between what is spam and what is not spam because it
is easy for known and trusted senders to send unnecessary, yet not strictly
unwanted messages which means the problems mentioned still increase but without
being noticed that strongly.

An issue specific to instant messaging is the idea of mobile/online use. Where
some places of work also expect quick replies to e-mail, instant messaging
is often used on mobile devices allowing receivers to stay online for the
newest messages all day and making it possible to propose events without further
preliminary thought or preparation.

Summarizing these findings, current use of instant messaging greatly disrupts
the ability to concentrate and getting work done efficiently in terms of
throughput (not latency).

One might argue that life is not all work, yet there are only those two
alternatives in this context:

 1. Communication is actually the goal. In this case, one might very well just
    call people by phone. Talking to groups is also possible with telephony
    and it is always more interactive and pleasant (e.\,g. in terms of
    communicating emotions) to talk to people more directly. Meeting physically
    is even better :)
 2. Communication is not the goal. In this case, it seems best to minimize the
    effort for communication. While it might seem that writing a short instant
    message is minimal by its size and time to write, it is definitely not the
    minimum effort taking the receiver into account: A receiver getting an
    instant message needs to cancel whatever he or she was doing, process the
    message (e.\,g. by replying etc.) and then resume (or not resume) the
    previous activity. There are few activities so thoughtless that they can
    be resumed in zero time -- for most things, one needs some time to get
    back to whatever one was doing. Due to the asynchronous nature of
    instant messages and their often incomplete content needing further
    extension later (see previous points), these times may occur very often
    thus causing a lot of time to be effectively lost with getting back to
    activities on the receiver's side.

All the problems mentioned here are not specific to technology. It seems very
well possible to use all of the means of communication sensible e.\,g. by
sending messages or calling very rarely and then with all the necessary
information at once as to keep the number interruptions minimal. Yet in
practice, people think least about these issues with chat because it is very
easy to add any missing details later and chat software does not encourage
users to prepare their message thoroughly before sending it.

As an example, one can see this with the very small detail of how the [ENTER]
key is handled in most chat software: Whenever [ENTER] is hit, the current
message is sent. Inserting a newline inside a message (i.\,e. something one
likely does when thinking before sending), is often more difficult than sending
requiring a shortcut like [SHIFT]-[ENTER] to be pressed instead.

For most people it seems difficult to understand all the implications their
spammy chat messages may have and as a result, it so far still seems best to
avoid chat as much as possible. This is true for both work and free time:
For work, one is likely to get more stress due to the fact that work needs to
be finished in the time remaining after all the interruptions from chat (also
partially applies to e-mail). For free time, there is probably not more stress,
still the interruptions from chat or e-mail cause free time to shrink.

---------------------------------------------------[ Improving the Situation ]--

A lot of insight can be gained from the people who receive a lot of (non-spammy)
e-mails with respect to the correct usage of e-mail whenever one e.\,g. asks
for help or similar. Two notable sources of information for these special cases
include the
Debian\ Mailing\ List\ Code\ of\ Conduct(https://www.debian.org/MailingLists/)
and Smart\ Questions(http://www.catb.org/esr/faqs/smart-questions.html).

Without any sort of priorization, nor claiming completeness, here are some very
basic ideas on how to improve written communication which partially overlap
with the links mentioned but also contain some other ideas:

 * Avoid unnecessary messages: Do not write, if you do not have anything
   useful to say for all receivers of the message. If what you say is
   useful for just part of the group, only write to that part of the group.

 * Talk to as few people as possible at a time (unless it is a scheduled event
   explicitly organized for the purpose).

 * Write whole messages in form and content: Prefer to give complete sentences
   and use abbreviations sparingly. Be explicit about tasks you impose on others
   and questions you want to be answered from them. Provide all the necessary
   information and if it is not available at the time, think twice and only
   write if (1) the incomplete information is already very useful for the
   receiver and (2) the missing information is very difficult to determine
   within some reasonable time limit. Do not excuse this by your current
   location or travel situation unless you are away for a very long time.
   (In that case, consider preparing your trip good enough to not only be
   able to provide incomplete information)

 * Use status codes only for relevant information. Be sure that everyone
   involved understands their semantics or is likely to guess right.

 * Prefer technical measures over organizational. This is a
   very basic concept also applying to worker safety. In the context
   of text messaging it might be interpreted as follows. If your software
   provides some useful means of organization, use it. Also note that not all
   technology is always useful. There are probably two interesting examples for
   One feature rarely used these days is ``send return receipt'' -- with that
   function (and appropriate software), a receiver may explicitly tell you
   by just the click of a button that he or she has received your message
   without any need to write an extra e-mail. Beware that this is never useful
   for newsletters or other kind of non-personal e-mail because it is very
   sensible for people to not use this feature if they believe their activity
   is tracked by this. Another feature which is very rarely useful is HTML
   mail: There are numerous security and privacy related issues with it and
   adding color to e-mail (or differences in font sizes etc.) often makes
   reading and writing such e-mails more difficult.

 * Use encryption to enhance privacy whenever feasible. It is not necessary that
   you have to hide something now. The day you want to hide something, only a
   lot of previously encrypted communication prevents those you want to hide the
   message from from becoming suspicious of the ``one'' encrypted message.

 * Use few means of communication and understand their implications.
   Today, one might easily end up with four different chat applications,
   multiple e-mail accounts and clients, a landline and mobile phone numbers
   and also multiple devices, each of which can use a subset of the means of
   communication. While synchronization across devices is getting better and
   better, it is still a concern especially if one tries not to share all
   communication with a few central companies like Google or Facebook.
   Remember that although Whatsapp messges are encrypted with state of the art
   technology, one would likely not notice an upgrade which (once installed)
   removes encryption for just one user's communication. The security of
   encryption always depends on the trustworthieness of the software it is
   performed with and thus also on the origin of the software.

Zum Seitenanfang