I have always believed that slavishly creating digital analogs of real world objects yield poor products, ones that do not account for the dense social interactions that surround the information that acts as the hemoglobin in the web bloodstream. One of the best examples has been calendar apps, which have — until quite recently — lagged the advances that we’ve seen in other parts of the social revolution.
One of the example of getting this wrong was the one-time popular travel app, Dopplr, which is being discontinued 1 November 2013 by Nokia. I realized that the app was going in the wrong direction a long time ago, despite being generally admired for ‘good design’. Here’s one part of the poor social sense of the app, which was meant to help busy people keep track of their friends comings and goings. So, imagine I am headed for London for a few days. Dopplr very nicely presented me a list of my friends using Dopplr who were going to be in town that week. But the next socially adjacent thing I’d want to do would be to invite some of them to have cocktails and dinner. And Dopplr wouldn’t let me do that: it failed the social adjacency test. Instead, they wanted to show information about London from travel magazines.
Social adjacency is design theory that I have been advocating for years, as a part of what I call social architecture, which is a variant of user experience-based design. The fundamental notion is that you shouldn’t model interactions of a user with an app or a store of information the app manages. Instead, social design is based around the arcs of communications between people and the social objects that they create, share, modify, and use. In the failed case of Dopplr, they didn’t envision the set of immediately adjacent social arcs associated with the ones that they did provide. The obvious benefit of me pulling the status of ‘friends that will be in London next week’ is to connect with them through the tool, and not jump out to email (which is what the folks at Dopplr suggested to me). And of course you have to wend your way through all the arcs and sub arcs: invitations require locations to be selected, commented on, voted on perhaps. Times and dates have to selected. It started to seem like calendaring, and that was too large for Dopplr to tackle. So they fell between TripIt and calendars, and didn’t gain or retain a community of committed users.
Tempo is a smart calendar that is moving along the socially adjacent trajectory in a very directed fashion. I reviewed the app when it was first released (see Tempo is a very smart calendar appliance). Their focus has been to uncover and support the implicit social needs associated with the information that resides in our calendars. I have a call tomorrow with two people, and one socially adjacent action is to pull more information about them from various obvious sources, like Linkedin and Twitter, and information about their company as well. If I am running late, I’d like to be able to send them a message, which is an common and adjacent social act.
Google’s calendar is not designed to do so: a ‘dumb’ calendar. Which is odd, given the effort they are making with Google+. I still think they should have started with a social calendar and social email. Maybe they will buy up some of these innovators, and do so.
A new version of Tempo was released yesterday, one that continues the product’s rapid innovation. Search has been implemented (at last), as well as company cards, pages that aggregated corporate information:
I can’t use Gregarious as an example of the app showing recent communications with someone I am about to meet because G and I coordinated through Twitter direct messages, and Twitter isn’t integrated. However, I have a call tomorrow with two folks from Sparkcentral, and we coordinated via email:
Clicking on the ‘suggested emails’ opens recent email with all of the different attendees. This is particularly helpful where you may be having different threads with different subsets of the full attendee list. [This is an example of what’s needed for social email, too.] Here’s that list, which in this case is just one email with each of the two attendees, but could have been five attendees and five emails each.
The Bottom Line
With this release I have to say Tempo is now a killer app. It has socialized the calendar to a degree that I see myself using it in place of Google and Apple’s calendar apps on my iPhone. I certainly always use Tempo as a preamble to a call, and as the smart appliance to automate conference call dialing and passcodes.
There is one large caveat: a great deal of my calendar entries are created when I am in Gmail on my laptop. Someone recommends various options for a call or meeting, I look in Google Calendar, and pick a time. All of that happens outside of Tempo, and there are many things that could be done to help at that point. I’d like to be able to find things out, like when was the last time we spoke or emailed? What was the name of the last company he worked?
Tempo has not web app today, and even having one wouldn’t necessarily solve my needs. What I would like to see is a replacement for Rapportive from Tempo, as a browser extension. (Note: Linkedin acquired Rapportive last year, and released Linkedin Intro, created by the Rapportive guys, last week. It is the creepy app in my post from last week, Social email ranges from cool to creepy.)
This Tempo extension would appear — like Rapportive does — in the right hand margin of an open email in Gmail, and would provide information about the individual, like upcoming meetings, last time we met, Linkedin, Twitter, and Facebook information, and so on. It would also allow for the creation of new appointment with the people in the to:, from:, and cc: lines in the email.
And I have hopes that Tempo will become even more social. For example, the functionality of Dopplr might still be of interest, if implemented in the right way. I am planning a trip to London: Tempo knows because I say so in some travel related events for next weekend. Who have I spoken to in the past weeks and months that will be in London too? (Yes, they would have to be Tempo users, too. And they would have to opt to share that information with me.) And when this future Tempo surfaces that information, I could pick some of those folks and invite them to dinner, or business meetings. At last.