Mobile Web
’11.5G’ made me laugh – in a write up on a conference I read this morning (no link I’m afraid – this client doesn’t have copy and paste!). It means the need to build services that cater for all bearer technologies: 2G + 2.5G + 3G + 4G = 11.5G, right?
Well, my first instinct was to point out that they were missing 3.5G (HSDPA) and 3.75G (HSUPA), and I’m sure I have also heard something described as 3.9G.
So we’d have blown through 20G already. Perhaps this is getting a bit silly.
A similar thought recently concerned the daft web3.0 meme starting to do the rounds. Should we actually care what it is called until it succeeds in meeting users’ expectations?
Looking across at the technological evolution within the recorded media industry (vinyl, cassette, CD, MP3), there’s clearly been no need to resort to dull numerical monikers – the differences are clear enough to users – as are the benefits.
So perhaps we need to drop the in-house jargon and arithmetic one-up-man-ship… and think about packaging what we do in simple language that helps human beings know what’s in it for them.
…and in a fit of early morning motivation, I’ve built a parked page for the front of the site.
Firstly, I set the DNS servers for the domain to be my hosting company (this seemed to take about 10 minutes to propogate – I’m sure it should have been hours).
Then I stole a markup template from dev.mobi. Those who know me probably realise I know how to bootstrap an HTML page 
but I took the template approach to 1) get an idea of the sort of page structure the .mobi guys were recommending, and 2) get the declarations and DTDs right. I can never remember that stuff.
I rationalised the in-line CSS a bit since some style attributes were duplicated in the template, and I’m still assuming that every byte counts in mobile. Then uploaded.
Tada.
Looks OK in Internet Explorer:
Looks OK in Firefox (give or take some anti-aliasing):
Looks OK in some device emulators:
(although I can already see I’ll need to learn something about font sizing…)
Most importantly, it seems to work on a real phone.
So far, so easy
Well I’ve sat on this project for a week or so. Other business calls. But I’ve had a chance to do some preparation.
Firstly, I signed up for the .mobi developer forum at http://dev.mobi/ (which is a cool domain, at least). With a desktop browser, you get redirected to pc.dev.mobi - perhaps some sort of a convention - but, nicest of all, you can also view the site on a mobile.
(So I guess when you’re out and about and scratching your head about a development problem, you can hook up and surf for answers.)
The only catch seemed to be that I couldn’t sign up for an account on my phone. I had to do that on the PC, which was slightly frustrating.
There’s some good stuff there. How to use WURFL for example, and how to skin up CMS and blog platforms for mobile. I’m sure there’s more to come - in the meantime, the blogs are worth a read. But it’s not yet a vibrant buzzing community… I guess these things take time and I’ll keep checking back.
For now, I think I’ll need to forge my own path. I guess I should plan to contribute what I find back into the developer community.
Not good words about mobile. But good words for mobile.
It’s unlikely that predictive text is really going to help you type a .com or .mobi address into your mobile browser. And you want the user’s experience to be as streamlined as possible.
Efficient URLs are the order of the day. And no “slashwalls”.
(I mean expecting users to append /mobile or /wap or whatever. That’s so 1999)
But length is not everything thanks to the way that most alphabetic text entry works on numeric keypads. A is 1. B is 11, C is 111, D is 2, etc. So not all letters are created equal, which can spell (!) trouble for some domains.
As an example, you might be particulary proud of ziz.com and think it is a great snappy URL for mobile users. But wait: Z is four keypresses of the 9 key, and I is three of the 4 key.
So just those three letters demand 11 clicks from the mobilely-impatient user.
In contrast the first five letters of madam.com (whatever that might be about) cost 5 clicks. If you really want to burn 11 clicks, then why not go for accessible.com?
So this set me thinking… what are the good and bad words – on a mobile keyboard – and which have a good ‘keypress ratio’ of clicks to actual word length resulting. KPL: “Keypresses Per Letter”, and lower is better.
A quick bit of spreadsheet magic and I’ve got my list. My source of nearly 20,000 words was 12Dicts 3esl, and my algorithm was simply to add 1 for a, d, g, j etc, 2 for b, e, h, k etc… and then divide that total by the word length.
The winners and losers in summary:
3 letter words:
24 words (from add through to www) have a KPL of 1
SOS is the worst 3 letter word with a KPL of 3.67
4 letter words:
damp, data, mama, papa and watt all have a KPL of 1
fizz and loss have a KPL of 3.5
5 letter words:
adapt and madam have a KPL of 1
sissy has a KPL of 3.6
6 letter words:
damage, gadget, jagged, jammed, madman, and matted all have a KPL of 1.16
crisis, fossil, frizzy, and sizzle have a KPL of 3.33
7 letter words:
adamant, attempt both have a KPL of 1.14
bossily thru viscous have a KPL of 3.14
8 letter words:
amputate, Muhammad, and teammate have a KPL of 1.25
scissors has a KPL of 3.5
9 letter words:
appendage and attendant both have a KPL of 1.33
fossilize has a KPL of 3.22
10 letter words:
amalgamate has a KPL of 1.3
crisscross has a KPL of 3.4
And the list goes on of course. I’ve zipped up an HTML version in kpl.zip (~110k). For those interested, there’s also http://www.pukupi.com/tools/domainatron/.
My rather crude algorithm hacked up in Excel VBA is:
Function keypress(word As String)
keypress = 0
For i = 1 To Len(word)
c = Mid(word, i, 1)
Select Case LCase(c)
Case "a", "d", "g", "j", "m", "p", "t", "w"
keypress = keypress + 1
Case "b", "e", "h", "k", "n", "q", "u", "x"
keypress = keypress + 2
Case "c", "f", "i", "l", "o", "r", "v", "y"
keypress = keypress + 3
Case "s", "z"
keypress = keypress + 4
Case Else
keypress = "n/a"
Exit Function
End Select
Next
End Function
I can see plenty of room to enhance this, by the way… taking into account those words that have consecutive letters from the same key (which slows you down as you have to wait for the cursor to move on). And then there’s the fact that .com, .net and .mobi have varying KPLs, and that some devices even make . a real nightmare to insert. Any other ideas?
I’ll probably get round to building a dynamic web-based KPL analyser too… We’ll see.
Anyway, in the meantime, please dwell on the fact that you can type amalgamate with only 3 more keypresses than a QWERTY keyboard – and be thankful that you don’t own uncharacteristically.com
OK. After a day on the beach with the kids, I have an idea. That could have taken weeks - in the interests of pacing this story, thank goodness it was only a few hours.
It’s a simple idea - a bit naive, but good enough for the exercise.
Whenever I travel abroad to a country where I don’t know the language, I always find myself stuck with the simplest conversations. I feel really guilty not even knowing how to say thanks to the taxi driver (I failed miserably with Hungarian last week).
So my site is going to provide – to mobiles – translations of the same 5 words (in as many languages as I can compile):
“Hello“, “Thank you“, “Yes“, “No“, “Goodbye”
…all the vocabulary a world citizen requires 
Now this should work quite well as a mobile app. It’s a low-bandwidth, low-markup sort of service, and it’s exactly the sort of thing you need when you’re in a mobile context.
So… first the domain name. I think I’ll take the first letter of each of these 5 magic words and see what’s free.
HTYNG.mobi is available (as the .com is, incidentally). But it doesn’t quite strike me as memorable enough.
So I’ll swap the first two letters, and it at least becomes a pronouncable word. I go to my registrar (Dotster, as it happens), check it out…
… and $49.98 later (I have to register it for 2 years), I can welcome to the world THYNG.MOBI!
Stay tuned as I actually try to do something with it.
An interesting thing happened a few days ago. My domain registrar sent me a mail to tell me that the .mobi versions of each of my .com domains were still available. Would I like to purchase them?
Not interesting in a direct marketing sort of way, but interesting for me, since I’ve been watching the promise of the mobile web evolve since 1998, and now we’re getting to a point where my registrar is mailing me to get me to upgrade my domains… cool. (It’s happening, it’s happening!)
Anyway. Also interesting because I don’t yet have a .mobi address, and I guess I should get one, and build a site. I’m also intrigued because, as far as I can tell, the .mobi TLD is about more than just a dot and four letters: I think I’m also going to need to prove my site is up to the job.
So, I thought I’d document the process as it happens. A step-by-step diary of how I get on. (Step 1: think of an interesting mobile proposition for which the .mobi address is still available! That’s going to take a few hours…)
Stay tuned for my progress. If things work out, it might also serve as a bluffer’s tutorial to bootstrapping a mobile site.
Long feasible in the US, but only starting to get traction in Europe, the idea of flat-rate, open-garden mobile access to the Internet might be coming…
http://www.three.co.uk/news/index.omp
Interesting stuff. Of course this is an operator with a network built for this sort of thing, but which has previously been as ‘walled’ by default.
I think the inevitable is happening and another catalyst of the mobile web (as envisioned by many) is happening as we speak.
This factor (the lack of flat rate combined with open access) has long been touted as pretty much the one and only thing holding back mass mobile web user adoption.
Let’s hope that’s right. It seems a couple of enlightened mobile operators are about to try to help us prove it.
I truly hope it won’t call our bluff (and we’ll merely find some other excuse for failure!)
You know what you have to do
A question on the Mobile Monday mailing list today: how to stream video from a mobile phone?
Obviously streaming the other way is a fairly well known science, but the other way? Well, before thinking too much about why (I envision a remote controlled helicopter with suspened camera – controlled by SMS ) I had a look about…
My initial assumption was that you’d need to write some software (my first answer to everything). There are Symbian APIs for the camera and codecs, J2ME JSRs to approach the same thing, and maybe even some Pocket PC APIs.
But then a couple of Google searches found Mobiola (only works over USB and Bluetooth) and finally, Comvu on PPC. Genius.
Community feedback seems to be positive. But I guess we’ll need to wait for HSUPA until we all become roving live broadcasters & vloggers…
In case there was any doubt that there’s something underway (that may or may not be called ‘Mobile Web 2.0′), observe the enthusiasm and buzz converyed via this new W3C aggregator.
It’s interesting in two ways. It reminds us all that the W3C Mobile Web Initiative group is healthy and well underway. It also shows that W3C has more to offer than standards and recommendations. This is about trying to seed a community.
And it mostly seems to be down to the efforts of Dominique Hazael-Massieux, who is to be applauded.
[Edited from comments made on the dotMobi blog]
As I understand it, .mobi is not as much about the fact a site is to be used on a mobile phone as it is to signify that the application or content is going to be suitable for usage in the context of mobility.
ilovetacos.com might be a corporate site with a rich, browsable ordering service.
ilovetacos.mobi, on the other hand, might be an interface designed to get you some tacos (with as few keypresses and dollars of data usage as possible), while you’re out and about.
I would have thought “finding out about tacos at leisure” is a totally different use case to “I’m on the move. Get me tacos now!”
It’s one web. Just two use cases. Right?
Additionally, if the browsers are able to do spectacular gymnastics to get full web sites running on a phone, then content developers may be lulled into a false sense of mobile comfort.
In fact, I would hazard thar ‘mobile applications’ are encapsulated by a philosophy far broader than fiddling about with markup and media-ruled stylesheets (on the server or on the client).
Could any browser turn a corporate taco web site into a location-based delivery service?
One final way of looking at this: if you could run a full version of FF2 or IE7 on your phone, might there not still be a good reason to visit the .mobi domain first (as you walk down the street)?
