The app is now done and has been submitted to the app store. So, say hello to Crème, the new iPhone Twitter app. See more info at cremeapp.com.

There’s so much more to post. I’m really happy that the project is done now, I think it came out quite well. But, of course, a lot of the features are missing still, and I’m already planning next versions.

For now, you can check out cremeapp.com for some nice screenshots and feature overview, and follow @cremeapp to hear more about when it will be available on the App Store.

[ Update: wow, I got great response. So, if you haven’t responded already, then… you may still contact me, but I may add you in a later round. Or just direct you to the app store for the complete version soon. Thanks to all who have responded thus far. ]

For some nights and weekends, I’ve been working on a yet unnamed/unbranded iPhone Twitter client app. I’ve looked at all the existing ones and I think I have some new things to contribute to the scene in terms of the UI, interaction and the overall experience.

I’m now starting a closed/private beta. To join, you need to have an iPhone (vanilla and jailbroken are both fine) and use Twitter at any level. You also need to have some imagination and patience because parts of the software are still broken or need some work. But, the app is not just a raw piece of rock any more. You can see the outline of the final thing, it’s starting to shape up and just needs lots of sandpaper—and your help, both in terms of technical testing and UI/interaction feedback. The goals of the test are to get to a good place with the technical quality of the app, and make sure the interaction is solid.

If you’re interested, contact me through some private channel (email, Skype chat) this weekend (Feb 13-14… happy Valentine ) to get set up. We’re going to use Google Wave (remember? Wave? Not Buzz. Wave.) as the collaboration tool. If you haven’t used Wave before, it will be an interesting experience from that perspective too.

Your main benefit will be participating in the test with me and a fun bunch of other people, and witnessing the app coming together. The final app will sell for a few dollars, and all the testers will get it for free. There’s no other material compensation. The beer, though, will be on me the next time we meet.

Get it

Get it from GitHub.

As part of the example, I also put together a very simple iPhone app that just lets you sign in to OAuth with Twitter and lets you post an update. I tried to showcase how logging in works, and how to handle things like user deauthorizing your app etc in a reasonable way.

The focus of this app is much more on the architecture than the UI; the UI is just the simplest I could put together to accomplish the purpose.

Here is the screenshot walkthrough.

It is not great that the user goes away from the app and to the browser. But, I could not imagine how to fit the viewable PIN, PIN entry field and keyboard into the UI in a reasonable way, so I did not even try.

It wouldn’t be so bad if the PIN could be copy-pasted in a reasonable way. But, since the PIN is seven digits, iPhone tries to be helpful and thinks that it is a phone number. By tapping on it, it lets you call the PIN, but not copy it. (It actually is possible to copy if you play around with your finger.)

I don’t know what would be a good experience. Can Twitter construct some mini-PIN display that still works for a UIWebView within an app? Or can they provide an iPhone-optimized web UI for /authorize and/or just disable the phone number recognition (not sure if you can do it by some WebKit smartness)? Sending user off to browser is surely the cleanest solution from the security perspective, as you don’t capture their credentials within the context of your app.

So, I decided the time has come for me to learn more about OAuth, and specifically how to work with Twitter API using it, instead of HTTP Basic Authentication. I found some shortcomings in existing docs and thought to write a post.

This post is for you if you:

• know how HTTP works on a general level: e.g you know what’s a request header.
• kinda sorta know what OAuth is and does even if you haven’t developed for it before; if not, read e.g Wikipedia or Beginner’s Guide to OAuth.
• want to understand how the protocol works for client apps on the barebones/wire level, instead of just using a client library.

Let’s see what resources there are today to learn about OAuth:

• Beginner’s Guide to OAuth
• Blaine Cook’s presentation
• Twitter API wiki OAuth FAQ and authentication guide
• oauth.net spec 1.0a and the RFC draft (newer than spec)

Some of these were somewhat helpful, but there wasn’t one single guide that satisfied me. The RFC is probably the most accurate as reference material, but it is very dense and hard to parse/follow if you are starting out. Terminology has also changed over time, and the RFC points out the mapping between “old” and “new” terms.

What I find most helpful when working with a new HTTP-based protocol is to examine what “goes on the wire” and what comes back. There are some examples in the above, but they are not one coherent story. The examples are also generic, and not specific to Twitter, which is what I was interested in. So here we go… an introductory OAuth session in three (+1) steps.

0. Register your app with Twitter

Go to Twitter OAuth clients and register your app. Select “Client” as the app type. You will get two very important pieces of information: “consumer key” and “consumer secret.” You will use them below. RFC calls these “client credentials.” (Confused about terminology yet?)

1. Request temporary credentials from Twitter

You will now issue a HTTP GET request to the following URL:

https://twitter.com/oauth/request_token

(Twitter actually uses HTTP throughout the examples on their site, but HTTPS is better for security and works fine.)

It is a simple GET request, but as part of it, you include the following HTTP header:

