Sunday, 26 April 2009

More Usable URLs:

URLs are consistently the least usable aspect of our interaction with web-based information services – which is terribly unfortunate considering their prominence in how we access, share, and interact with these services.

With that in mind, let’s take a look at how Twitter’s URLs could be more usable – by either being more logical, more readable, more share-able, or a combination of all 3.

Here’s a standard Twitter URL:

Let’s break this apart:
The person’s Twitter account we’re interested in – very clear1.

I’m not sure what ‘status’ is – seems like a very system-centric term. For the sake of this conversation, let’s assume it’s a synonym for ‘note’, ‘message’, ‘news’, ‘memo’, or the collection of things I publish at Twitter.

This is the individual ‘status’ identifier. Presumably, it’s the primary key ID of this ‘status’ within all the ‘statuses’ in Twitter’s database – making this ‘status’ ID global – not nested within ‘garrickvanburen’. Again, very system-centric and kind of backwards – if we assume URLs should go from largest logical entity to smallest nested entity.

A RESTful URL structure would dictate the following:
/Plural Version of Resource Name
/Individual Resource Identifier
/Plural Version of Sub-Resource Name
/Individual Sub-Resource Identifier
/(et. al.)

If we mapped Twitter’s existing structure against this model we’d have:

We can see, Twitter’s URLS aren’t exactly RESTful, and since they’re not – let’s look at some ways to make them more logical.

Proposal 1: Logically Long text-of-the-tweet-in-the-tweets-permalink.
This is the most usable and readable for both people and machines. It has the huge benefit of having the entire message in the URL (the mind reels with possibilities). WordPress does a great of making legal URL strings out of a weblog post’s title.
Benefits: Highly-readable, logical nested structure, great for search engines
Detriments: Long (though Twitter’s built-in limits provide a maximum length)

Proposal 2: Globally Short
This is akin to my WordPress URL Shortening Hack
Benefits: Short
Detriments: Almost no information provided makes this the least usable and equivalent to the shortened URLs you find throughout Twitter.

Proposal 3: Personally Short
Where 5954 is the number of the individual message in the pool of all my messages.
Benefits: Short, encourages numerically navigating through a person’s messages.
Detriments: Numbers are always less usable than words.

The great thing about these proposals is they’re not mutually exclusive. In fact – different URL structures bias different usages and contexts. In the same way different formats (HTML, RSS, XML, Text-only, etc) providing different presentations of the same webpage to different devices are more usable – different URL strings pointing to the same webpage are as well.

1.’s URL structure doesn’t include the person’s name [example]- making the number less confusing, but the URL itself less usable.

Tuesday, 14 April 2009

A Proposal for Shorter Google Maps URLs

I was adding a link to a Google map into my iCal and noticed Google is encouraging me to share the the map URLs in email and IM.


But there’s a problem with the Google Maps URLs.

They’re +/- 155 characters.

Here’s the full URL:,+plymouth,+mn&fb=1&split=1&gl=us&cid=1854680882426337660&li=lmd&z=14&iwloc=A

This URL is neither short, nor easily memorable, nor easily guessable. Which means it’s a completely un-usable – and barely shareable URL. Plus, something tells me this breaks both email and Twitter’s box.

CampaignMonitor says we don’t even get to the geocode.

Really Google!?

Even something like this is more share-able (in that it’s short).

For the exact same character count, we can make it more guessable and more memorable (therefore more usable).

Yes, this is the exact same complaint Dave Winer had 5 weeks ago in Solving the TinyUrl centralization problem. Hell, if I’m only 5 weeks behind Winer, I’m cool with that.

Thursday, 9 April 2009

My Long Bet Against Mobile Carriers: Update 1

Late last year, I extended my T-Mobile contract 2 years.

When I signed it, I had a hunch it will be the last time I’m locked into an agreement like that.

Now, I’m confident – so confident that if I was holding any mobile carrier stock, I’d start shorting.

A couple weeks back, we got a great deal on a 5-day trip to Playa del Carmen, Mexico. We booked it, made arrangements for the kids and packed out bags.

