User presence awareness, by which I mean an application's understanding of the user's state of interaction with the application and its ability to adapt accordingly, still completely sucks in 2013. When I say it sucks, I mean that it basically doesn't exist. Very little of our modern computing life is actually using presence awareness, and I can't blame individual applications all that much because an application is isolated to its single device. In 2013, my phone still knows hardly anything about my tablet, and my tablet knows hardly anything about my desktop PC, and none of these know hardly anything about my workstation at the office.

The underlying cause is that in our multi-device lives we still don't have something like PAO: personal application omnipresence. PAO is my name for a theoretical computing model where application instances are singular and personal, running to service the needs of one user. They run on hardware the user owns or leases specifically for their computing needs or the needs of their family. PAO applications would provide multiple device-adaptive network-connected views, with any number of views (0 to N) open concurrently.

You could open a view of your e-mail client from your home desktop PC, from your tablet, from your phone, and from your work desktop PC. All at the same time; all interacting with the exact same application state without the need for synchronization. Typing in one view would ghost-type in all of the others because you're just seeing multiple views of a single application instance.

If you've not already read my description of PAO, I recommend you do so. I'd love to see something PAO-like in my lifetime. But the model requires better infrastructure (especially within the network and operating system) so it may not be achievable by one person or a small team.

Simplicity of presence-awareness is among many user experience improvements provided by PAO. Put briefly, presence-awareness is an application knowing where you are and how to interact with you. Because PAO applications are singular with multiple views, they know intrinsically when you are using your phone or your tablet or your desktop PC: it's merely a question of which device's view sent the last interaction. That's where the user is. In today's plain-cloud application model, each device is a first-class computer running its own applications (or interacting with "cloud" applications operated by a third-party) and none of these have insight into whether the user is interacting with another device.

This is one reason among several that plain-cloud multi-device computing—what we have in 2013—is disappointing despite all of the R&D that has gone into it. The plain cloud solves users' desire for application omnipresence through centralization, causing either lock-in or data fragmentation (I pity the fools who spread their data throughout several cloud services). Even cloud-hosted applications tend to have very poor multi-device user experience cohesion because consistent user application state is not typically a chief concern.

Today's plain cloud is most certainly not good enough.

Chat / Messaging

To explain the disappointing continued failure of user presence awareness in today's applications, I'll discuss the canonical use-case for presence awareness: chat or messaging. Be it IRC, instant messaging, SMS, Twitter, Skype, Facebook, Google+, GroupMe, or any other chat or messaging application I am aware of—they all fail at user presence.

The requirements of an ideal chat and messaging application are fairly simple:

1. Large (effectively unlimited) text length. IRC, SMS, and Twitter fail.
2. One-on-one or group chat.
3. Built-in image sharing. IRC and SMS fail. Twitter partially fails, consuming irrationally-precious characters for an image URL.
4. Direct peer-to-peer communication. That is, user-to-user communication without a third-party server. All fail at this unless you and your peers run personal IRC servers.
5. Trustworthy encryption. That is, user-to-user encryption of communication. Essentially all fail because even when SSL is used to communicate with the server, messages are still in the clear at the server.
6. State consistency. For example, consistent read position across all of a user's devices. Essentially all fail because each device runs its own application to interact with the service and none that I am aware of even try to make state consistent. This is a presence failure—each application instance does not know whether you've read something, because generally reading is just a matter of having moved to some position in a scrolling history. So they don't know where to position your view when you connect from your mobile phone after a day of chatting.
7. Presence-aware notifications. That is, notifications that are sent intelligently and with an understanding of the user's context. All fail here. Either the client applications and/or service simply doesn't provide notifications at all; or notifications are sent to all devices without intelligence; or it's up to the user to repeatedly change their notification settings as their presence changes. Some are so dumb by default (e.g., Twitter, Facebook) that they send another notification via e-mail.
8. Reliability. The use-case for messaging often assumes reliability but many services still fail to be reliable in 2013. Skype routinely fails to deliver messages or update server-stored chat history in a timely fashion. Similarly, SMS messages will simply vanish if the recipient's phone doesn't have connectivity.

Example: GroupMe

Just this weekend I was made aware of GroupMe. This chat and messaging application is apparently part of Microsoft's portfolio by way of Skype, which previously acquired GroupMe. It's somewhat odd that it remains a stand-alone service despite a great deal of overlap. After all, Windows Messenger was retired after the Skype acquisition.

Nevertheless, from what I can tell, GroupMe is (or was) a fairly ambitious project to rethink chat and messaging. Unfortunately, like so many other similar services, it left many requirements on the table, such as user-to-user communication without a third-party server, encryption, and presence awareness.

Frankly, I am left dejected that a modern-day group chat application could be funded and built with a non-trivial team and still miss these.

What they were going after is some manner of harmony in the face of user diversity, allowing you to chat with friends and family who used different devices than you.

Where they failed is the same place so many chat and messaging services—so many applications in general—fail: assuming users use a single device and in user presence awareness.