Authorization: OAuth realm="", oauth_nonce="92673243246",
oauth_timestamp="12642432725", oauth_consumer_key="9874239869",
oauth_signature_method="HMAC-SHA1", oauth_version="1.0",
oauth_signature="l%2FXBqib2y423432LCYwby3kCk%3D"

Whoa. What?

Yes, that’s basically how OAuth works. It is otherwise like simple HTTP, but you just include this special header in all your requests. (It should all be one line, it has linebreaks above just for readability.) So. Let’s talk about this header. (There are other ways to do this besides the header, but RFC section 3.5 says header is preferred anyway, so we will just use the header.)

You see it has a bunch of fields. Here’s what they should be:

• realm: “” is fine for Twitter
• oauth_nonce: a unique value. I myself use sha1(timestamp || str(random)), i.e current timestamp concatenated with a random string. Anything should be fine as long as it is unique string. Keep it alphanumeric or hex for simplicity.
• oauth_timestamp: current UNIX timestamp, seconds since epoch (Jan 1 1970).
• oauth_consumer_key: what you got from Twitter.
• oauth_signature_method: just use HMAC-SHA1. There are other methods, but I won’t talk about them.
• oauth_version: just use “1.0.”
• oauth_signature: this is a signature calculated across a set of fields in a very specific way, so let’s talk about that.

OAuth signature and the signature base string

OAuth headers need to include a signature. It is calculated thus:

signature = base64(hmac-sha1(signature_base_string, signature_key))

So, there is some hmac-sha1 function that takes two things as input: a base string and a key. It signs the base string with the key and returns a signature. The output value must be base64-encoded. Treat these functions as black boxes, just find a hmac-sha1 and base64 implementation and use those, they are standard.

Let’s talk about the key first. The key is defined thus (“||” means concatenation):

signature_key = consumer_secret || "&" || token_secret

“But I don’t have a token_secret by this point?” Correct, you don’t. So if the consumer secret was “abcd”, your signature key in this stage is “abcd&”.

Now, let’s talk about the base string. Here is an example base string.

GET&https%3A%2F%2Ftwitter.com%2Foauth%2Frequest_token&oauth_consumer_key
%3D1rB94WF54ayRvryLQIZ01A%26oauth_nonce%3D92676946%26
oauth_signature_method%3DHMAC-SHA1%26
oauth_timestamp%3D1263777725%26oauth_version%3D1.0

Again, it should all be one long string without linebreaks.

The algorithm to calculate the signature base string is:

signature_base_string = HTTP_METHOD || "&" || urlencode(normalized_url)
    || "&" || urlencode(parameters_string)
parameters_string = join(sorted_urlencoded_parameter_keypairs, '&')

In English:

1. Take the request parameter keypairs. These are your GET or POST key/value pairs. We don’t have any in this first example. In addition, you have a set of core fields that are included, which you can see above.
2. Sort the keypairs alphabetically by key, merge them into a big string “key1=value1&key2=value2”, where the keys and values are URL-encoded. (RFC specifies a specific method of URL-encoding; see section 3.6.)
3. Construct the base string by merging the HTTP method, normalized URL, and URL-encoded whole parameter string into the base string. This means that for some parameter keys/values, you will see double URL-encoding: first the individual value was encoded, and then the result got encoded again due to the whole parameter string being encoded.

OK… so, let’s go back to where we were. We have managed to construct a signature base string, and have signed it. We have put together the OAuth Authorization header. We fired off the GET request. At this point, one of two things will happen.

First, you may get a “401 Not Authorized” response from Twitter. It is helpful to examine the response body for more detail. It will say something like “Invalid signature” or “Invalid / expired nonce.” Use this knowledge to fix what you were doing. I had lots of trouble to get the base string and signature calculation right. Don’t forget that the signature key always contains “&”. And Twitter really does make sure that nonces are not reused: if you send the same correctly constructed request twice with the same nonce, then the first one will be successful, but the second one will fail.

Let’s say you did everything correctly. In this case, you will get a 200 OK, and the response body will be:

oauth_token=lLUrf57ghMfIt24173AgJiSUHjTbT
EdNRqOqQFz5Pk&oauth_token_secret=5K60EOjryJVtiC
NkwoEteTQkGhMkrwFsEMs&oauth_callback_confirmed=true

Aha! Now we are getting somewhere. Capture and save the oauth_token and oauth_token_secret values; you’ll need them soon. Disregard oauth_callback_confirmed; since you are a client app, there are no callbacks.

1.5 Redirecting user to obtain the PIN

Next, you need to redirect the user to this URL in their browsers:

https://twitter.com/oauth/authorize?oauth_token=Bo2bmtiydaKScpMqzIsEWuZuG2x8

Where the token value is, of course, the one that you got from Twitter just a second ago.

The users will then go through these screens:

They will come back to your app with the PIN, and will expect to input or copypaste it somewhere. Let’s see what happens after they do that.

