Today, I am pleased to announce that Chinese artist, political prisoner, and sower of porcelain sunflower seed, Ai Weiwei uses dabr!

On last night’s Newsnight, as part of a package on Ai Weiwei’s release, they showed him using Twitter. Here’s a screenshot.

Click for larger image

One interesting thing, none of the user’s avatars appear. That’s because, at a guess, the images are retrieved from Twitter’s servers which are blocked by the Great Firewall of China.

Indeed, if we zoom in on the text we can see the letters “GFW”.

My Mandarin is too rusty to translate the rest – can anyone else help?

So, looks like my next addition to Dabr will be to use an image proxy to ensure avatar images make it through China’s firewall!

Thanks to Kristian Carter for alerting me.

Ai Weiwei uses @dabr! #Newsnight

22/06/2011 22:15 via Twitter for BlackBerry®ReplyRetweetFavorite

@Kristiansblog

Kristian Carter

Awesome!

Rather than using an external service like Embed.ly to retrieve thumbnails, all the data is embedded within Twitter Entities.

So, if you request a status using “include_entities=true“, you will be able to grab the image and display the thumbnail using the following code.

So, a tweet like this:

#Photos on Twitter: taking flight http://t.co/qbJx26r

02/06/2011 18:53 via webReplyRetweetFavorite

@twitter

Twitter

Notes

This is very rough and ready proof of concept code. Beware of the following:

• This will only take the first image from the tweet.
• Only images are supported – I’m not sure how their proposed video sharing will work.
• There’s no error checking.
• In the above code, the https URL is used – if you want a non-SSL link, you’ll need to remove the “_https”

Enjoy!

Dabr’s strength for developers is two-fold

1. Dead easy to install. Unzip the files, fill in your API key(s), upload, done.
2. It’s under an incredibly permissive Open Source MIT License. Essentially anyone can do anything with the code and they don’t need to ask permission, nor contribute anything back to the code base.

It’s a really popular tool. Although it’s hard to count how many users are on the main Dabr server – not to mention all the clones – it’s obvious that many people find it an indispensable way to access Twitter.

According to the New York Times, Rafinha Bastos is the most influential person on Twitter. Guess what client he uses?


So, with a kick-arse product and no silly “Intellectual Property” restrictions, we have let a thousand flowers bloom. There are clients deployed all over the world. Including on my secure server – SSL Dabr. And here’s one more…

Welcome UberSocial!

The most recent flower is UberSocial. As well as having the most popular BlackBerry Twitter client, and an iPhone client – they’ve now beta-launched a mobile web client – based on Dabr!

I’m really excited to see Dabr spreading far and wide. The intention – for me – has never been to make pots of money from it. The adverts on SSL Dabr just about cover the hosting costs.

What I like seeing is my code being used far and wide – and helping people. I know it’s corny, but seeing my code being used by Twitter users in Egypt during the uprising was overwhelming. In a tiny, almost insignificant way, I helped.

I don’t think my coding is good enough to get something into a really important project – like the Linux Kernel, or the International Space Station – but seeing millions of users is personally edifying.

So, long live Open Source and long live Dabr!

So, how do we go from http://4sq.com/fgIWov
to
?

1 Expand the URL

Get your Bit.ly API Key.

http://api.bitly.com/v3/expand

   ?shortUrl=http://4sq.com/fgIWov
   &login=YOUR_BIT_LY_USERNAME
   &apiKey=YOUR_BIT_LY_API_KEY
   &format=txt

You can, if you prefer, get the info back in JSON or XML. See the Bit.ly API Expand Documentation.

2 The Foursquare URL

Bit.ly gives us the URL which includes a checkin ID and a signature.

http://foursquare.com/edent/checkin/4d7e5b4f9df3f04d7400c394

   ?s=afH3jJg3L9HpLqVIwiqp-YpNL5k

3 The Foursquare API Call

From this, we construct an API call to Foursquare. It looks like this

https://api.foursquare.com/v2/checkins/4d7e5b4f9df3f04d7400c394

   ?signature=afH3jJg3L9HpLqVIwiqp-YpNL5k
   &oauth_token=YOUR_FOURSQUARE_OAUTH_TOKEN

NOTE the Foursquare URL says ?s= whereas the API call requires ?signature=
That caused me more frustration than it should…

Getting your OAuth token is a little cumbersome – follow the steps at the Foursquare Developers site.

4 The JSON Response

I’ll cut the cruft out of here, so you only see what you need to display images.
The response gives us the link to the full sized image – as well as several different sizes should you wish to display thumbnails.

5 Gotchas

Again, nothing in life is easy. Not all foursquare checkins have an image associated with them. In which case, we can do one of three things.

1. Display no image
2. Display the user’s avatar – if it’s public
3. Display an image of the venue – or one of the icons associated with it.

6 Embed.ly

Dabr uses the awesome Embedly service. Rather than having hundreds of different regular expressions and API calls to get embedded images, Embed.ly gives us a single end point to call.
So, rather than rewrite huge chunks of Dabr’s code, I’ve submitted this to the clever-clogs behind Embed.ly – that way, everyone can benefit.

Any questions, comments, or clarifications – please let me know in the comments box.