I left the laptop and my Nokia at home – taking my iPod Touch and the Kindle.

Wifi was everywhere – in the airports, Starbucks, probably more places as well – all along the way. While the hotel was only confident of their wifi covering their lobby, coverage was fine in our room.

I was able to check email, Twitter, Cullect, and we used Skype to talk with everyone back home. All on the iPod Touch all over the hotel’s wifi.

When we returned home this weekend, my Nokia greeted me with.

0 messages
0 missed calls

Short URLs Re-defining SEO

It’s conventional search engine optimization wisdom that URLs should contain words, separated by either dashes or underscores. This approach improves the readability of the URL – making it more usable for people while simultaneously giving internet robots something to work on.

But with people sharing URLs within places – like Twitter and Facebook (and … and … and …) – places with a default social context, we’re seeing a URL’s context trump its readability as a significant usability factor.

Who is sharing and how they describe what they’re sharing is more important than the readability of the shared URL itself.

Leaving the search engine robots blocked out completely (disallow, nofollow, etc) or piecing together a pile of redirect URLs (which may or may not exist tomorrow, e.g. RE07.US).

Additionally, the share-er’s pays for each URL with their social capital. ‘Good’ URLs (as deemed by each individual follower) raise the share-er’s capital while ‘bad’ URLs lowers.

Throw in the proliferation of other difficult to index assets like images and video – and we’re talking about an internet that’s not Search Engine Optimized, but Social Engagement Optimized.

Monday, 6 April 2009

Publishers Shorten Yourself

The Wege pointed me to an excellent article by Joshua Schachter on the issues w/ URL shortening services.

It’s consistent my concerns and my Insecurity of Short URLs post.

As I alluded to that post, I see 3 opportunities for URL shorteners, all of them revolve around increasing trust (branding, security, backup).

Let’s take that first one – branding. Another name for branding is accountability. Who really knows where a tinyurl a similar service will point you, but you can be confident a URL will point you to an article on and a URL will point you to something I authored.

