This is a set of guidelines to produce a good mobile client. They are drawn from the experience of building Buddycloud on the Symbian, but should apply equally to other platforms.
Overview
Not "friends and chat"
Buddycloud uses XMPP as a protocol. XMPP is also used by lots of chatting applications. Buddycloud is not a chat application - there are enough IM clients. Buddycloud is about "social location" enabling content in "channels".
Chat type functionality should always be secondary to the channel and place operations.
Always on
The software design of the client should be efficient enough to run in the background and not kill a users battery. Broadcasting your location to your friends becomes much more powerful the longer your application can keep doing it in the background.
Find a happy medium of data input
Buddycloud is a service with mobile and web clients. Consider Buddycloud as an application that plugs into the greater "cloud" of Buddycloud enabled devices. Try to keep in mind that the user's experience of the service is dependent on what your application sends in. Sending too much and the service degrades for others, sending too little and your end-user is not accurately represented. For example, sending location updates every two seconds wastes a resource locally, on the network, and on other Buddycloud clients. We've found a good update interval to be around the two minute mark.
GPS sucks
Buddycloud is designed to work without firing up a battery-sucking GPS, together with the network overhead associated with aGPS's downloading the ephemeral tables for the satellite's positions. Remember that Buddycloud works by placing you at names patterns like "Home" and in broad locations like "Soho, London". For this just cell-id and WiFi is more than enough to accurately place the user back at their placemark. If you really want to use GPS or the device that you are designing for has a very power efficient GPS, then by all means fire it up and send in GPS beacons too. Or even just fire it up when the "motion state" changes to "restless" or "moving".
Network
Reconnect Nicely
It's a rough world out there for the lowly XMPP packet trying to navigate the bitpipes. Running a stable internet connection on a mobile device is tricky: going through a tunnel could cause a connection to drop, mobile networks sometime don't hand-over smoothly between cells and network operators send keep-alive packets on your behalf. A good Buddycloud client will handle this well, detecting when the connection is down and reconnecting and resending data. The Buddycloud Symbian client waits for 90s of silence before doing an XMPP ping to determine that there's still a valid connection and socket. We have found this to be a good medium between excessive keepalive attempts and sending packets into a no longer existent network socket.
Compression reduces XML to 10%
we see that considerable time and network capacity savings can be achieved if compression is used; further it is evident that also energy is saved during transmission, because the transmission time is shorter and the energy consumption does not depend on the content. With zlib based compression on the XML stream, content is coming in at around 10% of the uncompressed size. More details are posted in the Usenix mobile forum.
User interface
Sort Nicely
Make life easy for the end user - sort by by unread private messages, unread channel messages, then by activity. That way "interesting" people and channels are at the top of the list and the user scrolls less.
Bubble Nicely
When a user changes place, sends you a message or updates their status, they should bubble to the top of your followers list and then be "sorted nicely".
Don't duplicate functionality/do things in one place on the client.
Try to keep operations just accessible from one place on the application. For example, inviting a user to a channel could be done from the channel or from the user but shouldn't be done from both.
Lists of lists
Everything is a list. Lists of people, places, channels, messages. Some lists have a special item at the top. In the case of the following screen, it's you. In the case of the Places screen it's your current place. Try to visually distinguish this user form the rest of the list.
Mom's don't know how to set preferences
We love our mothers. For their sake choose sensible default options. Better to design a client well so that preferences and complexity are minimised. For example on Buddycloud followers are always sorted by activity with messages "bubbling" to the top of the list.
Explore don't search
People are in a relatively passive mode when using a phone. They like to browse and click. Search boxes are the antithesis of this and present the user with a big interrupt: They must start typing data into a search box. "What data?" "with or without spaces?" "incremental lookup or not?" "what happens if there are 0 results?". Far better to have channels, people and places scrollable and easily accessible.
Make safe places (the mobile equivalent of hitting the ESC key)
User explore people and places. Sometimes they just want to get back to a safe place. Always have the "back" button take the user to a safe known screen like the "Following" screen.
Show the user how their friends see them
You will notice that the current client shows the user at the top of the list of friends. This let's them see how they appear to their followers. It's a small visual clue and encourages updating.
Differentiate user from others in list
Because the user is shown along with their friends, it's important to differentiate them from the rest of their followers. Provide a small visual clue, a different shade or a line separating them from their friends.
Provide a "big red stop button"
Buddycloud provides an easy way to leave the service. Make it easy for a user who was expecting something different to easily leave. Use the API call that removes all their account and place data.