2. Obtaining an access token from Twitter

You now have your consumer key and secret, token and token secret (which are temporary by this point), and the PIN that the user input (in the spec terms this is “verifier”). You now make the following HTTP GET request:

https://twitter.com/oauth/access_token

The header should be something like:

Authorization: OAuth realm="", oauth_nonce="926534246",
oauth_timestamp="1890725", oauth_consumer_key="9874239869",
oauth_signature_method="HMAC-SHA1", oauth_version="1.0",
oauth_signature="l%2FXBqib2y422LCYwby3kCk%3D",
oauth_token="31242343232", oauth_verifier="8689612"

The signature base string is something like:

GET&https%3A%2F%2Ftwitter.com%2Foauth%2Faccess_token&
oauth_consumer_key%3D1rB94WF54ayRvryLQIZ01A%26oauth_nonce%3D
86345093%26oauth_signature_method%3DHMAC-SHA1%26
oauth_timestamp%3D1263780501%26oauth_token%3D
Bo2d2oZewAyOHstF5bmtiydaKScpMqzIsEWuZuG2x8%26
oauth_verifier%3D2383255%26oauth_version%3D1.0

This is actually very similar to what we did above. Only three changes:

• The URL is https://twitter.com/oauth/access_token.
• The header and base string contain two new parameters, oauth_verifier (user-entered PIN) and oauth_token (what you got from Twitter as response to previous request).
• Remember how signature key is calculated: signature_key = consumer_secret || “&” || token_secret. You had both of these by this point, so the key was something like “abc123&456cde.”

(The Twitter API wiki says that the method for this call should be POST. I am not sure why, but as empirically shown, GET works just fine.)

The outcome is one of two things. Either “401 Not Authorized,” in which case it is again time to debug. But if all is well, Twitter responds with 200 OK and the following body:

oauth_token=103393708-XKheKolp4P775W8Ejr1DQ
Z82AciwFOicaRg6hw1Y&oauth_token_secret=vRaADq6
v7vUZ90fisaIF2jqJZW29pKVS8vLKMUb
f3k&user_id=103393708&screen_name=exampleuser

Cool! If you get by this point, you have done the bulk of the work and are pretty much done. As you see, we got four things back from Twitter:

• user_id and screen_name. These are the identifiers for the user who signed in. Note that you haven’t actually asked the user for anything in your app; you just get the userid and screenname like this back from Twitter. You can now save and use them.
• oauth_token and oauth_token_secret. Here is the confusing part: these parameters are called the same as they were before, but they mean an entirely different thing. These are now AUTHORIZED, which means that you will now use these to make further requests. Throw away the previous oauth_token and secret, and keep these new ones. In RFC terms, these are “access token and secret.”

3. Making further requests

You would do the above steps only once per user in your app. They would authenticate once, and then forget about it. Now you will continue to make Twitter API requests. Let’s look at a simple example of updating status. Say you POST to this URL:

https://twitter.com/statuses/update.json

And your post body (parameters encoded in a standard way) is:

status=hello+world

Your header would be:

Authorization: OAuth realm="", oauth_nonce="926534246",
oauth_timestamp="1890345", oauth_consumer_key="9874239869",
oauth_signature_method="HMAC-SHA1", oauth_version="1.0",
oauth_signature="l%2FXBqib242y422LCYwby3kCk%3D",
oauth_token="31242343232", status="hello%20world"

And the signature base string would be:

POST&https%3A%2F%2Ftwitter.com%2F1%2Fstatuses
%2Fupdate.json&oauth_consumer_key%3D1rB7654ayRvr
yLQIZ01A%26oauth_nonce%3D45586507%26oauth_
signature_method%3DHMAC-SHA1%26oauth_
timestamp%3D1263781497%26oauth_token%3D1033
93708-XKheKolp4P775W8Ejr4234246hw1Y%26o
auth_version%3D1.0%26status%3Dhello%2520world

Note the new “status” field, and how it may be differently encoded in the POST body and in the signature base string. It is in the end since the keys were alphabetically sorted.

Phew… that’s it.

A note on debugging

The above may be difficult to debug in your client app. One strategy that I found extremely helpful was to use curl. Here is how you would do the curl request for the above status update example:

curl -v -X POST -H 'Authorization: OAuth realm=""
oauth_nonce=... etc' -d "status=hello world"
https://twitter.com/statuses/update.json

So, in your client app, you would generate this header, but not actually run the request. Remember that nonces need to be unique; you can only run the request once with the same nonce value; changing it arbitrarily would invalidate the signature. So, just generate and print the header from your client app, and try to curl it, and see what you get back. The -v flag ensures you see plenty of debug info.

Acknowledgements

Tweepy is a great Twitter API implementation in Python. I used it to debug the protocol, just inserting print statements in relevant places, letting me trace what went on the wire and what came back.

See also