Pagination is the act of splitting data into logical  pages. Suppose I had a list of item, numbered 0 – 99.  If I want 20 items per page, it’s trivial to see that pagination looks like:

p1 = 0-19
p2 = 20-40
p3 = 41-61
p4 = 62-82
p5 = 83-99

If I wanted to start at, say, page 55 – pagination would look like:

p1 = 55-75
p2 = 76-96
p3 = 97-99

Easy, right?  So why am I telling you this?

Twitter Timeline

Imagine that those items are Twitter Status ID.  Each one represents a tweet in your timeline.

Twitter will allow us to “page” back and forth through our timeline. If we say status ID 80 is the most recent post in our timeline, and we want to see 20 tweets at a time, pagination would look like this.

p1 = 80-60
p2 = 60-40
... etc.

Normally, that would be fine.

The only issue is that friends are posting all the time.  Imagine we start with tweets 80-60.  We go to page 2, but in the meantime, 5 new tweets have been made.

p1 = 80-60
p2 = 65-45

The user sees 5 tweets she has already read.  Not desirable.

If 20 tweets had been made before clicking on the “next” button, this is what happens.

p1 = 80-60
p2 = 80-60

Max_ID To The Rescue (AKA, the easy bit)

Luckily, Twitter allows us to use a max_id parameter in our API calls.  This says “Get the tweets older than this number.”

http://api.twitter.com/1/statuses/home_timeline.json?max_id=123465789

So, using max_id we can ensure that the user never has to read the same tweet twice.  Instead of dumbly using pages, we call the specific tweets we want.

p1 max_id=80 = 80-60

p2 max_id=60 = 60-40

Easy!  We just use the oldest tweet on the page as the max_id parameter when we call the next page.

Looking To The Future (AKA, where it all goes horribly wrong)

So far, we’ve looked at stepping back in time.  Seeing older tweets.  Suppose we want to see newer tweets?

Twitter provides us with a since_id parameter for API calls.  This says “Get the tweets newer than this number.”

Unfortunately, it doesn’t work.  Well, it works but not the way I expected it to!

Suppose our user is deep down in her tweets, this is how I would expect since_id to work

