Let's have a chat - a taxonomy and some context
(This is a text I wrote for work, but it contains nothing work specific and I might as well drop it here. Again, this is a raw brain dump and requires imagery, more contextualization and more examples to be really polished)
The first chat network I have been using was IRC - Internet Relay Chat. This has been in the late 80ies or early 90ies, so I now have had an interactive online presence on the upside of 25 years or so.
Later I got to use ICQ, Jabber, Skype, Google Hangouts, Facebook Messenger, WhatsApp, Slack and RocketChat among many others. I also got exposed to a number of collaborative document processing systems with chatlike properties: the now defunct Google Wave (alias Apache Wave), and its heirs Google Documents and Google Spaces.
All these applications and chat systems are different, and can be ordered along a number of dimensions to understand and classify chat systems better.
Managing presence in adverse circumstances
In IRC, being offline means not being present: people fall off the channel and what is being said with them being not there is lost to them. That is of course a nuisance, and so people have been using programs such as screen to run an IRC client even when they have disconnected from their (Desktop-) computer.
That of course creates a secondary problem, because now it cannot be seen if somebody is actually present or not. IRC has a somewhat hidden mechanism for that - /away - which let's one set a message and a status. But not only is the mechanism hidden (it is another command that needs to be learned and used), but the status is somewhat hidden as well - you can't see if somebody is /away unless you look at them with a /whois or you learn about the fact that they are /away only after the fact, when you say something to them and get an autoresponse with they /away message.
Some people do not like this, and so they use another mechanism and change their nicknames when they are not there - "Isotopp" becomes "Isotopp|AFK" or similar. This is less structured than /away, and so some people suffix their names, some prefix them and others completely change their nicknames - "Isotopp" becomes "Awaytopp". It also messes with log files, because in one-on-one conversations logs are often named after the chat partner, and if the chat partner changes the nick, this breaks the logging.
Because of that, all chat programs that came after IRC do have structured presence indication for this purpose, often as a combination of predefined states (Greenish 'I am here', Reddish 'I am here, but busy', 'Yellowish I am not at my computer and my screensaver went on' and additional freetext messages that can be defined). Presence and/or presence colors are shown as part of a roster or friends-directory, often by superimposing a colored icon on top of the users avatar.
Messages that come in while no client is online are typically being saved (even Skype has eventually learned that), and often chat-to-mail bridges exist for longer term presence interruptions. That is, users get chat messages mentioning their name in a chat room and direct messages delivered in their mail inbox if they are long term offline.
Optimizing chat programs for mobile creates specific problems for presence: presence state needs to be held in a central location and periodically refreshed by the mobile client without being too imposing on the battery life and mobile data quota. Conversely, mentions need to be converted into push notification on the phone according to the preferences specified by the user. In modern Android this is being managed efficiently by the Google Play Services, and while it is possible to write mobile chat programs on Android that do not use Play Services, this creates an additional penalty in terms of power and data usage that is often unacceptable to users.
Most chat programs log, some do this in a particularly clever way - various instances of the Google Chat merge their chat logs in simulated mail messages in a special GMail chat folder. This makes Chats searchable just like mails and in the context of mail search. In a corporate context, this turns chat into a deliverable in a similar way as mails are a corporate deliverable.
In a corporate context, communication is used as a vehicle to create and document agreement and the process how it has been reached. Mails and mail quotes are doing this, and so does chat, if it is handled that way. That is what the various Google Chats and their archival in the Gmail chat folder do.
Google had taken this one step further with structured chat. The pioneer application for that has been the short lived Google Wave: Wave allowed a group of people to create things in a kind of chat bubble, only that this bubble could not just hold a line of text, but also other media including rich documents, images, bots or other things that interfaced with the Wave API. Other users could comment on an item in a hierarchic comments-on-comment tree like in a discussion system, or directly edit the original item, incorporating their changes. Changes were recorded and were undoable and replayable. This allowed users to view the end result of a wave, or review the process of building that result after the fact.
In a way, Wave could have been an answer to the hell of corporate email: Waves produce results, documents or agreements, record the history of how that result had been reached, and they allow people joining the process late to catch up and review what has happened before on their own terms - no more full quotes, 13 levels deep, and no more dozens of copies of the same Word file, all slightly different and with diverging side remarks from people somewhere in the organisation, which never made it back into the main document.
Wave failed, though, and for multiple reasons. One of the bigger reasons is that Wave was all mechanism and no purpose - it could to many things and offered all of them without stating what Wave itself or the various functions are there for. One could use Wave to manage a world building and game session in a role playing game as well as replace corporate email, or use it as a rather clunky and overengineered word processor. So Wave needed explaination and contextualisation, a purpose, but none was given. Wave died.
Wave's legacy lives on, though. Much of the functionality of Wave is present in Google Docs, including the side chat, collaborative editing, history recording and replay and many other functions. Another reprise of the same idea is the little known Google Spaces ('small scale sharing'), which also does structured collaboration in a chat-like context. Nobody uses Spaces, though, so it will soon die.
Another failure of Wave was the lack of a mobile interface - Google Wave lives on as Apache Wave, but is obsolete, because it can't do touch interfaces and small screens.
Anyway, we should keep the structured and collaborative thing in mind. It is a powerful thing which alone would be sufficient to completely legitimize chat in a corporate setting.
One identity, many clients: a common history
There is Jabber. Many people praise Jabber: open, XML based protocol, extensible, servers can be federated and operated in a decentral fashion, many clients exist, all of which can talk to each other using a common protocol.
Jabber is a complete failure from a 2016 perspective, though.
Basic Jabber is a simple protocol, not media rich. A ton of extensions exists, but no common profiles exist ('a baseline client must be able to handle plain text messages', 'a multimedia client most be able to handle inline images, inline animations and emoji', 'a voice/video enabled client must be able to handle incoming SIP calls/whatever'). Because no common profiles exist, various clients incorporate various extensions, some of which are interdependent - but without profiles, these interdependencies are not structured and lead to subtle incompatibilities. Interop bakeoffs between various client developers similar to the various bakeoffs of various vendors for networking equipment do not exist in a formal way, so often there is no compatibilty information or awareness, even at the Jabber chat client and server vendor level.
Even basic functionality is not available without extensions, and these extensions depend on client and server features. For example, a single user may be using multiple Jabber clients on multiple desktop and mobile devices. Having a single unified history across all devices was added as an afterthought to the Jabber protocol, and requires client and server support. Also, having such a unified history and having end-to-end encryption of the communication interact in a bad way so that you can have only one or the other - it's either a common cross-device-history or end-to-end encrypted communication.
Originally Jabber was a federated protocol: I could be using a client on one server, and you could be connecting your client to another server. I still could address you (or a chat room) on a remote server and my server would bridge a connection to the remote server and interface there for me. Unfortunately, such federation not only created server-server-interop problems (see above for the lack of bakeoffs), it has proven to be an invitation to SPAM as well. The reaction at larger server operators such as Facebook and Google was to limit or turn off federation - at Google, one-on-one Hangouts-to-Jabber federation is still possible, but advanced and group communication features are unavailable.
This not only solves the SPAM problem, but also removes a lot of interop problems with rich and structured chat functionality coming from client divergence.
Many-to-Many conversations: Groups versus Places
When talking not to a single person, but to multiple, two fundamental differently outlooks exist: Speaking to groups and speaking in places.
When speaking to a group, the chat initiator invites a number of people into a group conversation and all of the invited persons then can talk to each other - a message to the group will be visible to all members of the group. Groups can often be expanded by invitation, but they are usually not discoverable by third parties.
When a group exists and and is discoverable by third parties which then can try to join of their own volition we are typically using a place metaphor - the group becomes a chat room, channel or other spatial metaphor. The two main differentiators are discoverability and user-initiated join, though.
Rooms often can be persistent - they exist even when empty. They usually have access controls - the room exists and is discoverable, but permission or invitation is required to join. As a public space a room often has policing functions - moderators can silence members, or temporarily or permanently expel and ban them from a place.
In a corporate setting discoverability is crucial for cooperative work, and places are a mandatory concept. Chats that have only groups but no places are quite anti-communicative and toxic in a corporate environment.
Another discovery mechanism is the roster, a public and a private directory which allows discovery of participants, often with advertised metadata ('Isotopp, infrastructure person, photograph, databases') or other attributes that facilitates serendipity and directed search. A private roster can associate bookmarks, private notes and privileges with identities ('show presence to x', 'allow direct messages from y', 'allow file transfer from/from z').
IRC is more or less completely metadata free - messages are byte-strings, and contains not even a proper chatset label. These days, utf8 or utf8mb4 are often being used, but there is no way to indicate or require that.
Modern chat have the concept of multimedia in text messages: text with charsets and RTL options, inline images, inline animations, inline videos, URLs with inline preview, inline general file distribution. Helper functions exist that allow browsing of a chats media history: clients have tabs for an image gallery, an URL gallery and afile gallery.
Bots and API
An old, but recently hip concept: bots in places or in a direct conversation, can be invited or invoked, spoken to with formal commands or in natural language, trigger lookup, media injection or external functions.
What do we want from a chat
What we want from a chat varies wildly with the clientele, dependent on the level of reflection and experience with synchronous communication, cultural and work context and many other things.
Some cultures and age groups use inline media to nuance or qualify their written text: channels are rich with emoji, giphy and meme references or other imagery. Some work styles use chat as a file distribution mechanism.
Some work styles use structured chat to produce deliverables, such as collaborative document editing, review and criticism of media artifacts or other things that result in a group-created deliverable or input for such a deliverable.
Different use-profiles are a problem, because chat programs are communication tools and hence subject to Metcalfe's Law, so using a solution such as slack for one group and Jabber for another, larger groups creates media breaks and disrupts unified communication flows in an organisation. It can even split organisations or deform deployed technology (Conway's Law).