Here’s another post about my OAuth implementation in Objective-C that also has an example iPhone app.

First, I went to a nearby AT&T store. They had the phone, but they said I can only buy it with AppleCare. (Rushing ahead, the Apple Store people told me this is a lie.) But I didn’t feel like arguing with them, so I went to Apple Store instead.

Managers of various capacity came by to look. They thought maybe the SIM in the phone is bad, so they exchanged the phone for a new one. Same thing. Everybody was very friendly, but obviously distressed at the same time because me and them had to put up with AT&T not activating the phone in a timely manner.

They said that maybe something is up with my service plan and I should go to AT&T to check it out since it is a network-related issue. (Reminds me of a “Mac vs PC” ad where the PC is calling various help lines in vain.) Luckily, there was an AT&T store nearby… except that it would close in a few minutes. But I made it in time.

The AT&T people were upset with the Apple People who had sent me to AT&T with a phone that says “no service.” This shouldn’t happen, they figured. Maybe.

AT&T gave me a new SIM and one of the more competent people looked at their computers and said there is a “network delay” of 2 hours. Whatever that means. They said that I could just go home and my phone with the new SIM would be activated later. Which is true. But then again, the first 3GS that I bought would probably have woken up the same way.

So, the final verdict is that there was some AT&T network delay that gave me and Apple Store people a bad iPhone 3GS buying/selling experience.

On a side note, the Apple Store retail staff always used to have some sort of custom PDA for mobile sales processing. Today I saw that they have replaced it with iPod Touch in a custom enclosure that contains barcode and credit card readers. Dogfood, eh. I mentioned this to the salesperson and he said he was very happy about the Touch and the sales app. Which indeed looked pretty slick.

Maintaining read/unread state

(Mentioned it previously, but it was so low nobody got to it, hence this new post.)

… or, more precisely, this is about maintaining “last read” position in your Twitter stream. I don’t think people will want to selectively mark stuff read and unread as you’d do with, say, email. But it is important to keep a pointer to what I’ve seen, so that it would be easy for me to tell the new stuff from old.

(Aside: read/unread would be one way to mark stuff as “to read later.” Currently, some people use favorites for this. Not a bad idea. But neither favorites nor read/unread are really for this purpose. Maybe we need something yet new…)

Currently, clients do this on their own, but do not share this data. For example, Tweetie exists on both my desktop and iPhone, but I still see the same messages twice. Nevermind other clients or Twitter.com itself.

One solution would be to create a third-party site to offer this as a service to clients. I don’t know what their business would be, but you can imagine clients sharing this data. And it can be with or without authentication. With, it’s secure but annoying. Without, you could find some downsides in privacy, but you could package the data up and offer it to the community. Who reads what and when? Is this sort of metadata privacy-intrusive? I don’t know. I myself wouldn’t care. (If I was more agile, I’d have the service running by now, it’s a few simple calls… basically setLastRead(user,lastReadId) and getLastRead(user) and that’s it.)

But really, this should be part of Twitter API, similarly to how your IMAP email, Skype Chat and Google Wave can keep track of what you’ve seen and what’s new.

Today’s campaign was interesting. Some tweets are shown red on Twitter.com based on certain criteria, but this does not come through to any clients.

This illustrates the tension between Twitter being an end-user product and a platform. As a product, you can promote any cause you want. As a platform, you should be content-neutral and removed from any such activities. Furthermore, you should be predictable and not repurpose users’ content in ways that are not agreed upon. Maybe I am all against the red color, why are you forcing it upon me? Maybe I was using #red hashtag as “Rocket Engine Designers” and don’t care about your initiative?

Priority contacts

Here’s a great video. Currently, Twitter contact lists are flat. If you’re like me with a few hundred contacts, you miss a lot of the activity. And for some of it, it’s OK: some people are more entertainment/ephemeral value and it’s OK to not see everything. For some, though, I really care about what they have to say, and would like to prioritize them to always come through. Current Twitter API typically gives you 200 messages at a time: I’d like to tune it so that I’d rather miss some tweets from the ephemeral people than be shown everything.

You could repurpose lists so that you could make a special list with your priority contacts, but here’s the thing: I don’t want my priority contacts to be public. This would reveal connections and interests beyond what I care to disclose.

This sounds like something that could start as a client feature and later graduate to the API if it’s really valuable. Hmh, where’s that pet project of mine… everybody must have their own Twitter client, right?

It has many UI flaws, but those are just minor glitches that I can live with. The biggest flaw is that some Waves can simply break. There’s one in particular where some member attempted to do something with a plugin. After that “something”, the wave is simply BROKEN for EVERYONE and the content is inaccessible. When we try to access the Wave, everyone gets this message:

This is data loss, and not acceptable. (Yes, I have submitted a response and reloaded many times.) So, my approach is that you cannot yet trust Google Wave and better be careful what you put there. I will change this when they either fix a wave or explain that this is an irrecoverable problem and how they make sure it won’t happen again. Until then, watch out with your waves.