If you are connected from a phone and a tablet simultaneously, you will receive notification alerts on both as neither knows whether you are presently using the other. After all, they are each running an independent application—not views on a singular PAO application.

Furthermore, all devices will just scroll the chat to the bottom as messages arrive. So if a group chat pushes the view position past where you last read, you need to scroll back to find out what you missed. Pushing the view position down automatically is defining failure of today's multi-device applications, caused by application instances not knowing precisely what you've seen elsewhere, and therefore making a sometimes-reasonable assumption that you have been reading elsewhere and are already caught up.

Let me reiterate that: every single time you need to scroll around looking for where you "left off" in anything (a chat room, a social network's feed, e-mail, an electronic book, a document, or whatever), you've dealt with what I consider one of the major failings of modern computing. The problem is caused by having multiple applications that serve the same purpose. Multiple chat clients, multiple e-mail clients, multiple social network clients, multiple everything.

A user should only have to select and use one application for each role.

Ignoring the elephant in the room: large form-factor

In GroupMe's case, as with many modern applications, a glaring omission is in handling large form-factor—the device space we've traditionally called desktop computing or PCs. Despite the prevalence of hip nomad developers and a complicit technology press that echoes the preachy mobile everywhere creed, many of us spend nearly all day working on desktop computers because we need large displays to get work done.

Most computing work is more easily done using large displays and a comfortable consistent work environment. Therefore I spend 8 hours each day at the office working with several large displays, and when I get home, assuming I have the luxury to do so, I spend even more time consuming and creating with several large displays.

Because I rail against technology stagnation, I keep my desktop computing environment modestly up-to-date. As a result, I dramatically prefer to both create and consume on my home desktop computer than any of the many small-screen devices in my household.

Nevertheless, application vendors appear to ignore users like me.

It is somewhat ironic that the computing platform with the greatest computing capacity, largest displays, an always-on high-speed Internet connection, a full-size keyboard, and an excellent and precise pointing device (the mouse) is marginalized by so many modern application developers.

GroupMe is no exception. As far as I can tell there is no native Windows application for GroupMe—not desktop (preferred) or Metro (acceptable). Nothing. On the desktop or on a laptop, it appears you are expected to use a web browser to interact with GroupMe. No surprise then that the experience is quite poor. Notifications are missing (they don't even use tab or favicon notifications), and of course window sizing and positioning is a nuisance because you're controlling a web browser window, conflating the traditional web browser needs for a URL bar and modest UI controls with the chat terminal need for a svelte no-chrome window.

An archetypical scene depicting the failure of modern computing is one that is recognizable to just about anyone: it's a user sitting at a desktop PC or workstation using their cell phone or a tablet. Every time I see this, or I am forced to do it myself, I am disappointed.

It's not the user's fault if they need to or prefer to use a mobile device when sitting at a desktop PC. It's modern computing's fault.

The fact that SMS still exists and gets delivered to my phone exclusively means that if someone texts my cell phone number, I need to move my focus away from my multiple 30" displays to a tiny 5" display that's out of view and which I was so happy to ignore. If I want to respond, I need to fuss with a stupid on-screen keyboard when I'm sitting right in front of a full-size keyboard.

Idealized chat and messaging

In a PAO-enabled computing context, chat and messaging would work as follows:

1. Your home application server (or the application server you lease from a third-party) would run your chat/messaging application.
2. You would connect views to that application from all of your devices: your phone, your tablets, your laptop, your desktop PCs. These views would interact with the application's controller tier through SSL or VPN-style encryption.
3. State information would be singular and automatically consistent across all devices. Your read position within a conversation only moves when you move it. Period. Imagine you've read messages up to 4:55pm on your PC when you pack up to head out for the day. When you look at the conversation on your phone from Starbucks, you'll be scrolled right at the same place, seeing the next message that came in at 4:56pm even if there are hundreds of new messages to catch up on.
4. Notifications would be intelligent, being delivered to the last view to interact with the application. Location-aware devices/views would notify the application that they are active when they sense location changes, so even just picking up your phone at the end of the work day (or a transition away from charging) would be sufficient to nominate the phone as the notification endpoint. Similarly, locking your workstation would signal that view's disinterest in notifications to the application.
5. Public-key encryption and key-exchange between your peers would be assumed, allowing your personal application to send encrypted communication to all peers.
6. The chat application would provide all the standard fare: text chat (without 140 or 512-character limits), images, URL highlighting, emoji, and so on.

I would pay good money for such an application, even if I could only use it to communicate with my wife because no one else I knew used the same protocol. Reliable, secure communication without the pains caused by today's multiple first-class computing devices? Yes!

What if you're not the product?

An obvious reason this doesn't exist today is that the decentralized nature of PAO means a return to models where individuals manage their applications directly on hardware they own or lease, meaning the vendor cannot collect and create value in the form of metadata to analyze and sell. The vendor cannot make you the product.