friends.praxeme

Maemo 5

Maemo is the framework used in Nokia Internet tablets since the N770, and today in the N900 phone which combines a cellular phone and an Internet tablet. Though I’m very found of this little thing that starts to look like the Star Trek communicator I wanted when I was a kid (except for the teleportation function), I’m not going to discuss pros and cons nor compare it to other gadgets of the same kind. I’ll focus on a concept that has been implemented in the UI: the Conversation.

The Conversation Concept

Maemo's Conversations

Conversation is a kind of abstraction for both instant messaging and SMSs threads. In a single view we have a list of all conversations going on with our contacts, including (in the last version) the rooms when the IM protocol knows about that. From inside this view we can start both an IM or a SMS thread by choosing directly in the contact list (accessed via a service oriented API). And the single view is very helpful to manage multiple conversations in a glance. Add to this the EDA architecture brought by the dbus system and all is up to have multiple alerting ways for incoming messages, including a very discreet and confidential LED lights emitting pattern (customizable): you end up with a very rich approach of what a device can do for you, speaking of human connections, all in the space of a pocket.

Cool Stuff

This is a great idea, well done and very useful, plus it’s the kind of abstract object that helps thinking differently about both UIs and more in-depth architectures: it is a natural abstract for humans, the human as a user of the device and the human as the concept linked by the exchange of messages.

But the story ends too soon

First, a conversation is the exchange of some messages between you and one contact, using one of the available protocols. This means that if your contact shares with you, for example, SMS, MSN, XMPP, IRC and GTalk (XMPP like), you could end up with five conversations with the same guy. This is weird because all identifiers (one for each protocol) are correctly stored (and manageable) in the same contact entry with the name/pseudo you want to use for that person.

Second, mails are not considered as an exchange of message, hence they are not included in the conversation view. I wonder why, but I can try to guess: mail is not seen in our common culture as an object, but as an application. Mails are older than other conversation protocols like SMSs or IMs, and during the last decades we have put a lot of attention to mailers and functions they have to provide to the user, and we probably have forgotten about the object, the mail, which IS a message and IS handled in a thread of exchanged messages. It’s not different from, say, an exchange of SMS messages.

Third, the concept is not used by some other applications that deal with new protocols. So new protocols may be added to the device, thanks to brilliant open-source volunteers, but applications are added next to the conversation UI but not integrated into it.

Why?

I see two points to help understanding why programmers did a very good work but failed to do an awesome one:

• They mixed two abstraction levels, user experience (the real world we want to deal with with the help of the device) and technical knowledge (the things we know how to do because we have built the technology for that). And, as usual, technology has tied down real user experience.
• The application concept ties down innovation and thinking by reducing all ideas to a set of functions closely entangled in a very rigid box with impermeable edges: an application is the equivalent in IT programs of a silo in an organizational structure, and we think of applications instead of the objects the user want to handle.

So, what’s next?

I’d like to see further enhancements for the conversation UI:

Semantic Aspect considerations:

• Redefine the conversation concept without the protocol: a conversation is an exchange of messages with one person, no matter what technical protocol is used to route the messages. There will be some (potentially customizable) tricks and hacks around date management to achieve the goal.
• Enrich the abstraction by including all potential protocols used to exchange messages, including voice-mails.
• Add the authentication and confidentiality concerns for all messages (no matter the protocol used to route them).

Logical Aspect considerations

• Add to the conversation object the required service oriented API to allow all add-ons (for example new IM protocols, MMS plug-in) to be fully integrated to the concept (and hence to the conversation UI).

Technical Aspect negotiation results

• Allow the user to choose a protocol for each message: one at a time, or by customized preferences, and/or with some rules about the existence of channels (is there a usable MSN connection right now?) or the capabilities of the protocol (SMS can not handle images, but MMS can).
• Encrypt all out-going messages (no matter the protocol used to route them, encrypt the message, not the channel) as soon as the contact exhibit a GPG/PGP public key (customizable).
• Sign all out-going messages as soon as the owner of the device has a public/private GPG/PGP key pair (customizable).

May 31st, 2010 | Tags: design, Logical Aspect, maemo, Open Business Concepts, Semantic Aspect, Technical Aspect | Category: Mood, Tools | Subscribe to comments | Leave a comment | Trackback URL