I was intrigued because it was a déjà vu from five years ago to me. It was the time when I was challenged with leading the effort to design Skype chat to support multiple people. I now thought a five year anniversary is fitting to document this part of Internet history. And furthermore, enough time has gone by to make sure that this doesn’t contain any proprietary info or doesn’t hurt anybody. A lot has changed with Skype chat and conversations, and I mostly wasn’t a part of the later changes. I can’t really explain the more recent work. I can only discuss how it came to be.

So, it was somewhere in 2004 and Skype realized they need to revamp their text chat/conversation system. Skype actually had one from the very beginning, but it was one-to-one and not very nice. It did support the basic concept of queueing messages that is extensively used today as well; that is, you could write a message to someone regardless of whether they were online or not, and it would be delivered the next time you would both be online. True to Skype’s serverless architecture, the message would simply be queued in your computer.

I was tasked with leading the project, and I take credit for the most important interaction design decisions, right or wrong. I actually consider Skype Chat my most important interaction design work to date of everything that I have done, though I didn’t know what I was doing was called interaction design. We called it just “project management.” I had great help, though, from Kristjan, Priidu, Indrek and other Skype staff, who we spent a lot of time with at the whiteboard, arguing through things.

Here are some of the most important questions and decisions we went through. This is reconstructed from memory, and is all years old, so forgive me for possible occasional misrepresentation, and fix it in comments.

What is the goal?

It was somewhat similar to Wave. We set out to “fix the email problem”, and provide a convenient group collaboration tool that would first and foremost support our own organization of many adhoc groups coming and going, but being fairly limited in size (the first chat size limit was 50 people I think, later boosted to 150). We looked at SMS, IRC, email, Jabber groupchat, Internet chatrooms, and other modes of such communication available at the time.

We were more limited in scope that Wave, though, since we didn’t try to solve the communication and document problems together. What Wave is trying to do is to say that the same “room” can serve as both discussion and document. The jury is still out there whether this works. At Skype, we limited our approach to only consider communication, and not really look at the document/wiki aspect. We figured we’d solve the document aspect by providing a convenient file transfer capability integrated with the chat.

What’s the content model vis-a-vis people coming and going? What happens when you close the window?

This was the most important question to me. Is it synchronous or asynchronous? Is it like email, where you get everything delivered at the time of your choosing? Or is it like IRC, where you only get the stuff that happened while you were connected with your client, and miss out on the rest? (Nevermind that there are now IRC log-bots that capture and share everything, as that is a different experience from actually participating.)

I chose to make chats persistent because that is how teams work in an organization. A team tends to be consistent over time, and it is in the interest of the team that everybody is constantly filled in and knows the same information. So, closing the chat window in the GUI should not disconnect you from the chat. Neither should turning off your computer and later turning it on again; you should still get all the messages. More on this below in “multiple devices.”

If closing a window keeps you in a chat, what does this mean for alerts if you get a new message? How about if you minimized a window? What notifications will you get? I don’t remember all the details, but we spent some time to generate quite an elaborate alert policy. Today, if you look at the alerts/notifications in your Skype preferences, you’ll find all the settings there.

But if closing the window does not take you away from the chat, how do you actually exit one? Or are you stuck in all your chats forever? No, you are not. We just made “leave chat” an explicit user action. There’s a button for it.

Are chats public or invite-only? How do you get in a chat and what do you see then?

I spoke about leaving a chat, but how about getting to a chat in the first place? We made chats private and invite-only. The only way for you to get in a chat was if someone added you to it. That could happen in two ways: either you started a 1:1 chat and expanded it to multiple people later, or you explicitly started a chat with multiple people. I don’t have data, but I’m quite sure that “1:1 first, expand later” is 99.9% of the use.

If you are added to a chat, do you see the whole history or only from that point onwards? I decided that each member sees only what’s posted during the time that they are a member of a chat. Again, this was to support our own use, but it also just feels more natural to eliminate historic cruft. You may be added to a team chat that may be two years old. What they spoke a while back may be irrelevant to you, and they may actively not want you to see it. If it’s important, someone will copypaste you the relevant parts of earlier discussion. I made it this way because it resembles how human groups naturally work.

Note that this is a major difference from Wave. If you are added to a Wave, you see everything from the beginning of times, and can play it back bit for bit, seeing all the edits. I’m not saying it’s wrong, and it definitely has its advantages in their wiki/document model. Time will tell how it works out.

Aside: later, there were public chats in Skype. And even in private chats, there’s a permission scheme so some people can kick others out under some conditions. But I won’t write about it because I’m not sure what’s the status or future of public chats, and the permissions are complex. We borrowed some functions from IRC: type “/help” to see the commands, including permission-related, that are available to you in any Skype chat.

How will multiple devices/computers work?