From my perspective there are 3 parties that should have a good short URL corresponding to their identity:

  • the author (i.e.
  • the publisher (i.e.
  • the share-er (imagine a link blog of short urls)

Sometimes all 3 are the same.

Conveniently, as greater accountability is introduced to short URLs, the issues of security and backups address themselves.


Take one step back.

Web publishing engines – like WordPress, MovableType, and all publications engines really – should automatically generate nice long human-readable URLs as well as a short, easy-to-share URLs (at least the URL keys, you can supply your own short domain if you want). (Dave Winer said this last month in “Solving the TinyUrl centralization problemsomething along these lines a few weeks back, but I can find the link right now)

One more step back, and you can see this is only an issue now because of the growing popularity of 1 specific website and an expectation that these short URLs are permalinks. If you don’t have that expectation, shorten with RE07.US

Monday, 30 March 2009

The Long Promise of the Mobile Web

I distinctly remember back in 1999, working for one of the first User Experience firms, when I first saw an internet-based service on a mobile phone.

Then, diversity meant some devices had 7 lines of text other had 3.

A few months later, I moved onto a new gig where I was designing location-specific websites to be delivered to laptops and very-alpha Linux-based tablet PCs with stylus-input.

Today, there are an ever increasing menagerie of mobile devices1 accessing HTTP-based services. The differences in their interaction models, primary usage contexts, and device capabilities make the IE vs. Firefox vs. Safari design challenges look like bad case of hiccups.

The design goal can no longer be one of consistency in visual design, but consistency of brand experience across multiple contexts and appropriateness of any specific interaction within a given context.

That’s the promise the mobile web made me a decade ago.

Justin Grammens and I cover this and many other mobile computing topics in our recent podcast [mp3]

1. G1, iPhone, Kindle, Chumbly, Palm, etc. I’ll even include Twitter in this list of devices applications should be designed for.

Monday, 2 March 2009

Device Agnostic Web Services

This morning I talked with John Vorwald‘s Multimedia Web Design class over at UW-Stout.

One of the great questions asked by the students was:

“Where do you see the internet in 2 years?”

2 years? Easy.

  1. Everything has a web server in it.
  2. The internet is accessible everwhere.

On my desk, as I write this, there are 5 devices that can have web browsers in them. At least two of them also have web servers in them. Only one of them is a “computer”.

Dave Winer’s Denon Receiver has a web server in it, as do other devices like Chumby, TiVo, Eye-Fi.

Though the contexts are different, and the interfaces need to be different, the same internet-based service could make sense across all 9 of those disparate devices.

Two years from now?

Thursday, 26 February 2009

Kindle 2: 9 First Impressions


Amazon’s Kindle 2 arrived today. It’s the 3rd mobile internet device I’ve picked up this year, and a few hours in, I’m more pleased with it than the other two.

My initial impressions:

  1. The monochrome screen is gorgeous, and looks almost textured – as if there were a digital compliment to letterpress.
  2. The slim, flat, form factor and white case make me want to treat the Kindle like a piece of paper. It seems OK with that, comfortably setting where ever I put it, ready to be picked up whenever – just like book or more accurately a newspaper. Like a newspaper, it feels comfortable in one hand with a cup of coffee in the other. I now have no guilt about dropping our Sunday newspaper tradition.
  3. The navigation elements are slow and sticky. I’m never quite sure if I pressed the Next/Prev Page button hard enough – for the ‘click’ and the on-screen reaction seem to be off by a beat. The joystick is nearly flush with the face of the device and square (square?) with sharp edges, making it just uncomfortable and kind of painful to use. So far, using my thumbnail seems to be the least awkward way to manipulate it. Oh, and it doesn’t fly across the screen – it’s more stumbles from active area to active area.
  4. I’m already annoyed by the famous-author-portrait screensaver. I’d much prefer the screen to be black when not in use, especially considering sliding the power-switch toggle is an easy and explicit gesture that I want it to wake up. (If you know how to turn off the screensaver, please post it in the comments, thanks.)
  5. The reverse-text-on-page-turn is a jarring reminder that I’m reading an electronic device. Dramatically minimizing any chance you’ll get lost in the story. Remind me of a time when cars couldn’t drive faster than horses. Hopefully, this will go away (I’ll stop noticing it and the next revision will use a more subtle indicator).
  6. OS X does recognize the Kindle as a drive. Excellent – I wish the iPods were this accommodating. Then, I was disappointed to discover PDFs need to be converted before the Kindle recognizes them. I found Lexcycle’s Stanza – works fair for converting (good for documents, useless for presentations) – and loaded up my library of Pragmatic Programmers PDFs.
  7. Amazon’s ‘Recommended for You’ is built into the device and should be classified as a national economic stimulus package. Unlike every other commerce venue – including Apple’s iTunes Stores – it’s far easier to make the purchase within the Kindle thank to not.
  8. Overall, the least interesting thing to me is the Kindle as an “eBook” reader – though I finally feel like I have a comfortable device to read PDFs on. I’m far more interested that the Kindle has a free, persistent 3G wireless connection, a full QWERTY keyboard and a very basic browser (javascript is off by default). I find it both terribly amusing and annoying that, long webpages on the Kindle are navigated with next/previous page buttons – instead of scrolling.
  9. The mobile versions of Cullect and Twitter are completely usable.


” The iPhone UI, right down to its flowing scrolling on its touchscreen, is elegant and happy; the Kindle is klunky and irritating.” – Jeff Jarvis

Tuesday, 10 June 2008

Twitter: Build a Revenue Stream on Dunbar’s Number

The problem with many of the suggestions on how Twitter should charge1,2,3 is they put the emphasis on the wrong problem. The problem isn’t on the publication side (number of ‘tweets’ written by any individual), it’s on the distribution side (delivering the ‘tweets’ to their ‘followers’).

A simple equation to understand this ‘spew’ problem.

Message x Number of Followers = Total Number of Messages Sent

As of this writing I have 521 followers, so everytime I hit ‘update’ I’m sending 521 messages. and I’m no Scoble (>26,000 followers as of this writing). 26,000+ messages with each update.

The same math applies to email4 – why it’s a bad idea to send large attachments to a large number of people – but, due to the distributed nature of email, it’s less of an issue.

Unlike email, the message senders aren’t the ones specifying recipients. The recipients are initiating the relationship.

Scoble isn’t to blame. If anyone is, it’s each of the 26,000+ people that have explicitly clicked ‘follow’ on Scoble’s profile.

I’m a big fan of charging at the point of value, and the point of value here is real-time updates from Scoble.

Amie Street determines the price of a song by it’s popularity. Get in early – it’s free, be the last to hear it and pay $0.98.

It’d be interesting to implement the same model on Twitter.

Since Twitter is about personal connections, I’ll propose tiering the price on multiples of Dunbar’s Number. $1/150 followers, starting at #151.

Here’s how that breaks down:

  1. Greg Swan; 838 followers, $5.59 to be the next follower
  2. Chris Brogan; 9,104 followers, $60.70 to be the next follower
  3. Dave Winer; 10,282 followers, $68.55 to be the next follower
  4. Scoble; 26,842 followers, $178.95 to be the next follower

Me? I’m a bargain at $3.48. 😉

Three things I find very interesting about this idea:

  1. it turns following into a market – which at these volumes is what it is – more on that here.
  2. it might result in getting more of these kind of Twitter accounts and fewer of these
  3. Like all cool things about Twitter, they don’t need to build this for it to exist.


“Well I’ve got [a solid business model for Twitter], and it’s quite simple. Allow accounts to charge to be followed. A one time fee, or a subscription. Twitter takes a cut, say 30% like the Apple app store. ” – Jim Gilliam

1. “In Twitter’s Scoble Problem”, a Business Model by Om Malik
2. Possible Twitter Business Model: Charge Leets, Not Tweets!
– Bex Huff

3. “A business model for Twitter: Pay up” – Dan Farber
4. This is probably why Twitter won’t be supporting payloads anytime soon.

Tuesday, 27 May 2008

Failbox: The Broken State of Email Clients – Part 1

If you’re of a certain age, as I am, your first expose to email was probably in college or at work. Processing messages daily wasn’t difficult; the number of people that had access or reason to send you messages was low and messages arrived fairly infrequently.

So quaint and last century.

Today, I’m tracking 8 email accounts, multiple Twitter accounts, 1 phone, and a number of other accounts I check infrequently1. By a conservative guesstimate, I receive 400 incoming messages daily. I suspect this is lower than some of you and higher than others.

In this context, there’s no surprise Facebook, MySpace, etc have become a primary communication mechanisms for peer communication. The restricted context makes processing messages much easier if only by reducing the number of messages. Easy, like the scenario some of us started with.

Here’s a quick survey of popular email clients
Email Client (Initial Launch)
Apple’s (2001) direct descendant of NeXTMail (1991)
Hotmail (1996)
Microsoft Outlook (1997)
Yahoo Mail (1997)
Google Mail (2004)

While all of these applications have evolved and changed, their DNA is from a simpler time. A time with less email and no Twitter.

Spam has guaranteed receiving an email message is no longer a rare event, yet all of these clients insist on an unread indicator and its annoying little brother – the unread mail quantity indicator. All ordered reverse chronologically. Why a message has priority simply because it arrived last is baffling. Imagine lines at the IKEA managed via last-in-first-out. Riots would break out.

“My broader gripe is messaging fragmentation – creating a growing need for universal app to do mail, Twitter, Facebook, etc” – Julio Ojeda-Zapata

In Chris Anderson’s recent conversation with Russ Roberts, Chris Anderson digs into the economics of providing email clients for $0 (Yahoo, Google). It left me wondering if free is the innovation or if it’s preventing innovation.


“Personally, it feels like my Facebook stream is becoming an email inbox. I get a lot of messages, a few of them matter to me, and there are lots of business newsletters and promotions” – Jim Lastinger

1. Flickr, Facebook, Pownce, Skype.