max_id=60  = 60-40

 (So, let's show any more recent tweets)

since_id=60 = 80-60

We see the 20 tweets that occured since the since_id.  Right?  Wrong!  This is what happens?

max_id=60  = 60-40

(So, let's show any more recent tweets)

since_id=60 = 100-80

What?

An Explanation

The since_id retrieves tweets starting with the most recent.  It stops when it reaches the since_id.

I don’t know the max_id that I’m looking for, so I can’t call that.

I could call the most recent 200 tweets and look for the 20 I need.  That’s wasteful in terms of bandwidth and processing – there’s also no guarantee that the since_id will be in there.

So, I have a problem.  The “Older” link in my Twitter application will work.  The “Newer” links won’t.

Any suggestions?

You can see the full code on Dabr’s Google Code page.

First of all, you’ll need to have enabled OAuth for your Twitter client. I use Abraham’s excellent OAuth libraries for PHP.

This tutorial assumes you already have OAuth working. I’ll attempt to explain what I’m doing as I go along – but the code should be pretty readable.

Start by reading the Twitpic API documentation. You will also need to register for an API key – this only takes a few seconds.

We start by setting CURL’s headers to those required by Twitpic

Next, we create the OAuth credentials that we need. Essentially, we’re signing a URL request. We then pass that on to Twitpic and they verify it with Twitter. We never pass our OAUTH_CONSUMER_SECRET – so Twitpic can’t impersonate us.

We add these generated credentials into the header.

Add everything into CURL

The data we send to Twitpic (message text, image and key) have to go via POST.

All done, we now send the data to Twitpic.

If this has worked, Twitpic will pass back the URL of the image we posted. We then need to post the entire message to Twitter ourselves (Twitpic can’t do it for us).

This next part is specific to Dabr – your client may post things differently.

If it didn’t work, Twitpic will tell us why.

One of the advantages of the text processing is that it will recognise that www.example.com is a URL and automatically create a hyperlink. Considering that dropping the “http://” represents 5% saving on Twitter’s 140 character limit for messages, this is great.

So, I was mightily surprised to get this bug report from user “schmmuck”

Dabr rendering error

How very odd… This is how it looks on m.twitter.com.

m.twitter rendering error

Twitter also use mobile.twitter.com for smartphones. Here’s how that site renders the text.

mobile.twitter rendering error

Finally, let’s take a look at the “canonical” rendering at Twitter.com

Twitter rendering error

The Problem(s)

The first issue is inconsistency.  Twitter ought to be using the same regex for each of its sites.  It doesn’t.  This means that different developers will get divergent experiences.  This leads to confusion, which leads to fear, which, as we all know, leads to anger…. and so forth.

Secondly, and more importantly, parsing is hard.  There are so many edge cases that errors inevitably creep in.  My post about hashtags explains the problems in defining what should be recognised.

So, based on what we’ve seen, should Twitter recognise any of the following as URLs?

news.bbc.co.uk – no www there.

invalid.name – a silly URL, but a valid one.

खोज.com – International domains contain more than just ASCII

All the above are valid – yet they’re not recognised by Twitter.

A (Simple) Solution?

There is a canonical list of TLDs which is also available as a plain text list.

Any string containing a “.” followed by a valid TLD, then followed by a space or “/” should be treated as a URL.

Your thoughts?

@@ and geotag

Reply to All

The @@ symbol allows you to reply to all the people mentioned within the tweet.
It only shows up on tweets which mention other users – so you should only ever see it when it can be used.

Hitting @@ on the above tweet will pre-populate the text box with “@topgold @whatleydude @dabr”.

It should remove any duplicates and should also remove your username.

Geotagging

Twitter recently allowed the geotagging of tweets. This allows you to set the longitude and latitude of where you are when you wrote your message.
Clicking on the green globe (it just looks like a dot at that size!) takes you to a mobile mapping service.

Google Maps Mobile

It only shows up on tweets which are geotagged – so you should only ever see it when it can be used.

How Does It Work?

You can see all the code in the SVN, but here’s a quick rundown.

Geotagging is very simple.  Statuses now have a <geo> field.  If this is populated, it will contain a longitude and latitude.

We can take those values and pass them to Google Maps Mobile (or your favourite mobile mapping service).
if ($geo !== null)
{
   $latlong = $geo->coordinates;
   $lat = $latlong[0];
   $long = $latlong[1];
   $actions[] = theme('action_icon', "http://maps.google.co.uk/m?q={$lat},{$long}", 'images/map.png', 'MAP');
}

Reply to all is a little more involved.
Twitter provide an excellent set of Text Libraries. These provide officially sanctioned regular expressions to help your project find URLs, hashtags and usernames.

Using the Twitter Text Extractor class we can determine how many usernames are mentioned in a tweet. Any duplicates are removed – as is the user’s username.

Any questions – just ask!

This sort of knowledge is common in life – but is fatal in computing and design. Take the following tweet I received.

Mawkins

(Mark Hawkins)

@edent @dabr you folks aware ampersands / &s don't seem to work as part of hashtag links?

On 24-2-2010 16:27:19 from TweetDeck in reply to Terence Eden

The complaint was that #tfm&a should be rendered as #tfm&a not #tfm&a.

Everyone knows that’s how hashtags work!

On Twitter’s website, find the page which discusses hashtag syntax. Find where they explain how they should be styled.

You can’t.

And thus implicit knowledge is born. Dabr only looks at letters and numbers in a hashtag. It assumes that any other character is the end of the tag.

Dabr's Hashtag

Without official guidance – implicit knowledge develops.

Has Dabr Got It Wrong?

No. I don’t think so. Take a look at how Twitter on the web renders hashtags…

Twitter's Web Site

…and on the mobile.

Twitter Mobile

So Where Does Render The Full Tag?

Several applications don’t render tags in the same way as Twitter. Take a look at SocialScope

SocialScope Hashtags

Tweetie2

I’ll upload more screenshots if I find examples of “badly behaved” hashtags.  Please let me know if you find any.

What Does Twitter Say?

Twitter has one page devoted to hashtags.  It is a support page for hashtags.  This explains to people what hashtags are.  There’s no detail on valid characters, maximum length, or any of the things which might be useful for a developer or designer.

Edit 2010-02-25

David Dorward has pointed out that there is an official resource. On the Twitter Engineering blog – which isn’t linked to from the developer site – there is a page discussing hashtags and how to validate them. You’ll notice that they are rather circumspect on what should constitute a hashtag.

Conclusion

Standards and guidelines allow developers to create compatible applications.

Without explicit recommendations, developers will diverge as widely as possible.  Twitter – and everyone with an interest in compatibility and usability – needs to ensure that the knowledge they impart is explicit.

Letting people make it up as they go along leads to confusion.

It’s one of my gripes with Linux.  If you’re editing a configuration file, you are relying on yourself to sanity check your input – often without knowing what the limits are.

Take these two different examples.

In a text file, we might have:

#Maximum Widgets to fidget
maxW_to-F = 0

Whereas a GUI would show

How many Widgets do you want to fidget?
1235

Even if you don’t know the rules behind Widget fidgetting (must be a prime number lower than 7), the GUI won’t let you choose a value that you can’t select. The GUI doesn’t prevent you setting an innapropriate value – just an illegal one. Your config file, however, could be set to any crazy value that a user type – often resulting in “unpredictable” results.

#Maximum Widgets to fidget
maxW_to-F = seventeen

It’s with this in mind that I’ve made the following change to Dabr – the mobile Twitter client.

To Auth or Not To Auth? That Is The Question

Twitter’s API has bug / peculiarity (reported to their discussion board) which causes Dabr to log a user out. Let me explain the steps

• User 1 (@private) has set her tweets to “protected”.
• This means no one can see @private’s tweet unless she allows them.
• @private has not allowed User 2 (@edent) to view her tweets.  She is protect from his view.
• @edent clicks to view @private’s profile.
• @edent can see that @private has 42 friends, 17 followers and 3 favourites.

So far, this is the same behaviour on Twitter’s website as it is through their API.  Here’s the difference

Web

• @edent tries to see @private’s followers and can see their names, profile pictures etc.
• @edent can also see @private’s friends
• @edent cannot see @private’s favourites (or even how many favourites she has)

API

• @edent tries to see @private’s followers, friends or favourites
• Because @edent isn’t allowed to see @private’s info, the API returns 401 Authorisation Required.

This is where things get tricky. Dabr sees the 401 and concludes that the user has invalid credentials.  It then, as a security measure, clears the user’s cookie and logs them out.

This may be a little harsh, but HTTP 401 essentially says that the authorisation has failed.

Fixing It

There are 3 ways that this could be fixed

1. Twitter could rationalise the API to allow access to the same content that a web user gets.
2. Twitter could return a different status code.
3. Dabr needs fixing.

So, how do we get Dabr not to log out when it receives a 401 only under these specific circumstances?

Looking at the code, we can see that Dabr simply sees the HTTP response code.  To fix it we’ll need to pass extra parameters, check where the code was called from, investigate all the edge cases, add more logic to the system, futz around breaking things, etc… etc…

What a pain in the…

Or

Don’t let users do things they can’t do.

If a user can’t see the information – why do we even let them try to see the information?  Why can’t we just get rid of the link?

This is what a user currently sees:

Old Style

We’ve established that they can’t view followers, friends and favourites.  So we can get rid of those links (but not the information).

New Style

(Incidentally, I’ve changed the order of the links.  I’ve tried to group together similar items.  Followers, friends, favourites and lists go together. Then DM. Finally, follow, block, report spam.)

Now a user cannot click through to an unwanted error message.

Or

There is another way round this.  With “Direct Messages” we could do the same thing – simply remove the link if you’re not able to send that user a DM.

Instead, we’ve taken the approach of displaying a suitable error message.

Direct Message Warning

The advantage of this is that the user gets an explanation as to why they are unable to complete an action.

Your Thought?

Which do you prefer? Being unable to click on a link (with no explanation) or clicking on a link only to be given a warning message?

This was a problem I faced when trying to get Dabr to render the ASCII* art produced by Aral Balkan‘s Feathers App. Feathers uses line breaks to achieve images like…

〰❀❃ Introducing ❃❀〰
My new iPhone app,
░░░▒█ Feathers █▒░░░

What’s confusing to me, as a developer is the inconsistent way Twitter handles line breaks. For example…

Twitter’s website ignores line breaks.

Desktop Spacing

Twitter Mobile, however, does line breaking correctly.

Android Spacing

Twitter has no style guide for rendering and – if it did – appears to render inconsistently. So, what’s the correct thing to do?

In my opinion, respect the user. If a user has indicted that they want something, it is a developer’s role to implement it (unless it causes severe problems for the system).

How to achieve it?

You could use all sorts of complex regular expressions to get line breaks and convert them.
Thankfully, PHP has this function built in with nl2br() which will give you (X)HTML line breaks wherever a break occurs in the text.

Footnote

*Technically, Unicode Art. But that doesn’t have the same ring to it.

Usually, I would be a big fan of this move – especially if it forces password anti-pattern sites like TwitPic to implement the new, secure standard.

This means that you won’t be able to log in to a third party site by giving them your username and  password.  You will have to use OAuth to securely validate with the main Twitter site.

But – as ever – there’s a dark side to OAuth.

Repressive Regimes

One of the joys of Twitter is that its clients are decentralised from the main site.

This means that if Twitter is blocked in your country, you can use a third party client (like Dabr) to access it.

Twitter User -> Dabr -> Twitter API -> Dabr -> User

If Dabr became sufficiently popular to be blocked by an oppressive regime, you can switch to any one of the thousands of Twitter web clients.

OAuth forces you to the main Twitter site.  While you may visit Dabr to start with, you would be redirected to Twitter to complete OAuth.  If Twitter is blocked, you can’t connect.

At a stroke, Twitter has shut itself off to anyone in a repressive country.

This has been picked up by some concerned users.

A (Hacky) Way Around It

There’s really only one way around this problem.  The third party web client has to act as a man-in-the-middle.  There’s a patch for Dabr – developed by cnyegle – which will ask for a username and password, then proxy it to Twitter, get the OAuth token and tweet on behalf of the user.

From the user’s point of view, they are still giving the (potentially untrusted) site the username and password.

Challenge Response

This could be solved by implemented a challenge / response system.

1. Alice visits the Dabr website.
2. Dabr asks Alice for her username (and only her username)
3. Dabr asks Twitter for the challenge associated with Alice’s username.
4. Twitter checks that Dabr is an authorised website (i.e. has signed up for OAuth).
5. Twitter returns the response:  A secret phrase which Alice has previously chosen.
6. Dabr displays this phrase to Alice.
7. Alice knows that Twitter trusts Dabr
8. Dabr asks Twitter for the password challenge.
9. Twitter returns that it requires the 3rd, 5th and last character from Alice’s password (the characters requested change randomly).
10. Dabr asks Alice for only those characters.
11. If Alice provides the correct characters, an OAuth token is granted to Dabr to tweet on behalf of Alice.

This has the advantage of proving that Dabr is trusted (by displaying Alice’s pre-defined secret phrase) and mitigating the risk that Dabr is untrusted (by only revealing part of the password).

Conclusion

This is a very new area, and I’ve not had a chance to read through all of the proposals.  Nevertheless, it remains a fundamental problem that, if you can’t access a site, you need to delegate your trust to someone else.

I’m not a security expert – so I would appreciate someone pointing out the flaws in my reasoning.

For a service which started out operating by SMS, Twitter takes a surprisingly unenlightened view of mobile. It’s main mobile service – http://m.twitter.com/ – is almost completely devoid of useful features. That’s one of the main impetuses behind the development of Dabr. Their latest mobile site – http://mobile.twitter.com/ – is really only suitable for the tiny minority of people who have smartphones.

So, understandably, many people use 3rd party sites like Dabr. They are now faced with a dilemma – give an untrusted site their username and password or try to use OAuth on the mobile.

A few weeks ago came the announcement that OAuth was finally ready for mobile… Was it? No. Once again a “mobile friendly” site designed with masses of JavaScript and guaranteed not to work with the majority of phones on the market.

Here’s how mobile OAuth looks on a variety of popular mobile phones.

BlackBerry

BlackBerry Twitter OAuth

While this looks pretty enough, it doesn’t work. The buttons aren’t clickable. I’ve tried with and without JavaScript. No matter where I click, nothing happens.

Android

The Android’s User-Agent isn’t detected by Twitter as being a mobile phone. While it’s true that the browser is very capable – the OAuth screen is a lot more usable when it’s in mobile mode.

Android Twitter OAuth

So, it works, but it doesn’t look nice.

N95

The N95 makes a good test phone because it’s popular. Probably more popular than the iPhone.

N95 Twitter OAuth

N95 Twitter OAuth

It’s not pretty – but at least it works.

Others

The Sharp GX-10 is my default test phone. One of the first phones with a colour HTML browser. If your site can work on this phone, it will work on any phone. There are no screenshot capabilities for this phone – but rest assured, it does not work.

The three phones I’ve demo’d above are very popular modern phones – AKA the minority. If they don’t work well, what chance for the people using older phones?

Useless! How hard can it be? All it needs is a username field, a password field and a button. That’s just about the most basic page imaginable. It should be child’s play to make it work on mobile.

This was first raised in March 2009 on Twitter’s issues list. It’s currently the most popular bug.

So, we’re stuck in a dire situation. Third-Party mobile sites get access to Twitter users’ passwords because Twitter are unable or unwilling to develop a simple OAuth form. It would be fascinating to know how many of Twitter’s security breaches are down to corrupt or insecure 3rd party sites which leak passwords.

I’ve tested this to work on the Vodafone 360 H1 – but it should work with any JIL handset.

Because it isn’t certified, you may need to dial

*#35767#

to remove the H1′s security check.

The code is very simple.  The JIL SDK allows you to call specific phone application – in this case, all I’ve done is invoked the browser.

<body>
   <script type="text/javascript">
      Widget.openURL("http://m.dabr.co.uk/");
   </script>
   <div>
      Launching Dabr!
   </div>
</body>

One thing to note, if you’re deploying the widgets from your website, ensure you have set the MIME type to “application/widget” – as per the W3C standards – otherwise many devices won’t recognise it as a valid widget.

If you’re interest in developing for this platform, there’s a €1,000,000 bounty up for grabs.  There’s also a Dev Camp at Mobile World Congress this year.

I work for Vodafone – this is my personal blog, I don’t to speak for them.  All opinions, claims and mistakes are my own.

I’m a big fan of AudioBoo – for those who don’t know it,  AudioBoo allows you to record some audio on your phone and then publish it to the web.  It’s like instant podcasting.  Originally only for the iPhone, AudioBoo now works on Android and there’s an S60 version comeing out “soon”.

I’m very proud to announce that as of r260 – Dabr now support AudioBoo!

It all started with a tweet from David Carrington (creator of Dabr) asking how one would go about linking directly to a tweeted ‘boo.

So – how do I turn a tweeted ‘boo like http://boo.fm/b73803 to the associated MP3 of http://audioboo.fm/boos/73803-rockbandboo.mp3 ?

Bring Me The API!

An API is a way for two computers to talk to each other.  The client (dabr) asks the server (AudioBoo) a question.  The server replies with some data and the client then does something with it.

AudioBoo’s API is a “work in progress” – that’s the polite term for “not quite finished”.
There are various APIs to get information about a ‘boo. However, it’s not particularly intuitive. For example, if I use /audio_clips/

http://api.audioboo.fm/audio_clips/b73803.mp3

I get an error.
I have to drop the b to get

http://api.audioboo.fm/audio_clips/73803.mp3

I asked on the AudioBoo forums if there was a better way but I didn’t get a quick response – so I turned to twitter. One of the top AudioBoo bods, Mark Rock, is an active twitterer (seriously – isn’t there a better word than that?)

markrock

(Mark Rock)

@davidcarrington @edent just updated server so this works - http://boo.fm/b1234.mp3

On 21-12-2009 12:12:59 from TweetDeck in reply to David Carrington

So, now I can link http://boo.fm/b73803 to http://boo.fm/b73803.mp3 – simple. Here’s what it looks like in the browser.

AudioBoo

Phreadz

Phreadz is a service which allows you to post VITAL – Video Images Text Audio Links – it’s a fantastic service, so when Kosso (its founder) asked me to integrate it into Dabr, I was keen to take on the challenge.

The code was quite simple and can be seen in r261. But there was one small complication – image sizes.

The thumbnail images from Phreadz aren’t always suitable for mobiles. If images are too large, it will slow download speeds and potentially cost people money.

So, I used tinysrc.mobi. Tinysrc is a very simple API which will resize any image to a mobile friendly format. It detects the phone’s user-agent string and creates a suitable sized image.

Here’s what it looks like.

Phreadz

Conclusions

I’ve used 4 separate APIs here – twitter, AudioBoo, Phreadz, tinysrc – the joy of Web 2.0 is that all those disparate services can combine to create something new and magical.

API designers often need to think about how their products will be used “in the wild”. It’s very easy to create something that works very well for your requirements – but much harder to think about what others will need.

Getting the client was fairly simple, but could be better. Simply visiting http://seesmic.com was enough to bring up a mobile friendly page with download instructions.

However, scrolling down presented this mess.

You simply can’t rely on users to know what make, model or firmware version they have. Use the user-agent string to do as much of the hard work as possible. If a user tries to install an incompatible version, it won’t work and they’ll blame you.

The download itself is a sprightly 172KB and installs very quickly – it also doesn’t require a reboot.

Once you’ve signed in, the main interface is very simple. UberTwitter, for example, presents the user with complex set-up options on the first run. Seesmic gets straight to the action.

Seesmic is entirely menu driven – there are no shortcut keys. UberTwitter allows me to hit R for reply – on Seesmic, I have to delve into the menus. Luckily, they’re short and have obvious names.

Reading a tweet gives the usual option, hashtags and @s are hyperlinked – as are web addresses.

On usability flaw, the cursor is at the top of the screen. A user has to scroll through the “Web” hyperlink before getting to the links within the tweet.

Again, because there are no keyboard shortcuts, everything has to go through the menu.

Searching is problematic.

Pressing enter doesn’t start a search, it inserts a new line.
The search button isn’t the first thing you get to when you scroll down.
While the results are standard, this odd error message kept popping up.

I encountered this error several times.

Writing new tweet has some great usability touches – and some real clunkers.

The closer a user gets to filling the 140 characters, the more red the screen turns.

URLs can be automatically shortened and images can be added. This shows one of the great usability failures of Seesmic.

Rather than use the BlackBerry’s file select utility, it uses its own – and it’s dreadful. Ugly looking, no ability to search, slow, no preview. Overall, a real let-down.

I don’t know why companies often insist on creating their own versions of well established system functions. Especially when they add nothing and remove plenty.

Sending a tweet was continually problematic for me.

Although it eventually relented.

Seesmic also makes great use of notifies, showing you on your home screen how many unread tweets you have.

Overall, Seesmic isn’t a bad client. There are a few rough-around-the-edges bugs and the file selection is atrocious but other than that, it works. Power users like me will miss the shortcut keys of UberTwitter, and UT’s system-wide integration (uploading photos, capturing hashtags in emails etc.).  It lacks other features such as in-line photos, ability to see followers and friends, it also has no way of marking a tweet as a favourite or seeing favourites.

One feature it does have – a first in mobile twitter clients – is the ability to view lists.  You can’t add, edit or create – but you can see the lists you have created or are following.

Conclusion

Seesmic works well enough as a basic twitter client for BlackBerry – but there’s nothing exciting about it.

The code is fairly simple – although I still suck at regular expressions.

 if (preg_match_all('#youtube\.com\/watch\?v=([_-\d\w]+)#', $tmp, $matches, PREG_PATTERN_ORDER) > 0)
 {
  foreach ($matches[1] as $match)
  {
  $images[] = theme('external_link', "http://m.youtube.com/watch?v={$match}", "<img src='http://i.ytimg.com/vi/{$match}/1.jpg' class='twitpic' />");
  }
 }

Here’s how it looks.  A user writes a tweet which contains a YouTube URL

A thumbnail embedded in a tweet

The thumbnail is displayed and hyperlinked to the mobile version of YouTube

Pointing to Mobile YouTube

When clicked on, the user is taken straight to the video’s page.

The Destination

There were three main issues with this code

1. How do we extract the video’s ID from the URL? YouTube video IDs contain alphanumeric character and the – and _ characters. They can also have other parameters passed.  There can also be text after the URL.  The regular expression above takes care of them.
2. How do we get the thumbnail?  Previously, I had been using the image URL given in the m.YouTube page – something like http://i.ytimg.com/vi/plvE4882B7Y/default.jpg?w=80&h=60 – however those URLs now need signing. So, using the YouTube API, I took a look at the Video Information XML file – http://gdata.youtube.com/feeds/api/videos/plvE4882B7Y – it showed that all videos have a full sized thumbnail – http://i.ytimg.com/vi/plvE4882B7Y/0.jpg and a mobile friendly thumbnail – http://i.ytimg.com/vi/plvE4882B7Y/1.jpg
3. How do we link to the mobile version of YouTube?  There are two ways to do this – either allow YouTube to detect the User-Agent and redirect based on that, or simply point to the mobile version.  While a regular YouTube link looks like http://www.youtube.com/watch?v=plvE4882B7Y the mobile one simply substitutes www for m : http://m.youtube.com/watch?v=plvE4882B7Y

TODO

For phones which support playing YouTube videos inline (Android, some Nokias etc) I may actually embed the video, rather than just link to it.  I may also detect Desktop Browsers and send them to the regular version of YouTube.

So, hurrah for LongURLPlease – a service which takes those horrid little links and turns them in to full sized URLs.

Here’s the basic code in PHP to use the service.

[php]
function long_url($shortURL)
{
//Use the LongURLPlease API
$url = "http://www.longurlplease.com/api/v1.1?q=" . $shortURL;

//Set up CURL
$curl_handle=curl_init();
curl_setopt($curl_handle,CURLOPT_RETURNTRANSFER,1);
curl_setopt($curl_handle,CURLOPT_URL,$url);

//Get the JSON response
$url_json = curl_exec($curl_handle);

//Close the connection
curl_close($curl_handle);

//Decode the JSON
$url_array = json_decode($url_json,true);

//Get the Long URL out of the array
$url_long = $url_array["$shortURL"];

if ($url_long == null) //The service couldn’t find a long URL
{
return $shortURL;
}

return $url_long;
}
[/php]

So, how should this be displayed to the user in Dabr?

There are three possibilities.

Display

[html]<a href="short.url/foo">VeryVeryLong.Url/Bar</a>[/html]

This keeps the redirect, but it displays the full URL for the user.

Pros.

• Get to see what the content is.
• Allows the short URL service to record hits etc.

Cons.

• Won’t highlight if you’ve already visited it.
• May cause problems if the VeryLong.Url is too long for the screen.

All Change

[html]<a href="VeryVeryLong.Url/Bar">VeryVeryLong.Url/Bar</a>[/html]
This completely replaces the short URL.

Pros.

• Hurrah! No more silly URLs.
• Will highlight if you’ve already visited it.
• You can seen what you’re about to click on.

Cons.

• Breaks any statistics management the short URL service was performing (is this a con? Surely the receiving website should be recording such details?)
• May cause problems if the VeryLong.Url is too long for the screen.

Background

[html]<a href="VeryVeryLong.Url/Bar">short.url/foo</a>[/html]

Pros.

• Will highlight if you’ve already visited it.
• You can seen what you’re about to click on if you hover over the URL.
• Won’t cause problems if the URL is too long for the screen.

Cons.

• Breaks any statistics management the short URL service was performing (is this a con? Surely the receiving website should be recording such details?)
• User can’t immediately see what they’re about to click on.

Conclusions

I prefer replacing the URL completely.  I see no value in the various short URL services.  The stats that they gather don’t seem any better that those your webserver can provide.

However, long URLs can be messy – especially on small screened devices.

Long URLs on a BlackBerry

So, which do you prefer?

The Good
Once again, it’s impossible to feel anything other that gratitude and humbleness in the face of the sheer amount of effort, determination and self-sacrifice that goes in to making a “happening” on this scale. Kudos to Amanda, Ben and everyone else who worked so hard.

Getting people all over the world to raise (hopefully) a million bucks for Charity : Water certainly goes on my #Awesome09 list.

As always – it’s the people you meet which make the evening. It’s bizarre trying to recognise someone from a 48*48 pixel avatar – this often means spending a large portion of the time staring at random strangers’ chests trying to read a name-badge.

There’s a myth that in some languages the word “stranger” translates into “Friend I’ve Not Yet Met” – so it is with twitter. I was surrounded with people who I felt I knew intimately, yet I’d never so much as shaken their hand before tonight.

The net result of all this was that everyone was so friendly. Any other venue in London, if you accidentally spilled someone’s drink you’d get stabbed. Here, you were more likely to get a hug.

Which was nice.

The Bad
I’m obviously a grumpy old man – but here’s my run down of what people could do to improve the next London Twestival.

1. I appreciate that there’s a paucity of cheap / free venues in London on a Thursday night. But if you’re going to pick one a mile away from the tube, in some grim back street, it might be an idea to put up a few signs directing people – or even a few volunteers.
2. The queuing system sucked. I don’t know what the hold up was at the front, but it took us around 45 minutes to get in. That certainly put a dampener on my evening.
3. You can’t control the weather – but you can plan for it. If you can see that there’s a long queue of people standing about in the snow – go out and explain to them what’s going on. People are happier when they know why there’s a delay and what’s being done about it.
4. If there’s a long queue of bored and hungry people, bring out some food or (non-alcoholic) drink. I saw lots of organisers wandering past the queue with crates of food. They didn’t even throw so much as a bag of Doritos our way.
5. Twitter is a meritocracy. If you’re the organiser and you spot one of your mates – or a BBC journalist – in the queue, don’t let them jump the queue! It’s the sort of thing which builds resentment.
6. Actually check the tickets. By the time I arrived at the front, the notion of a ticketing system had all but been abandoned. There were funky 2D Barcodes on there which should have speeded up the check-in process.
7. Either pre-print name-badges in big letters, or make sure you have enough thick black markers on the front desk. Loads of people had been reduced to writing their badges in biro. This made it really hard to read who someone was.
8. Have more than 2 people on the coat check. I’m here to part and meet people, not join another queue just to hand over a coat (see point 12)
9. Keep food, drink and raffles in a fixed location. I saw lots of people chasing after the last reported sighting of the raffle tickets and the burgers. If people can’t find you, they can’t give you their money.
10. The food. What a farce. Despite being given a ticket for food, I couldn’t find anywhere to spend it – nor could anyone else. There was a chap wandering around giving burgers away – but he didn’t know where the rest of the food was, or if there was anything vegetarian available. I subsided on a few dropped Liquorish Allsorts. Rubbish.
11. The raffle. Grrr. Possibly the most annoying thing about the night.
• Hard to find raffle tickets
• No validation on the tickets (I saw people dropping both halves of their ticket in and only keeping one stub from the several they purchased.)
• Filling in the tickets took an age. Not sure how this could be improved – certainly give the raffle sellers more pens so that multiple people can fill in tickets at the same time.
• Timing was bad. The website said you had to stick around to claim your prize. A bit unfair given that our names and phone numbers were on there.
• Lousy rules – the website said you had to stick around until “halfway” through the evening” for the draw. I’m obviously an old man because I don’t consider after 2300 to be halfway through the evening. We don’t all work in PR – taking Friday as a hangover day isn’t always an option.
• To make matters worst, the first few prizes were announced – then the raffle was seemingly abandoned! I got bored at this point and left.
• I should point out that I’m probably just bitter that I didn’t win the Lego Death Star…
12. Coat check. When you have “tired and emotional” party goers who just want to catch the last train back home – put more than two people on the coat check. Make sure that the coats are in some sort of order so your coat can be found.
13. The final testament as to why I’m an old man. The music. Don’t get me wrong, I loved the music, but the point of twitter is that it’s a conversation. It’s rather hard to have a conversation when the music drowns out everything.

The Ugly
It would appear that I am genetically unable to be photographed in a flattering light.

Photo by Webwandering.

Photo by Annie Mole.

Photo by Annie Mole.

Although it was very nice of LJRich to interv
iew me for the BBC!

Amazing to see nearly everyone in that video using the fantastic Dabr for tweeting from their phones..

So…
I hope I haven’t upset anyone with this post. I am genuinely in awe of the organisers for getting a global event of the ground and raising a whole heap for charity. I just wish that a bit more logistical effort had gone in to the London Twestival.

TTFN.

This is a quick review of some of the mobile Twitter interfaces and how well they work on the BlackBerry. I’m just looking at mobile web interfaces (for now).

Mobile Twitter

First off – the official mobile Twitter interface – http://m.twitter.com

It’s fairly plain and uninteresting. At the bottom of the screen, we see a few options.

You can even perform basic follow / unfollow activity.

At first glance, it seems ok. Most of the basic functionality is there. If all you want to do is read your stream and post – it’s fine.

But! Thanks to the Twitter API, there are a plethora of different interfaces.

Slandr

Let’s look at Slandr.

Wow! Straight away we can see the difference. Avatars are displayed – as are adverts – and there’s a whole heap of extra functionality. Those icons beside a person’s name are “reply”, “Direct Message”, “Favourite” and “Retweet”. It really saves the wear and tear on the thumbs to have quick access to those functions.
There’s even more at the bottom.

Conspicuous by its absence on the official interface is “Replies”. Slandr quickly gives you access to any messages you’ve been sent – either directly or in your friend stream.

There’s also a wicked search page.

The only problem with it, is that you cannot bookmark your searches. So, if you’re following a particular subject of hashtag, you’re out of luck. You’ll also notice that hashtags aren’t clickable.

Twitstat Mobile

Twitstat is a great site for gathering stats about your twittering. Their mobile interface is also pretty good.

It’s clean and well spaced. Although you may see fewer tweets at once, it’s much easier to read than other interfaces.

The little icons allow you to favourite, reply and – oddly – “LOL” someone. Disappointingly, they rely on JavaScript. I keep JS switched off on my BlackBerry for performance reasons.

On to the features that make Twitstat stand out.
Reply highlighting. When scrolling through a load of tweets, it’s easy to miss ones directed at you. Twitstat helpfully colours the tweets to make them stand out.

The “ego” link will return all the tweets that feature your name.

Hashtags are clickable and can be bookmarked.

Anyone who follows twitstat, will have generated for them some details about their tweeting.

I post a lot about beer…

Not only will Twitstat expand some links run through URL shortening services, it will also place flickr pictures in-line.

This is probably the most useful aspect. It’s so annoying to have to click through to find out what someone thinks is cool. Much better to see the full URL so that I can determine if it’s a link I want to visit, if I’ve seen it before or
if it’s BlackBerry friendly.

Dabr

Finally, on to dabr.

Lots of options – but the screen is quite cluttered. Again, it has the ability to reply, DM, favourite and retweet.

The basic search functionality is good. It allows bookmarking.

Hashtags are also clickable.

Profile pages allow you to see followers, which is a nice touch.

It does have a couple of bugs. The input field isn’t limited to 140 characters. This means you don’t get notified if your tweet is too long. It also claims to do reply colouring – but I can’t see any colouring in the BlackBerry browser.

Conclusion

All of the alternatives are better than the standard m.twitter.com interface. I find myself using Twitstat for reading and searching – but as it doesn’t allow me to follow new users, I flick back to Slandr quite a bit. Twitstat has cooler features, but Slandr is more useable. Dabr is fine – but it doesn’t have anything to make it stand out from the others.

Geek Stuff

These device used was a BlackBerry 8800, running firmware 4.5.0.37. The screenshots were taken using JL_Cmder.