This was a very interesting question, and we diverged from what most of the popular IM systems did at the time. In client-server-based systems like MSN, AIM, Yahoo Messenger, ICQ etc, only one client per username could be connected at the time. If you connected with AIM from computer A, and then from computer B, computer A got disconnected at the moment you connected from B. I don’t know why that was the common practice in the industry. Maybe it was about message routing complexity, or security, or who knows what.

Skype’s architecture, though, was more complex than simple client-server. Everybody was a client and a server at the same time. What would “one client at a time” even mean? It would have created more problems than it would have solved. So, we realized that what were dealing with was not a messaging problem, but more of a distributed database problem. And through some brilliant engineering by Indrek, we created a system based on “synchronizing”. That is, each device signed in with a particular username has a local database of all chats, and when (re)connected to the Skype network, synchronizes the chats with the “Skype cloud”, posting messages created locally, and retrieves new ones from the cloud.

It sounds complex, and it is. Initially it was quite buggy, but over time, I think it has worked remarkably well. I myself use Skype across multiple devices and overall it works really great. I absolutely think it was the right decision as I could foresee Skype being used across multiple computers and other devices. Extrapolate this approach to the iPhone version and you see what I mean.

I have not looked at Wave protocol guts, but it feels that our design and implementation was/is fairly similar to the gist of Wave federation, except that Wave is more complex, spanning multiple servers, networks and who knows what else. But all in all, you have a collection of waves, and in those, you post messages locally and retrieve remote ones, and it works quite nicely already today, e.g across multiple browsers.

One important thing that Skype and Wave do right, but that’s completely broken in Twitter, is the distribution of metadata, and in particular read/unread states. In Skype, we synchronize not only message content, but also the read/unread state, and Wave does the same. But in Twitter, it highly annoys me that there is no facility to synchronize read/unread state, and I have to read the same tweets ten times across different clients and devices.

Interestingly, email can work using both models. The “old MSN/AIM etc” is POP3 where content is downloaded to client and deleted from cloud, and the new Skype/Wave model is IMAP. (Though these days, probably very few people use POP3 or realize the difference.)

So there; that’s some of the thinking that went into Skype Chat that continues to serve the global Skype community. I’m extremely proud of it and as I said, it’s one of my most important works to date. I don’t know what’s next for it; I do know that Skype’s “conversations” pitch that they practiced around Windows version 4 has much of the same goals that Wave tries to achieve, with perhaps voice and video other added goodies. We’ll see what comes next.

Two previous players on the market were iRise and Axure, but I didn’t need it so much that I would have cared to invest in them. But recently Microsoft and Adobe have entered this market with Expression Blend and Flash Catalyst.

I have used Flash Catalyst to build a medium-complexity prototype, but I can’t post it here, sorry, proprietary. But I did do a very simple example project which illustrates why I like FC more. I made a very dumb project in both: an application that has two views. And in the first view, there is a button; click the button, and a transition happens to the second view. As simple as can be, but plenty to get your feet wet in the tool.

Here are the screenshots of developing this application in Expression Blend/Sketchflow, and Flash Catalyst.

My first reaction to the EB view was “whoa, what exploded here?” Look at all these controls. I am sure they are all useful and necessary, but all these controls feel like I had accidentally detonated something and they just flew all over the screen. Somewhat difficult to get around. See also Brandon Walkin from a while ago about managing complexity, especially the “Alignment & Visual Hierarchy” section.

Flash Catalyst feels much more welcoming. Granted, some of the functions don’t work that well since the product is not even out of beta yet; for example, text engine needs improvements (although it has got better in beta 2, compared to beta 1). But even with all these missing things, I feel much more welcome in Catalyst. It is a more focused tool and I feel it is easy to get around.

This is definitely unscientific and biased. I have used Adobe tools much more than Microsoft Expression, so maybe I am just used to them. And I do not know how well these tools fare for complex prototypes; it may very well be that EB can handle complex things better. This is just my first run impression.

Not a big fan of standing in line, so I went across the street to kill a few hours by seeing a movie instead. (“2012.” Don’t go. Terrible.) Came back, the line was gone, got in. Crowded, but shoppable.

I really like the first floor. It’s unusually high for a retail place. Feels more like an art gallery or something. You don’t see the ceiling on these pics.

From the outside, it’s less impressive than 5th Ave, no cube or such. But the inside is really quite something.

Lower floor is blah, simple Apple shopping, same as other stores.

More pictures.

The old design was just about two years old now. I needed a refreshment, and some parts were just plain ugly. There was also too much clutter in the sidebar. Many thanks to Priidu who helped me with some ideas and nudging along the way.

Content changes

Along with the new layout, I also published information about two projects that haven’t been out there yet.

First, Skype group chat. I take credit for largely designing its behavior in 2004, just about five years ago. I didn’t know at the time that I was doing interaction design, but that’s exactly what it was. It was interesting to revisit this experience, in light of Google Wave and all these new things. As an example, we did an interface where elements appear and disappear based on mouse hover. I see the same behavior in iTunes 9 for song preview playing. I’m not saying there is a connection between the two, but it’s interesting to see how such interface concepts mature and evolve across products.

Comments

One thing that also changed is the comment system on this site. I am now using Disqus instead of Movable Type built in features. THey have better features, and my own comments were a pain to maintain well. The old comments may or may not be migrated.

Comment system switching illustrate the evolution of identity and content on the Internet for me. On one hand, you could argue that anything that’s been put up should remain there forever. On the other hand, things have a lifecycle. They are born, they live, and they die. I don’t have an expectation that my comments will be up there forever, and neither do I guarantee anything to you if you are posting on my site. It may remain, or it may not.

Disappearing content? Or even disappearing identities? It used to sound terrible to me until I saw danah boyd’s writeup on teen IM identities. Can’t locate the exact post, but her point was that whereas adult identities in the form of IM, email addresses etc tend to be fairly stable, some teenagers tend to often switch to new identities on IM systems and just completely abandon the old ones, and that’s perfectly normal for them.

Commenting should now be much more convenient here than it used to be. You can do it anonymously or reuse any of your existing identities. Leave me a note if you find something broken.

… there’s no way you’re going to have games where the input is a little five-button Apple Remote, or anything else connected by IR.

Apple already has a great gaming controller. It is called iPhone. Granted, the hardware is not as spectacular as Xbox and PS3 controllers with vibration, analog thumbsticks etc, but there is something to be said about the benefits of having a full reconfigurable touch surface for gaming. Imagine games with pinch and other multitouch gestures. I have played many games on the iPhone and it really exceeds my expectations as a gaming platform. You should not dismiss touch-based gaming until you’ve tried. I recommend Assassin’s Creed, but why not also Flight Control and other such staples.

So, let’s imagine that we use iPhone as controller for games that you buy on iTunes and push to your Apple TV. I can’t see anything broken with this model. It would just need one “controller app” for iPhone, that could be game-specific or generic, maybe to the point of expanding the already existing Remote app.

Let’s also push this further and imagine games that work on Apple TV as well as iPhone; games that keep you immersed regardless of your environment. Until now, most games are bound to a platform, but you can imagine a rich experience like Sims where the story continues on your TV when you are home, and iPhone when you are on the move. Obviously the content and angle need to be a bit different due to screen size, direct vs indirect manipulation etc, but again, there’s something worthwhile in this model.

With the later example, you wouldn’t even need a new app store. You could keep buying games on your iPhone as you do today, and some of those could simply be expanded if you have an Apple TV.

I can identify with the problem; I have 7 screens worth of apps and I page through them constantly. But I think the solutions proposed in the above two posts are too complicated, and I agree with Fred about why Tog’s #1-#3 solutions are not good.

My solution is very simple, and is around containers. We simply need containers for apps. I don’t know if they are “folders” or “playlists” or “groups”, well, let’s call them “groups” for now. iPhone tries very hard to hide the file system from the user, even though they have a complete one inside. But Apple has many groups all around the iPhone and OS X that I would call “domain-specific containers”. These would be playlists in iTunes, Events etc in iPhoto, Groups in iCal… i.e not general-purpose folders, but hierarchies for the purpose of organizing items in a particular domain. iPhone App groups fit here well.

On the left, you see a regular iPhone view. On the right is what you see when you tap on a Group.

You’ll see that the four über-apps have disappeared. This is because when you are already in the context of a group, you don’t care about those; you only care about this group.

Why is this a superior solution?

It keeps everything about the Springboard that we already have. You still have pages, you move apps around exactly the same way, you can still search for them, you still have the four “über-apps” that are always visible etc.

Unlike Fred’s and Tog’s solutions that require a computer to manage them, these groups are fully manageable on the go without a computer. This is important, since I know many people (and also myself) who don’t connect the phone to the computer for an extended period of time.

Furthermore, managing apps is something that you do when you get the urge. Apple recognized that buying apps also falls in this category, which is why they let you buy, delete and do everything with the apps on the phone without a computer. So you have a bunch of apps and you look at them on your phone and suddenly decide “hmm, I would like these three to be in a group”. Being able to do it right then and there is superior to having to remember (or rather, forget) this for a later time when you have access to a computer.

The group interface is not limited to 16 apps. Similarly to Documents and Downloads stacks on OS X dock, it can change its appearance based on the number of apps: if it’s greater than 16, switch to table/list view, where the amount of apps can be endless with live filtering. (Another option: keep the magic number at 12, and keep the four über-apps in the bottom.)

Scenarios

Here are the things you can do.

Moving an app to group. Just tap and hold like today, until you see apps and groups wiggle. Drag and drop an app on to a group. It goes there.

Moving an app to parent group/back to master springboard. Tap and hold on an app while looking at a group, and either just drop it in the “Back” button; or, the “wiggle” version of Back button could be something that is more obviously a (bigger) drop target.

Moving groups around. Fully same as apps today. Put them onto the “quick launch” zone if there is room etc.

Creating subgroups. I don’t see it as necessary. But all the above scales for nested groups as well. Apple does not have playlists within playlists, events within events etc for a reason.

Deleting a group. Just tap and hold for “wiggle mode”, hit the X icon in the corner of the group, and tap it. And then see some explosion animation that removes the groups and explodes the apps back to springboard.

Move many apps to a group. See above; if you put more than X apps in a group, the group stops looking like a mini-Springboard and instead switches to table/list view. (Or, maybe a group can have multiple pages in it.)

Creating shortcuts, one app in multiple groups. This is Tog’s #5. On one hand, shortcuts are too abstract on a filesystem level; on the other, they seem to work in domain-specific groups (iTunes playlists, iPhoto albums). I can’t think of a good way to manage this on the device, but surely you can do it in iTunes, similarly to playlists.

Creating a group

The only thing missing from the above is, how do you actually create a group? (Leaving aside iTunes on computer where you could do it in many ways, let’s focus only on the device for now.) Well, let’s say you are looking at an empty space on your Springboard where you’d like to see a group. So, you just tap and hold (which currently does nothing on empty space) and you get an interface for naming a group, and you name it, and voila, you have it.

If Apple wants to do multiple things with this gesture, they could introduce indirection through choices. I.e

1. tap and hold on empty space
2. select “Create Group” from among the options
3. Name group
4. Done.

Now this week, I needed to do the same. I went to my local branch and was again turned away. I insisted that I want to use their paper form because I am sick of nonworking systems, and I had seen the system not working before. But the representative told me that the system had been fixed since I last tried, and I should give it a shot. And in case I had problems, I should call the online support and they had a “dedicated team” on standby for international wire problems.

This was quite annoying. I am already at the office, and you are a human being. Why do you force me to go away and try a system which may or may not work, and then navigate your stupid phone system (which has a billion numbers to begin with, I don’t know which one I should call in the first place) and sit on hold for a long time to reach some person who probably isn’t empowered to do anything anyway?

Turns out this is forbidden. Computers are only for staff. Which to me translates to a missed opportunity. If you are trying so hard to market online banking, why not set up a computer at your branches so people could come and give it a shot right then and there, and get some basic assistance? You have computers already, setting up another one does not cost anything. And having your staff instruct people in online banking could translate to many customers turning to it.

Many people are less tech-savvy than me and would really appreciate this small push, instead of being driven away from the branch with a bunch of paper instructions in their hand and being forced to face online banking the first time for themselves.

Estonian banks are similarly big on Internet banking, but they get this right. At each bank branch in Estonia, no matter which brand, there is at least one computer set up for customer use. And if you are new to online banking, the staff is always willing to walk you through it, so that you are more confident when you leave the branch and can then use it on your own.

The wire transfer system had been fixed and did indeed work when I tried it later on my own. But it would have been nice to try it out right then and there at the branch, so I wouldn’t have left the branch and the staff in an annoyed state of mind.

One of my favorite Master’s professors, Bonnie John, said:

If there’s one thing you want to take away from your main course and your whole education, then it’s this: THE USER IS NOT LIKE ME.

In other words (my paraphrase): the designer is an impartial bystander who has no personal stake in the product. Their job is to study the user, their needs and their desires, and then make design decisions based on what they witnessed, while still standing aside.

For Apple, I refer to the Steve Jobs interview in Fortune:

We did iTunes because we all love music. We made what we thought was the best jukebox in iTunes. Then we all wanted to carry our whole music libraries around with us. The team worked really hard. And the reason that they worked so hard is because we all wanted one. You know? I mean, the first few hundred customers were us. … We figure out what we want. And I think we’re pretty good at having the right discipline to think through whether a lot of other people are going to want it, too.

Now, I am sure that this is a sugar-coated version of what happens in practice. I have been in big software organizations and I KNOW that reality is more complex than that. But the complexity is just details. The above is still the guiding force.

As for Linux, I refer to ESR’s famous The Cathedral and The Bazaar:

Every good work of software starts by scratching a developer’s personal itch.

See what I mean? I will make a rough cut and say that Apple people develop frontend and Linux folks develop backend. But what unites them is that they both have a personal vested interest that the software succeeds, because they personally care about it. Which is opposed to the view of “professional designer” and “the user is not like me”.

In many Apple job ads, you need to show that not only are you good at design, but that you also have the domain knowledge. In other words, if you want to design Pro Music apps, you must actually know a thing or two about music and be able to play an instrument.

Can a designer make good design decisions and build a brilliant product design if they are not the users? And approach it purely at a professional level, vs being the target group and having a vested interest? I think the best products are still built if you have a personal vested interest and you care. The rest is “industrial”: industry-standard and boring.

What do you think?