Tripleodeon

Closing The Gap Between Your Users And Their Data

Tue, 08 Nov 2022 00:00:00 +0000

In September, I was lucky enough to speak about local-first apps at the International JavaScript Conference.

Local-first apps are a topic very close to my heart! Here are the slides and (tweet-shaped) notes I presented.

If you’d like to comment on individual slides, there’s a Twitter thread here. Enjoy!

A few months ago, I left Meta and my professional life in Silicon Valley, and started on a new adventure: living with my wife on a sail boat, Scout.

Here we are, anchored by Coney Island so I could get to this conference.

It’s not every day you downsize onto a boat. One thing I did was archive my digital footprint before I moved onboard.

To do so, I categorized my local files by date and I copied them over, year-by-year, to the archive.

I noticed a very interesting thing.

During the 2000s, I had more local artifacts every year. But around 2010, the archiving accelerated: fewer files each year.

By 2021, I barely had anything to show for myself!

It’s like my work just wasn’t on my computer…

And of course, that’s exactly what had happened.

My mail isn’t in .pst files any more. My photos aren’t on my hard drive. Most of my code isn’t on my laptop.

Documents, spreadsheets, designs, sketches, presentations: they’re all on someone else’s computer now.

(Sticker credit @chriswatterston)

Now, after a decade, we maybe take this for granted. But it is actually pretty cool.

I can drop my laptop in the sea and it’s probably OK. Everything important is saved on a quietly humming computer in a rack in a Google, or Apple, or Amazon data center.

And of course, it’s easier than ever to work together: we don’t have to send files back and forwards over email with increasingly ridiculous names to collaborate.

All you need is that fast internet connection!

Well, I don’t have time to talk about life on a boat, but let me at least say that this is a regular sight for me. I’ve become very aware of how dependent I am on other people’s computers.

And it’s made me think about the shift that’s happened over the last decade.

Once, our devices were everything. Our electronic destiny was in our own hands. When we built apps, they were ‘local-first’: state was always stored on the user’s computer.

The web was a useful to share and consume, but not fundamental to daily creative workflows.

Now, the pendulum has swung hard the other way. ‘Cloud-first’ intelligence, data, and business logic is nearly always hosted elsewhere.

And, our devices, which aren’t just desktop computers of course, act as thinner and dumber clients, entirely beholden to connectivity.

Despite this huge architectural shift, apps and their user experiences haven’t often changed that much. Cloud-first Excel in 2022 looks a lot like local-first Excel in 1997!

So has it been worth it? I do wonder if we’ve lost some trade-offs as this pendulum has swung.

Pseudo management consultancy! The pros and cons for the two approaches go on and on. It would be awesome if we could figure out the best of both worlds.

But honestly, when it comes to experience, what really separates a cloud first app from a local first app?

Now maybe I have rose-tinted nostalgia, but spinners seemed rare in the 90s.

Now? You’ll spin whenever you need data that isn’t present on your device. Which, with a cloud-first app, is… all of it.

Even well-written cloud-first apps are competing with the speed of light.

At least spinners are educational I suppose.

They’re reminding us that your embattled app developer is having to fight the laws of physics to get YOUR data onto YOUR computer.

So let’s think about this from a developer perspective.

This is how we architect web apps by default today.

But there’s a challenge here. The user thinks they’re seeing ‘the view of truth’, not the view of your app’s local cache. In fact the state of truth and the supposed view of truth are a long way away from each other.

PULL data every time there’s a new view.

POLL for changes in case something happened on the server.

Oh, the user makes a change? Get the change back to the server somehow, and reconcile.

PRAY that the resulting local state is consistent.

Sigh. Is there another way?

What happens when we think local-first? What if local state is the source of truth?

Immediately the state and view of truth are right next to each other. For a start, you can now keep them in sync at 16ms or less!

We can also make the state more structured on the client.

You’re closing the gap between your users and their data.

And local-first isn’t local-only. There’s nothing to stop us persisting that data to the cloud.

But that’s at our convenience: perhaps to save a snapshot every now and then, rather than on the critical UI path.

This was a super essay from four folks at MIT (@geoffreylitt, @nschiefer et al), exploring this idea.

This quote in particular jumped out. Not only can we provide a better experience for users, but it might also be easier to build these apps ourselves!

So what is this thing? It has these 4 requirements. But meeting them all is tricky!

Some state management tools provide reactivity but not structure - or assume a cloud-first app. On the other hand, a fully-fledged RDBMS likely compromises reactivity or footprint.

So it seems like local-first apps on the web might be a bit of a struggle.

With these challenges in mind, I’ve been building a project called TinyBase. It explores these ideas and tries to meet these requirements without too many trade-offs.

The zeroth thing about TinyBase is probably a bit meta until you know what the library does - but I wanted to get it out there anyway.

The clue is in the name - but yes, TinyBase is tiny!

Remember when the Ever Given got stuck in the Suez Canal last year?

This little digger trying to free a monstrous ship is the perfect metaphor for the life of a modern JavaScript developer. Why is my simple app bundle suddenly 6Mb bigger than it was the day before?

I wanted to do my bit. TinyBase has no external dependencies. This is pretty rare for non-trivial libraries.

You get core functionality for 4Kb (compressed), or everything for 8Kb. You can also reason about its (empty!) supply chain and security risks.

And I should say that keeping a JS library tiny takes a special type of obsession.

As a brief aside, I wrote about the experience of building a personal project without the typical constraints or deadlines of a professional environment. It’s been really interesting.

Back to TinyBase. One distinguishing feature is that it requires you to store your app state in a tabular structure.

Uniquely named tables, containing uniquely name rows, containing uniquely named cells, containing strings, booleans, and numbers. That’s it.

This might seem quite limiting, but unlike a real RDBMS, schemas are optional. Each row can have different cells to the others, so you can store orthogonal flat objects in each row. You can fit a lot of concepts into nested three-level tabular structures.

To work with that structure of data, there’s a completely obvious API for setting and getting data in an out of the store. Set tables, rows, and cells, and then read them back out.

OK, so I know what you’re thinking. This is maybe not so very interesting yet.

But an opinionated data structure can be reactive. Changes to any part of a TinyBase store can be listened for, and at any granularity.

Register a listener in one part of your app, and if another part makes changes to the relevant state, you’ll get a callback immediately.

And there are all the propagations and cascades you would expect here. Changing a cell will fire a listener for the table it’s in. Changing a whole table table will fire any listeners for the affected cells within - and so on.

But only those parts that change! TinyBase won’t waste your app’s cycles with parts of the data that stay the same. This is one of the reasons you can only store strings, booleans and numbers in each cell - they’re fast and easy to check for equality.

TinyBase doesn’t require React, but if you do use it, optional idiomatic bindings are available.

This is where the reactivity really pays off. The React hooks set up listeners, and only cause the component to re-render when the underlying data changes.

Imagine you have a todo app: a table of rows, with text and ‘done’ flag for each. (The JSX syntax here is illustrative).

Click the flag, and the data is immediately stored. The change then fires an event to update just the component for that cell: a surgical re-render.

Here’s a demo. The store has just three rows, with text and done cells.

The moment we change the data, the UI updates - and as you can see, only the row that changed re-renders.

Suffice to say that if this was coming from a server source of truth we would naively have to send an update to the server, perhaps even re-querying the whole table over the wire and re-rendering it all.

Whilst not a fully featured RDBMS, TinyBase does support some of the things that you typically do with such a system:

metrics of aggregated numeric values
indexes to look up rows quickly
relationships to associate rows to each other

These are also all reactive!

This demo indexes 10,000 words by stem, for a prefix-based autocomplete.

You get an idea of how fast local-first can be. Imagine the spinners if you loaded a new list of words from a server every time you pressed a key.

You can even express SQL-like queries (select, where, join, group-by, etc) with an imperative dialect called TinyQL, and register listeners to render the results - again reactively.

This is new, but opens up interesting ideas for client-side analytics and rich data-driven apps.

Here’s an example of how we build up a query with TinyQL. It’s got two tables: pets and owners. And then we set the definition to select the species of the pet, and the name of the owner. The reactive results are just as you would expect.

Here’s a more complex example with 5 tables and relational IDs to connect them.

One thing that’s notable: because this is imperative rather than declarative SQL, the joins are all made in a programmatic loop.

That’s TinyQL. Excited to see how people use this.

Here are a few other demo apps that showcase the benefits of using a local-first architecture:

There’s more to TinyBase of course. It turns out 8kb can get you a lot these days.

Next I’ll be adding typed ORM APIs so you can start modeling your domain in TypeScript.

And CRDT synchronization is a stretch goal. It’ll be truly local-first if I can pull that off!

Let’s pop back up the stack to summarize what we’ve talked about.

Firstly, we talked about local-first apps. There is an alternative to having everything locked up in a cloud, and placing more of the logic and content of truth on a client device.

More fine reading: I greatly recommend this article by @inkandswitch.

They talk about a set of seven principles for local-first apps, of which this is just one.

These are all wonderful food for thought.

We also talked about what this means architecturally - bringing a relational, reactive data store into the client, rather than having that source of truth in the cloud.

And we looked at how TinyBase might be an interesting way to do that.

I must stress that your mileage may vary. This is no panacea.

Certain types of apps can never be local-first: a social network or a banking app, to name just two! And until decentralized synchronization is more widespread, the cloud is still pivotal for collaboration.

I also think it’s not always super easy to retrofit a local-first architecture onto an app that’s already cloud-first - at least compared to going local-first in a more greenfield environment from the start.

But I feel like if you can make local-first work, you should give it a try.

This morning’s beautiful sunrise is symbolic, because it’s easy for us to get stuck in the status quo, following established approaches even when constraints change and opportunities arise.

If you’re here, you are still early in thinking about local-first apps.

And if we can pioneer new techniques that help us build more amazing user experiences (and yes, question a few assumptions along the way) - we should do it, and together!

Thank you.

Software Without Compromise

Thu, 13 Jan 2022 15:00:00 +0000

Have you ever worked on a software project and found yourself asking “if only”? “If only I didn’t have to support this legacy codebase”. “If only my customers were clear about what they wanted”. “If only we had more people”. Or “If only I had more time”?

Yes, of course you have. It’s the job. The craft of writing software is fundamentally about handling compromise, understanding trade-offs, and knowing when (or hoping that!) things are just good enough. At least, until the next version! We’ll get it right then, eh?

In my professional career, I’ve known this only too well. I’ve been fortunate to work with brilliant people, but still… we have deadlines, roadmap commitments, rapidly evolving requirements. It’s actually pretty fun, and those challenges go with the territory.

But I’ve always wondered… what would happen if you didn’t have any of those constraints? What if you had all the time you needed? If you could build exactly what you wanted? If you had the time to make your code (well, at least in your eyes) perfect?

No compromises.

Over the last few years, I’ve been tinkering on TinyBase in my spare time. Accountable to no-one, and purely for my own curiosity, it’s a small project that had a chance to explore this possibility. And today I finally launched, which is about as close to this dream of having had “no compromises” as I could personally get.

(I am fully aware that this is in the eye of the beholder! What I think is close to perfect you may think is a hacky prototype. Bear with me, whatever your absolute standards are!)

This post is not about the details of the project itself, but about a few of the things - both good and bad - that I experienced as a result of loosening those constraints.

It’s hard to converge when you can refactor forever

Like all software, TinyBase has grown organically. I didn’t have the perfect vision of what it would be when I originally started, and I started with the basics, and kept layering on new ideas, features, and patterns. I lost count of the times I refactored it - often back and forward between similar ideas.

In a real software project I would have had a finite number of shots at this: breaking API changes are expensive. But when no-one is using your product and you are the only person doing codemods, you can keep moving things around forever. It becomes a curse!

In plenty of cases these oscillations meant that the total distance covered far exceeded the net final displacement - more motion than progress! Actually having a damping function to force convergence would have been far more efficient. Oftentimes I probably needed a peer calling out my indecision.

That said, when I did finally converge on the conventions and patterns I was happy with, I was able to guarantee them consistently across the entire codebase. And that feels good.

Syntactic perfection is cheaper than you think

I feared that polishing the code itself, line by line, character by character, would be where the majority of my time was wasted. I did want the formatting to be perfect!

But here I invested in tooling so I just couldn’t get it wrong - and the result was joyous. Typescript and Prettier did a lot of the hard work of course. I cranked up ESLint for every personal preference I could think of - including how comprehensively every declaration is documented. CSpell found a bunch of naming issues and typos. These are the giants whose shoulders I stood on.

My overall view is that these days, these are things you probably never need to compromise. Once set up, any code - at least JavaScript - can be basically syntactically ‘perfect’ forever, however you choose to define that.

It’s easy to obsess over minification

I wanted TinyBase to be small. It’s in the name. I wanted to have no runtime dependencies so that there was no danger of application bloat.

This caused me to not compromise on supporting legacy browsers. I didn’t want lots of polyfills, for example, and modern terse syntax like nullish coalescing was super appealing. I moved everything that appeared more than once into common libraries - even string literals! - testing every change with the bundler to see if it saved or cost a byte. I even stumbled on things like grouping let and const declarations to save a little more.

In the grand scheme of things, was this effort worth it? I’m happy with the call to keep it modern and free of dependencies. But I spent many hours of my life saving a few tens of zipped bytes for the world, and I’m not sure that was time best spent.

Test coverage: 100.00% or bust

I knew I wanted to try and ship a project that tested every line of code, every branch and every statement. This is definitely not a luxury I’ve enjoyed on any professional projects!

For TinyBase, I wired up Istanbul coverage to Jest and made the coverage report a standard part of my workflow. Sometimes I was able to write tests before code, but more often I just fast-followed with tests after functionality. In the end, it never felt like a drag, and once you get used to the coverage percentage always being in the high 90s (at worse!) it only takes mild motivation to get it back up to 100% again.

Contrast this with having to climb the huge mountain of getting coverage up on a previously un-tested codebase. That’s soul-destroying! I think the trick is to commit to have 100% coverage from as early in the project as possible.

Documentation as a first class citizen

In my experience, documentation is always the last thing to get prioritized on a software project. But having had a previous stint as a technical writer way back in my career I wanted to see what it might mean to put it on more of a pedestal.

For TinyBase, there is rich documentation built into the TypeScript definition files, with a (linted) guarantee that everything has documentation coverage. A toolchain based on TypeDoc turned it into the API documentation. As an extra trick, all examples in the documentation are themselves tested with Jest, which means a guarantee that everything runs, and that there’s a little extra test coverage.

On reflection, I may have overcooked this. It took ages. Even relatively obscure parts of the codebase ended up with multiple working examples and rich explanations. In fact it might even end up being daunting for the reader - making the API seem larger and more complex than it actually is.

But is it valuable?

This is the big one. Untethered by requirements, customer constraints, and deadlines, how do you guarantee that what you are building is actually useful in the real-world?

In other words, it might be ‘perfect’, but is it ‘valuable’?

I do worry about this. Having disappeared down the rabbit hole of creating that utopian project, and then popping up again… what will other people think? It fits how I think of the world, perfectly - but that is almost by definition!

Indeed, I asked a few friends for feedback on the project last week. They were all lovely about it, but one theme that definitely came back was “but why would I use this?”. In creating this thing, had I lost touch with why it should even exist?

Here goes!

Well, we will see. I’m open sourcing it today, and sharing it with the world. I’m a little nervous I guess! But then again, perhaps ‘without compromise’ means that even its reception shouldn’t matter.

At the very least, I now know what it feels like to be able to indulge ones’ self like this.

And an indulgence it was! I think it’s important to finish off with one final point: and that is to acknowledge that working on this project has been a huge privilege in many senses of the word.

I’ve been able to work on a passion project in my spare time for such a long time, complementarily to my professional and family life, and that I can value it for the intellectual stimulation alone. I know how lucky I have been.

And bonne chance, TinyBase!

My Blog; 2006-2011 & 2022-

Thu, 13 Jan 2022 15:00:00 +0000

This blog has been dormant for over ten years. But not extinct!

A decade at Facebook & Meta has been a wild journey, and a trillion things have happened that would probably have made great blog content.

But for various reasons, I didn’t keep this channel going: generally a combination of limited time, investing in internal communications instead, and yes, a degree of confidentiality.

However, in 2022, I want to see if I can find that voice again! Are blogs still a thing?

I’m not sure what the dominant themes will be, but you should expect some creative pieces (I’m trying to be more present on GitHub and build things!), notes on what I find as I explore technologies as yet unfamiliar to me - and maybe a few personal posts.

For the nautically inclined, my wife Jayne and I have been building a boat. Follow that adventure on Scout Sailing.

See you soon!

Moving on

Fri, 02 Dec 2011 06:00:19 +0000

Friday is my last day at Sencha.

It’s been a great company to work for, with smart people, valuable products and a vibrant community. It’s not too much to say we’ve really led this year’s growth of interest in mobile web applications, HTML5, CSS3, and JavaScript.

But for me, a new challenge. As of Monday, I’ll be Head of Mobile Developer Relations at Facebook.

Not much to say right now – I have a six-week bootcamp to get through – but it’s probably sufficient to say the company also has a few interesting ambitions in mobile.

So, thank you Sencha, for a brilliant experience. And hello Facebook: let’s see what we can do.

First, Understand Your Screen

Thu, 01 Dec 2011 10:04:38 +0000

I unashamedly maintain that there is so much more to being successful on the mobile web than dealing with screen size. But I do accept that dealing with screen size is at least a first step.

Thank goodness then, that the matter of screen size is so simple and well understood.

Really?

As web developers, we will often need to know the screen size of the device we are displaying content on. Perhaps on the server, perhaps on the client, perhaps to be used as a clause in a media query.

But how best to measure it? And what are we measuring anyway? On the client-side, for instance, a variety of ways exist to determine screen and page size: things like screen.width, window.outerWidth, document.body.clientWidth, and so on. But these properties are infamously unspecified by any standards: so what do they all mean – and how reliable are they on mobile browsers?

Required reading at this point is PPK’s viewport article. With an article of tables from him that long, you know something’s up.

But last week I pushed out an update to src.sencha.io which allows client-side screen size parameters. Which parameters should mobile developers use? And when?

So for this blog post, I looked at a range of these metrics, and recorded their values for a variety of mobile browsers and page conditions. I’ve been working in mobile for far too long, but still, the amount of diversity in the results shocked me. Read on for the gory details, or skip to the end for the TLDR. I think there are some interesting findings.

Methodology

The tests comprised a very simple web page, containing several paragraphs of meaningless Latin, and a JavaScript function that runs to take screen measurements within the browser. The following properties are sought:

screen.width
screen.availWidth
window.outerWidth
window.innerWidth
document.body.clientWidth
document.body.offsetWidth
@media device-width
@media width
screen.height
screen.availHeight
window.outerHeight
window.innerHeight
document.body.clientHeight
document.body.offsetHeight
@media device-height
@media height
window.orientation
@media orientation

The CSS media query properties (device-width, orientation, etc) are taken programmatically by evaluating expressions with the matchMedia() function, supported in iOS v5.0 and Android v4.0.

I’m sorry to say that the tests were run on emulators rather than real devices, but covered iPhone (iOS v5.0 and iOS v4.3), Android v2.3, Android v4.0, and Opera Mobile v11.0. The Android and Opera simulators were set to use HVGA (320×480) so as to have conditions as consistent with the iPhone as possible. (Even though the actual physical screen of a retina iPhone is 640×960, this HVGA resolution is the one reported to the software APIs).

The tests were run with two different HTML document types – HTML5 and XHTML-MP – and also a third time with no doctype specified. The tests were also run both with and without a viewport meta tag to control the default width (constrained to ‘device-width‘) and scaling. Additionally each device was tested with landscape as well as portrait orientation – making a total of 12 test combinations for each browser.

For the iPhone and Android browsers, PhoneGap-wrapped versions of the test pages were also run (without the viewport meta tag), and finally, for iOS v5.0, the iPhone’s ‘Add to Homescreen’ technique was used (with the apple-mobile-web-app-capable meta tag) to launch portrait versions of the tests in a full-screen mode.

As if all those combinations were not enough, the properties were accessed four times during the lifecycle of the page: a) inline before the <body> tag, b) after the </body> tag, c) on the document’s load event, and d) one more time, 250ms later. I had a hunch that the values – at least those relating to page height – might change throughout this lifecycle.

Results

The full set of results is available here. The various combinations of conditions are across the top, and operating systems (and measurements made) are down the left. Each cell shows the value returned from the relevant API call, and ‘-‘ is used where the call failed or returned an undefined value.

Where the value changed during the lifecycle of the page, slashes delimit the change, and a letter is used to indicate at which of the four measuring points the value changed. So for example, ‘208/c:1962‘ means that a value was 208 before the <body> and after the </body>, but then it changed to 1962 for ‘c’, the document’s load event, and remained so 250ms later.

There’s a lot to digest in there, although you may at least have noticed – as I have – that homogeneity is scarce. You may notice some particularly strange results, particularly on Android, but also on iOS and Opera. Let’s analyze the data by slicing the findings by property measured, dicing by operating system, and trying to digest the whole sorry lot.

Analysis

`<a target='table' href="/assets/2011/12/table.html?r=screen.width&c=">screen.width</a>` & `<a target='table' href="/assets/2011/12/table.html?r=screen.height&c=">.height</a>`

These two properties are generally understood to return the physical dimensions of the screen upon which a browser is running. On desktop browsers, they will return you 1024×768, 1440×900, 1600×1200 and so on, regardless of how the actual browser window is sized. On mobile devices, one would expect the same behavior, and get full physical screen sizes.

Well, close. But no cigar.

Opera Mobile and Android v4.0 (as well as v2.3 in a PhoneGap app) behave most intuitively in this regard, and will indeed report 320×480 or 480×320 for portrait and landscape respectively.

iOS also consistently reports the physical dimensions of the screen (320×480), but notably fails to flip them for a change or orientation. So be aware that in landscape mode, your browser’s width will actually, apparently, be reported to be larger than the screen’s.

Android v2.3, in a regular browser scenario, however, displays even more curious behavior. Its screen.width always starts off as 800 – which is clearly some sort of virtual viewport, rather than the physical screen. But when the document has an XHTML-MP doctype, or a constrained viewport (for any doctype), the value will switch, by the time of the document load event, to be the 320 or 480 you might expect.

Now this might be tolerable if you remember to wait for documents to fully load before accessing this property, but even that caution is blown to the wind by Android v2.3’s screen.height behavior.

With a non-constrained viewport, a portrait orientation, and with no doctype, screen.height was reported during this test as 1003. With an HTML5 doctype, it also switched to 1003, but only after dallying at 498 until at some point after the document load event. With an XHTML-MP doctype, it also started out at 498, but then dropped to about 40% of that value (199) by the time of the document load. With a constrained viewport, behavior was stable as a function of doctype, but also demonstrated the 60% drop at document load: from 1003 down to 401.

Landscape-wise, the same sort of issues occur: with no doctype, screen.height is a reliable 402; and with an HTML5 doctype, the same value is also (eventually) returned. The XHTML-MP doctype, or a constrained viewport, will cause the eventual value to be 241, but by way of various intriguing values. Our constrained, HTML5 document, for example, reported 372 before and after the <body/>, 223 on load, and 241 at some point afterwards.

Yes, these actual values are probably dependent upon the length of my particular test page itself, but remember that these are supposed to be the physical screen dimensions, folks!

Some semblance of normality returns to Android v2.3 in the PhoneGap environment. The values of 455 and 295 are hardly accurate measures of physical screen size, either (since bizarrely they seem to take the 25 pixel status bar into account!), but at least they’re close, and hooray: take solace that the value does not change during the page lifecycle.

`<a target='table' href="/assets/2011/12/table.html?r=availWidth&c=">screen.availWidth</a>` & `<a target='table' href="/assets/2011/12/table.html?r=availHeight&c=">.availHeight</a>`

In the desktop world, the available width and height returned by these two properties still relate to the whole screen, rather than the browser’s window, but they take operating system chrome into account. The menu bar in OSX means that screen.availHeight is at least 26 pixels less than screen.height, for example – although the width values will probably be the same (unless you have a non-minimizing dock on the side of the screen).

In mobile, one might expect the available values to take into account any OS status bar height. Let’s see, shall we?

I need to caveat the Opera results here, since the simulator runs in a dedicated window without any ‘real device’ chrome. But that should have implied that its available dimensions are the same as the screen’s – and this was not what was seen. In fact, the availHeight is reduced to 369 from a height of 480, not by any OS chrome, but by the browser’s own rather fat chrome. This is not what is expected – even if, on a real device, it emerges that the OS chrome is deducted too.

And having labored over Android v2.3, above, there’s not much more to say here about that operating system either. Without exception it depressingly reports exactly the same values for <a target='table' href="/assets/2011/12/table.html?r=android23screen.availwidth&c=">availWidth</a> and <a target='table' href="/assets/2011/12/table.html?r=android23screen.availheight&c=">availHeight</a> as it did for width and height – although at least that means that the PhoneGap values are now correct! Android v4.0’s browser also reports the same available values as it did for total <a target='table' href="/assets/2011/12/table.html?r=android40screen.availwidth&c=">width</a> and <a target='table' href="/assets/2011/12/table.html?r=android40screen.availheight&c=">height</a>, but fortunately they were slightly more sensible to begin with. But bizarrely the PhoneGap app doesn’t take the status bar height off as it does for v2.3.

And then there’s iOS: it does successfully deduct 20 pixels for the operating system’s chrome. But remember that orientation is ignored! So although a portrait availHeight is sensibly 460 (having dropped from 480), it is anti-intuitively the width in a landscape orientation that is reduced (from 320 to 300) by a bar at the top of the screen!

Quirks on all fronts. Sigh.

`<a target='table' href="/assets/2011/12/table.html?r=outerwidth&c=">window.outerWidth</a>` & `<a target='table' href="/assets/2011/12/table.html?r=innerwidth&c=">.innerWidth</a>`

In contrast to the screen properties, the window properties are understood to refer to the browser window itself. For desktop browsers, (at least, when they’re not running in full-screen mode), the outer dimensions will normally be smaller than those for the screen. The inner dimensions then further deduct browser chrome: window borders, toolbars, status bars, and so on, and so they are normally smaller still.

In mobile, we might expect the outer values to more or less match those for the available screen – since apps run full size. And indeed, with <a target='table' href="/assets/2011/12/table.html?r=outerwidth&c=">window.outerWidth</a>, we have a good news story.

iOS v5.0 uses <a target='table' href="/assets/2011/12/table.html?r=ios50window.outerw&c=">window.outerWidth</a> to redeem itself over the lack of the orientation’s effect on screen. It is 320 for portrait viewing, and 480 for landscape viewing. Bam.

Opera does the same. Bam. Astonishingly, Android v2.3 also nails it. Bam.

In fact, the only small blot that stops window.outerWidth being the model student is Android v4.0 in landscape: the property often has the portrait value of 320 before the <body> tag is reached. However, this is arguably an edge case, and a very minor misdemeanor.

After that rousing news, it’s back to earth with a small bump for window.innerWidth. If your desktop experience had convinced you that innerWidth must be the same or smaller than outerWidth, you’ve now got the TARDIS-like experience of mobile viewports to enjoy.

Without dropping into classic viewport theory here, it’s sufficient to say that WebKit mobile browsers seem to use the boundary between the window’s ‘inner’ and ‘outer’ width and height properties to delineate the world of physical pixels and the world of viewport pixels: the latter a realm where zooming, pinching and tapping allow the mobile browser to sensibly scale web pages designed for much larger screens.

For those pages where the viewport’s behavior is constrained, perhaps through the use of meta tags, this is of little concern, since the mapping of the two worlds is 1:1. And indeed, in our tests, when such a tag is present, <a target='table' href="/assets/2011/12/table.html?r=window.innerw&c=">innerWidth</a> takes exactly the same value as <a target='table' href="/assets/2011/12/table.html?r=window.outerw&c=">outerWidth</a> – modulo the Android race conditions, at least.

Less well-known might be the fact that, for all these browsers, when an XHTML-MP doctype is present, the same is also true. We’ve alluded to this already: the presence of this forces the viewport width to be the same as the physical width of the screen (either 320 or 480), while still allowing subsequent scaling.

And of course, PhoneGap’s default configuration is also to constrain the viewport, so the values there also match.

But when the viewport has not been constrained, and an HTML5 doctype (or none at all) is used, innerWidth will suddenly start to represent values much larger than the physical screen: and represent the width of the viewport canvas upon which the page has been rendered.

On a portrait iPhone, for example, the default viewport is 980 pixels. On a landscape iPhone it is, well, according to window.innerWidth, 981 (yes, really).

Android 2.3 and earlier used a different value of 800 for the default viewport width, and this is exposed as <a target='table' href="/assets/2011/12/table.html?r=android23window.innerw&c=800">window.innerWidth</a> (as well as the vestigal value before document load for the constrained tests). With Android 4.0, the default viewport has been brought in line with the iPhone’s: 980 pixels.

`<a target='table' href="/assets/2011/12/table.html?r=outerh&c=">window.outerHeight</a>` & `<a target='table' href="/assets/2011/12/table.html?r=innerh&c=">.innerHeight</a>`

Mobile browsers normally have no vertical chrome, so apart from the matter of viewports, outerWidth and innerWidth values corresponded relatively nicely. However, they do have horizontal chrome elements: address bars at top, and toolbars at bottom. So we should expect the height to be reduced accordingly.

Opera, in a way, gets this right. We have already pointed out it surprisingly deducted the browser chrome to calculate its screen.availHeight. But since it then promptly uses the same value for <a target='table' href="/assets/2011/12/table.html?r=opera11window.outerh&c=">window.outerHeight</a> and <a target='table' href="/assets/2011/12/table.html?r=opera11window.innerh&c=">window.innerHeight</a>, it meets our expectations on the latter of these two properties at least.

For Android, <a target='table' href="/assets/2011/12/table.html?r=android40window.outerh&c=">window.outerHeight</a> is also relatively deterministic. Again, there are timing wobbles, but after page load, the values are consistently 455 (in portrait) and 295 (in landscape). The Android OS bar, as we’ve mentioned, is 25 pixels.

But it’s iOS that baffles this time. Only in homescreen mode, with an HTML5 doctype (or none at all), does the browser report the expected window.outerHeight value of 460.

In all other cases, bizarre numbers come out. For iOS v5.0, for constrained portrait pages, it’s 356 that becomes 445. For non-constrained portrait pages it’s 356 that becomes 1602. For constrained landscape pages it’s 208 that becomes 667. For non-constrained portrait pages it’s 208 that becomes 1702. In PhoneGap, it’s 460 that becomes 1602, or 480 that becomes 1202. And for constrained homescreen apps, it’s 480 that becomes 1602.

The fact that this is the one property whose values significantly vary from iOS v4.3 to iOS v5.0 also raises alarm bells.

Perhaps we could write a whole blog post to reverse engineer is going on here. 356 and 208 seem to have some plausibility, but apart from that – who knows? There’s no apparent Safari documentation for this property, and even WebCore’s own test suite describes the expected results as ‘empirical‘.

I think I can safely caution you never to use window.outerHeight in iOS and expect a meaningful answer.

After that, window.innerHeight seems relatively stable and predictable. In constrained (and XHTML-MP) scenarios in the regular iOS browser, it sits at that familiar 356 value for portrait and 208 for landscape. This is the actual inner height of the browser window, sans browser chrome, as per documentation. (The fact that these two values are not the same amount less than the physical screen dimensions is due to the fact that the landscape toolbar is slightly shallower than the portrait one.)

This pattern is also consistent when the page is launched constrained from the homescreen or in a PhoneGap application. Here, without any browser chrome at all, the values correctly return to the physical screen dimensions minus the 20 pixel tool bar.

However, this value is not as trustworthy when the page has a non-constrained viewport and an HTML5 (or omitted) doctype. In our test, window.innerHeight had values of 1091 and 425 for the two orientations – doubtless dependent upon the length of the content in our actual page – and hard to predict. As if to prove that point, in homescreen mode, this value increases to 1409. Not particularly useful.

When we look at window.innerHeight for Android, the results appear to follow a similar pattern, but, as usual, are somewhat obfuscated by the fact they change throughout the page lifecycle. For constrained viewports, the two orientations’ values are 401 and 241 in Android v2.3 (where the address bar is 54 pixels high), and 403 and 243 in Android v4.0 (where the address bar is 52 pixels high), and the PhoneGap values are also as expected, considering there is no address bar.

But again, the determinism disappears when the viewport is not constrained, the reported values as varied 1234, 496, 1003 and 402. We can deduce that these are viewport lengths rather than window size, that they are content-dependent, and that they change between platform versions due to the updated viewport width – but again, their utility is more doubtful than in the constrained scenarios.

`<a target='table' href="/assets/2011/12/table.html?r=offsetw&c=">body.offsetWidth</a>`, `<a target='table' href="/assets/2011/12/table.html?r=clientw&c=">.clientWidth</a>`, `<a target='table' href="/assets/2011/12/table.html?r=offseth&c=">.offsetHeight</a>`, & `<a target='table' href="/assets/2011/12/table.html?r=clienth&c=">.clientHeight</a>`

We move onto our final set of JavaScript APIs, and we might hope that we are leaving the vagaries of BOM implementations and entering the consistency of the DOM & CSSOM (although, sadly, these properties are still not under the purview of any W3C standard).

These four values should theoretically be available on all DOM elements: the ‘offset’ dimensions include an element’s content, padding and border, while the ‘client’ dimensions are the content and padding alone. Neither include the margin, as detailed in Mozilla’s documentation.

In our case, we are querying these properties for the document’s body, and, since it has no border, the offset and client values should be the same. Our test pages add a CSS margin of 10 pixels, so on the desktop, we would expect its width, at least, to be 20 pixels less than window.innerWidth. Empirically, desktop browsers seem to use the two heights to represent the total length of the page, rather than the height of the window display. (I’d thought that would be body.scrollHeight, but that’s another story.)

How do mobile browsers fare? How does the viewport concept affect these values?

With offsetWidth and clientWidth, iOS and Android work broadly as you would expect. The non-constrained viewports return measurements in the high 900s (and around 800s for Android v2.3), and the constrained pages in the low 300s (for portrait) and mid 400s (for landscape).

It’s notable how and when the choice of doctype affects these values though. With an HTML5 doctype, non-constrained viewport tests on both platforms report 20 pixels less than the viewport size for both values: 960 pixels regardless of orientation.

With an XHTML-MP doctype, as we’ve previously mentioned, the viewport becomes the device width by default, and again 20 pixels are correctly deducted to give us values of 300 and 460 in landscape and portrait respectively. The same expected behaviour is seen with HTML5 doctypes used on constrained viewports.

What is slightly strange is when no doctype is used. In this case, again on both platforms in all scenarios, the clientWidth is the full viewport width (980, 800, 480 or 320), and the offsetWidth is reduced by the margin (to 460, 780, 460, or 300). This seems systemic: as though the lack of doctype puts the browser into a mode where it interprets the body’s margin as a border.

Across all of our testing combinations, though, the offsetHeight and clientHeight values are the most bizarre set of results in the whole experiment.

There are three patterns on Android and iOS. Firstly, pages with no doctype will always have clientHeight equal to window.innerHeight once the </body> tag has closed – but the offsetHeight will be completely different. Secondly, when there is a doctype, the <a target='table' href="/assets/2011/12/table.html?r=clienth&c=html">clientHeight</a> and <a target='table' href="/assets/2011/12/table.html?r=offseth&c=html">offsetHeight</a> are always the same, and nearly always regardless of what the doctype actually is. (The bizarre exception is Android v2.3 where the HTML5 doctype on the non-constrained viewport causes both values to reduce dramatically at some point after the document load event). And finally, the offsetHeight value of the non-doctype test always produces the same values as the clientHeight and offsetHeight of the HTML5 equivalent.

Got that?

But what the values actually are seems extremely non-deterministic. We’ve already commented on the arbitrary nature of window.innerHeight which the non-doctype results seem to echo. But despite the doctype, orientation and viewport size, the meaning of these values would seem very hard to assess. The best we can say is that when clientWidth or offsetWidth go up, clientHeight or offsetHeight go down (as seems sensible), but that no attention seems to be paid to our 20 pixel margin.

Again, properties best left alone, I think.

In contrast to iOS and Android, which use window outer and inner dimensions as the point of delineation between physical pixels and the viewport, Opera Mobile’s strategy seems to have been to to stay in the world of real pixels until this last <a target='table' href="/assets/2011/12/table.html?r=opera11doc&c=">document.body</a> set of measurements, and finally we get a sense of how it sizes the viewport.

The default viewport width seems to be 850 pixels, but although Opera has, until now, remained oblivious to the pages’ doctypes, the values seem to suddenly be very dependent upon them. With an HTML5 doctype on a non-constrained viewport, both clientWidth and offsetWidth are 830 (which probably has had the 20 pixel margin deducted), and with XHTMLMP, we get 300 or 460 (which would be consistent with a constrained viewport, also minus margins).

But with no doctype and no viewport constraint, in either portrait or landscape, we get 850 for clientWidth (i.e. no padding) and… for offsetWidth, 2048! What?

And finally, as they were for iOS and Android, the clientHeight and offsetHeight are a fairly disparate bunch of values. The only assumptions we can make are that a) constrained clientHeight with no doctype will be the same as window.innerHeight after the </body> tag; that b) clientHeight and offsetHeight for constrained HTML and any type of XHTML-MP will all be the same value for a given orientation (and that non-constrained HTML5 will also eventually converge on that value sometime after the document load event); and c) that the values themselves will be more or less unpredictable.

But perhaps not as meaningless as the offsetHeight for non-constrained doctype-less pages. It’s consistent. But a highly unlikely 40960 – which must surely, more or less, mean undefined!

@media `<a target='table' href="/assets/2011/12/table.html?r=@mediadevice-w&c=">device-width</a>` & `<a target='table' href="/assets/2011/12/table.html?r=@mediaw&c=">width</a>`, `<a target='table' href="/assets/2011/12/table.html?r=@mediadevice-h&c=">device-height</a>` & `<a target='table' href="/assets/2011/12/table.html?r=@mediah&c=">height</a>`

We conclude the menagerie of screen dimensions by looking at the values used in CSS3 media queries. These are used as ‘features’ in declarations which are used to conditionally load stylesheets or apply the rules within them. Media queries are a staple of contemporary web design, and perhaps should be understood by designers as much as the other properties above need to be understood by developers handling layouts.

Finally, we have some properties which are defined by a standard.

Because, for this test, we needed to evaluate these values in JavaScript, we use the matchMedia function and varied the operand until it returned true. This does mean we only have results for those devices which support that API call: namely iOS v5.0 and Android v4.0.

Well it’s nice to end with some good news. In both platforms, in all conditions, @media device-width always returns the same value as screen.width, and device-height always returns the same value as screen.height. There’s no matchMedia support in Opera, but I’ll assume the same would be true.

This is great – but of course don’t forget the main issue afflicting those measurements: the lack of rotated values in iOS and Android 2.3’s wacky 800 viewport value which I’ll postulate may be echoed here too.

@media width and height also track other JavaScript properties in both platforms. @media width is almost always equal to window.innerWidth (except in non-constrained landscape mode in iOS v5 when the former is 980 and the former that curious 981). @media height is always equal to window.innerHeight.

(It’s not so clear whether this pattern would be followed by Opera too, were we able to measure it this way. To confirm, it would require a CSS-based test harness – perhaps another study.)

But there are a couple of things worth saying about this observation. Firstly, the window.innerWidth and window.innerHeight values themselves are something of a bit of a mixed bag. See the earlier discussions above.

Secondly, it’s interesting to note that the matchMedia result changes with page lifecycle in the same way that the regular JavaScript measures do. This may mean that media queries change their results as the page loads – I don’t know how to predict when these parametric CSS rules are evaluated – and I imagine this might create conditions under which certain resources referred to in the CSS, loaded early in the page (when the size is evaluated to one thing), might turn out to have been unneccessary later in the page’s life (when the size is evaluated to quite another thing).

Hardcore browser theory & probably more testing required.

`<a target='table' href="/assets/2011/12/table.html?r=.orien&c=">window.orientation</a>` & @media `<a target='table' href="/assets/2011/12/table.html?r=aorien&c=">orientation</a>`

As a final aside, note that we also measured orientation results. window.orientation returns the number of degrees (0 for portait, 90 for landscape), and is flawless in iOS, and set correctly after </body> on Android. (Just remember not to evaluate orientation before the <body> – it’s likely still to be 0 in landscape mode)

Opera does not seem to support the API.

The media query equivalent is also apparently fine (where measurable). The only Android timing quirk here is PhoneGap in portrait which thinks it’s landscape at first. I guess nothing’s perfect.

Summary

Wow. Painful, on the whole.

Let’s see what we can briefly conclude. I’m not going to go back through each of the properties, but a couple of things jumped out at me.

Doctypes matter – you may have no intention of using an XHTML-MP doctype, but if you forget your HTML5 one, some measurements are affected.
Default viewports vary from 980 through 850, to 800, depending on platform. Be aware that Android’s default has changed between v2.3 and v4.0.
Page lifecycle matters: even if you aren’t stupid enough to run measurement code before the <body>, it can still change radically afterwards, at the document load event, or – most painfully – sometime after that.
- Race conditions seem more common on Android than on iOS – I admit this could also be affected by the poor performance of the platform’s emulator
- Height measurements are probably too nerve-wracking to use – as might be expected. Except in iOS, where you’ll need height to get width.
 - Nothing much is standardized and where viewports are involved, the chaos of interpretation ensues. That matchMedia provides a JavaScript API into the (standardized) CSS3 properties might be a chink of light. </ul> But overall, the message should be: don’t take anything for granted. Mobile diversity is, unsurprisingly, still with us with a vengeance – even for apparently simple things like screen size.
 
 Check out the table again, get a little scared, choose your APIs carefully, and test on real devices* like crazy.
 
 (* yes, yes, I still realize this whole experiment is underpinned by the ultimate sin of using emulators 🙂 )
 
 Thoughts? War stories? Techniques? Fears? Comments welcome.

Bacon Off

Tue, 01 Nov 2011 04:00:38 +0000

Dave Kaneda and I wandered along to the Facebook Mobile Hack last week. We spend a lot of time attending, speaking at, and sponsoring hackathons, but wanted to have a go at getting involved for ourselves. Consider it SenchaCon decompression or something.

The event as a whole was excellent – some great sessions and a strong focus on using HTML5 for mobile apps. Facebook’s new graph API, for example, encourages developers to think about how to semantically describe users’ contextualized activities (how many sedentary web users do you see in this video?). All part of an exciting mobile future for the web’s next decade.

Team Sencha was probably rather too ambitious. But after several frantic hours, we managed something that more or less worked.

Our app was to be BaconOff, a two player game to match actors from your Facebook-liked movies against each other based on their Bacon Number, Top-Trumps-style. The server-side, node.js, hosted and deployed easily to Heroku, and which handles the Facebook authentication, delivers a Sencha Touch app, containing an access token, to the browser. (No doubts at all this can be more elegant and secure).

The first thing the app does is pull a list of your favorite movies from Facebook. Once loaded, each movie record calls imdbapi.com, a wrapper around IMDB’s database, and fetches four actors from each of your favorite movies.

Those actors are then created as a further type of model, each of which has a bacon-number-fetching method. We hoped to use YQL to get the values from Oracle of Bacon, but it was barred by a robots.txt condition. Slightly cheekily, we used our node backend to proxy a request to that server anyway, and then handle the common condition of there being more than one entry for each actor’s name.

In the meantime, and no thanks to me, we had a sweet UI and CSS3-animated loading screen – all Sass goodness from Mr Kaneda of course.

We’d hoped to avoid having state stored anywhere on the server or in the client, using the social graph alone. Eventually we figured it was unavoidable, and quickly had to write a game state storage layer on the server side. It uses a contemporary storage platform known as… the file system. Ahem.

From here on, with time running out, and with a flying visit required to my son’s (excellent!) school play on the other side of El Camino, code started sprawling as we dashed for something demonstrable.

APIs for starting, listing, and playing games quickly followed, and views on the client side emerged to allow competitor and actor selection, as well as the game’s home screen.

We added the Facebook JavaScript library relatively late in the day to allow competitor selection and request; (in retrospect we should have based the whole app around this library from the start – what were we thinking?). And then tried, and failed, to make the frictionless sharing of the game progress post to the timeline: I just couldn’t find the relevant permissions settings in the last 30 seconds before we went on stage. This was a shame, because we’d had the nouns and verbs configured ages before!

At somewhere approaching 1am, we finally got to demo the app, and for those two minutes it more or less worked. There was only one hack required to make the walkthrough work: I’d been working on the assumption that players would be keyed by name, while Dave (and, it turns out, Facebook) that they would be keyed by ID. A small hardcoded line covered that up – albeit at the expense of making every game ever appear to be against Dave himself. With that in mind, I’ll decline to link to a live running version. Screenshots only 😉

So yes, in retrospect, far too ambitious. Hacking time was supposedly limited to 6 hours, and we’d needed a few more than that. I rather wish now that we’d just done a Social Compass app and stuck some avatars on top of a simple webkitCompassHeading event handler or something. We weren’t expecting to win anything (there’s no doubt the well-prepared entries were far superior 😉 ) – and let’s just say that this was an expectation firmly met.

But it was a lot of fun being on the other side of the stage for once. And it’s interesting to see how far you can get on something completely new in a short time period if you put your mind to it. I guess that’s the whole point; code quality be damned…

Taking a new device API for a spin

Sat, 15 Oct 2011 00:30:52 +0000

I love Device APIs, even the non-standard ones. I think they are going to hoist the web up onto its next level of innovation, usage, and ubiquity.

I was pleased to discover that iOS5 includes a new one, tucked away as a new property, webkitCompassHeading, mentioned by Apple on the W3C lists a little while back.

Previously this event’s orientation data was great for relative rotation, but its absolute value was arbitrary with respect to the real world. The new property gives a heading that is meaningful for real-world navigation. (There is also a webkitCompassAccuracy property that tells you how well it is doing.)

So I lashed up Compios5, a small web-based compass application, to show it off. It requires, of course, a real iOS5 device to work. (It’s been tested on iPhone 4 hardware. Should work fine on iPhone 4S. Layouts are probably slightly strange on the iPad.)

The compass itself is created entirely with CSS, with a few programmatically created elements for the labels and arrows. Designers: please issue pull requests to make it look nicer!

The code is here. A couple of implementation notes:

There’s easing on the rotation to make it a little less jerky, but this has to be turned off whenever the compass spins through north. CSS transitions do not wrap-around transforms.
window.orientation needs to be added to the heading so that a landscape view still points to physical north.
Media queries detect orientation so that the compass stays in the center of the screen. It’s not quite stationary on a portrait->landscape flip, but great the other way.

As I said, this won’t work on any device apart from a real iPhone. There’s no way to simulate heading changes in the iOS simulator that I can find. But if you’ve upgraded, or have a shiny new iPhone 4S, please take it for a whirl.

Of Sites and Apps

Sun, 11 Sep 2011 04:43:17 +0000

Users probably don’t care what’s a web site and what’s a web app. But I believe web practitioners should, if only to know when certain best practices apply, and when they don’t.

But does an established distinction exist between the two genres of experience? Not as far as I know. Is it to do with creation versus consumption? Linkability? User experience? Or the architecture underlying the way they are built?

Personally I think there is a way to clearly delineate the two types of experience, but I’m also sure it’s not the only way to do so, and that the distinctions are very likely to vary with individual’s perspective. I’m unabashedly trawling for debate.

<tldr>

There’s one notable result of the disruption that mobile is wreaking upon the way we think about the web. The blogosphere, the conference circuit and various online communities – not to mention boardrooms up and down the country – are abuzz with hypotheses regarding the “One True Way” to do something, the “Dawn of” this, or the “Death of” that.

No doubt I’m a part of this. It’s quite fun. (Although let’s be honest, none of us really has a clue about how mobile’s going to play out eventually.)

In the real world, such binary proclamations are less useful than we like to think. Building mobile and web experiences for real users, real business – and with real constraints of many kinds – is not at all easy. Being buffeted around by voguish black-and-white philosophies (or even the outmoded ones) is of reduced benefit when you’re really trying to navigate the shades of gray in between.

One of the shadiest boundaries to have to consider when using web technologies is that netherworld that lies between ‘web application’ and ‘web site’. As far as I can tell, there aren’t established definitions that help us decide what is one and what is another – let alone a decision tree that developers and designers can follow to decide what sort of experience they should deliver to their users in different circumstances.

On one hand, the differentiation between these two things seems rather academic. If a user can access what I want them to access, and can do what I want them to be able to do, then who cares how we label that experience? It’s the web right? (Stop reading now.)

But again, this belies the subtlety of the real world, and especially in mobile. It’s 2011: iPhone-plus-four. Users want apps. Marketers want apps. Boardrooms want apps. This is, we’ve been trained to believe, the way in which we enhance our phones’ capabilities and access information in elegant, consistent ways. We can assert as much as we want that users should only be using their devices’ web browsers, but apps sell, and will continue to.

Of course, many of these apps are written with native technologies, and distributed via non-web-based stores. This article is not about them: they are likely to become evolutionary dead-ends. But if the web is to succeed as a distribution medium – and as a stack of technology – it will have to rise to match the expectation that’s been set. It will have to provide what is needed to create and deliver app-like experiences, just as well as it can classical site- and document-based content.

The good news is that smarter people than me have long seen this coming. Although much of HTML5 (the markup specification) is about improving the semantic qualities of web documents, HTML5 (the suite of related APIs and technologies) is unashamedly focussed on enabling web applications of increasing complexity. And with browser vendors now competing on such metrics as JavaScript performance and API completeness (rather than how well they support the <aside> tag or somesuch), it seems we should expect to see ever more advanced web apps in the future.

Nevertheless, in frequent discussions about the mobile web, its best practices, and its tools, you’ll hear many arguments qualified with clauses like “oh, but things are different if you’re building an app” or “this is a better technique for traditional sites”. I know, because I do too.

And so, as we enter conference season again, I thought it might be interesting to see if there’s any consensus about what these two things even are, and how we can differentiate between them. What is a mobile web app? And when is it not a mobile web site?

For me, there are a few possible vectors that we can consider.

Creation versus Consumption

Imagine a large structured collection of interlinked documents, where the user is essentially limited to a read-only interaction (give or take the odd comment form or search box). There’s no doubt that such a thing should be classified as a site. Blogs, news sites, academic papers – these are clearly the heartland of the classical web. Online stores too? Probably.

But what about micro-blogging services? Photo-sharing? Online email clients, document editors, IDEs even? Games? It seems debatable as to whether one should classify twitter.com as a site or an app (especially on a mobile device), but I am most certainly using an application when I’m logged into GMail, Google Docs, or playing Angry Birds – let alone working in some web-based data admin interface.

Interestingly, this second category of experiences all seem to be read-write (or at least, highly interactional). So can we classify sites as being read-only and apps as being read-write? That certainly seems simple enough: sites are to consumption as apps are to creation.

Does this feel right? One problem here is that there are some beautiful and enjoyable app-like experiences – Flipboard comes to mind – which are clearly oriented towards consumption. (But then again, maybe the logic is backwards here… perhaps Flipboard is what the web site of the future should look like, though Gawker’s infamous app-like blog felt clunky). And how would you classify Facebook? Entirely user-generated content, but it still looks and feels quite like a site.

Linkability

If you are launching an experience from a desktop or homescreen icon, it is easy to feel that you are in a sandboxed and closed environment whose boundaries are explicit and inescapable. If you start your experience by entering a URL into a browser, conversely, you’re more likely to feel that you are at the start of journey – one where every link clicked can immediately take you to another page or another site or another domain, across the web’s endless interlinked landscape with no boundaries.

So does this serve as a way to distinguish between site and app? Most native apps certainly do have impermeable boundaries: outbound and especially inbound. Even the iPhone Twitter app opens up links in a modal, embedded web view rather than spawning a new Safari window (much to my frustration, at least).

But web apps? Need these be silos? No, of course not. They’re still running in a browser, and (unless in hybrid environment) hanging off a URL like any web site does. There’s no reason for a web app not to contain links that lead you off to other parts of the web, either in new browser tabs or the present one. While reliable deep-linking back into web apps seems to be less commonplace, this is more a function of implementations and browser’s fragmented History APIs than some fundamental flaw in the web’s architecture. (I never shared purists’ distaste of hash-bangs, for example. These are a symptom of developers trying to make this inbound linkability and bookmarkability work for single-page web apps: fixing the web, not breaking it.)

So, like others, I’d definitely hold up linkability as a huge advantage of web apps over native apps – but not as a reliable way to distinguish between web apps and web sites.

User Experience

Another way we might classify apps and sites is by assessing the user interface and experience presented. What are the visual cues that an app’s an app, and a site’s a site?

The use of fixed toolbars is certainly an obvious one: at the top, containing a title and maybe a back button; at the bottom a series of large tab-navigating buttons within easy thumb-reach. This is a UI/UX paradigm that, pioneered by iOS, emerged entirely from the native application world, and which, before 2007, had absolutely no precedent in the classical or mobile web worlds.

Ditto disclosure lists. Ditto sliding transitions between master and detail records. Ditto action sheets, spinners, and momentum-based scrolling. Ditto even the disablement of pinch & zoom on document-like content (controversial to some, and yet understandable if you argue that viewport zooming was merely the browser’s way of dealing with legacy, not-made-for-mobile web content in the first place).

Many developers work hard to bring these platform behaviors in their web apps. And many web frameworks work hard to make it easy for them to do so. (My employer is one of those, of course.) Many rightly blanche at the thought of slavishly mimicking a particular operating system – nothing looks dafter than iOS pinstripes in an Android browser – but the point is that many of these generalized UX characteristics are highly suitable for one-handed, touch-based interactions. No-one will claim that legacy desktop web sites (often replete with tiny mouse-centric sidebar menus and table layouts) can ever match a dedicated app-like user experience. Responsive web sites can indeed improve this greatly, with navigation often flowing to the top or bottom of documents for certain screen sizes. But still, these sites are rarely mistaken for apps.

Because the visual appearance is the “I somehow just know this is an app” argument, and one that users might particularly relate to, I do give the UI/UX distinction a lot of credence. But still, it’s a very fuzzy boundary. What if my site displays a fixed toolbar, but no back button? What if my list looks like hyperlinks instead of tappable disclosures? What if I style plain scrolling instead of momentum? This is a question that the likes of jQuery Mobile have pondered too, in an attempt to follow a site-like, progressive enhancement philosophy. Nevertheless plenty of developers are undoubtedly going to describe the results as apps.

Architecture

So this leaves us looking for a more technical distinction. Is there an architectural, boxes-and-arrows argument that might clarify the difference?

The web we’ve known and loved for almost 20 years – undoubtedly a web of sites! – is unashamedly thin-client in design. Web servers do all the heavy lifting, hosting the storage, business logic, and the construction of the user interface that the user sees. Indeed it is surprising that we’ve had to suffer so much browser inconsistency over the years considering that all they’ve had to do is turn a stream of < and > into pixels.

But the rise of the use of AJAX was a clue that this architecture wasn’t always particularly elegant. A user clicks a link to another page on your site? That might mean a whole set of HTTP connections (again), a blocked server thread (again), a clutch of database connections (again), the execution of a bunch of business logic (again), the generation of a whole new slab of markup (again), and its dispatch back across the wire (again). And that’s all before expecting the browser to re-render the entire user interface (again).

I love URLs, hyperlinks and SEO as much as the next man, but that’s some price to pay to simply display a new record of content.

On the other hand, consider an architecture in which the browser is given far more autonomy and responsibility. Think “AJAX++”, perhaps, where not only fragments of the DOM are elegantly updated, but where the entire application can reside and execute in the browser.

The big breakthrough here, of course, has been HTML5’s storage APIs, which allow JavaScript in the browser’s environment to persist reasonable amounts of keyed data throughout or between sessions. This finally brings honest statefulness to our previously stateless browser clients.

On top of this, mature JavaScript runtimes and frameworks happily allow the creation of robust business logic to be applied to this data. DOM manipulation, made reliable and fast by contemporary browsers (and commoditized by libraries for others) means that you can programmatically construct and manipulate entire user interfaces in the browser – in the extreme case, bootstrapping them up from a <body/>-like document whose main purpose is merely to include a <head> of the linked resources required to execute.

This is the world of the thick web client – or ‘Rich Internet Application’ in slightly out-moded nomenclature. A world in which patterns like MVC can be used again to describing client-side behavior, as well as a server-side technique. With this approach, once a client-side application has loaded its resources and is up and running, it can function more or less independently of the server that originally provided those resources, and creates and maintains a DOM that looks very different to that originally sent in the HTML’s markup.

(One might wish to argue that GMail is really just a site comprising a set of documents. Conceptually, perhaps. But comparing the app’s view-source with an inspected DOM tree will present a dramatically different perspective.)

With perhaps the exception of simple games, these applications nearly always need to bind back to some sort of web-based data API. As required, though, they can then easily cache that offline in their own data stores, greatly increasing the responsiveness and user-experience of the application, and making the prospect of continued offline operation a reality. This is a bold new step for the web. Not the web as constantly humming HTTP-pipes, but undoubtedly the web as stack of standardized, open technologies, working in interesting and evolutionary new ways.

I don’t want to give the impression that I feel this type of architecture should be used for all web experiences, nor even that it’s easier to build. Creating apps this way can be a daunting experience for many. Using imperative APIs may seem like a step too exotic next to the familiarity of declarative markup-based documents generated from a server. Your mileage will most certainly vary, and definitely some sorts of experience are better suited by one approach, others by the other. No binary proclamations implied.

</tldr>

But the point is that perhaps this is the watershed that we are looking for: a relatively clear definition between web site and web application.

The former we can define as an experience constructed on a thick server, delivered, with declarative markup, to thin browser clients, which then render what they’re told. Sprinkle on some progressive enhancement to maximize the user-experience and increase the chances of delivering a suitably degraded experience to legacy browsers.

The latter, on the other hand, is an experience constructed on a thick browser client, from imperative instructions dispatched, probably only once, from a thin server (or, in the case of a hybrid app, even no server at all). The philosophy of progressive enhancement survives – perhaps better characterized as ‘feature detection’ in this programmatic environment – although such apps often assume a certain higher baseline of browser capability. Local storage is utilized, MVC-like patterns are followed, concerns of data, logic and presentation are completely separated, and markup, if present at all, might be used merely for templates to be applied to that data.

So…

…yes, I’m a developer. I think in boxes and arrows. But as a relatively unambiguous classification criteria, this final, architectural distinction works best for me. Assuming you agree that such classification matters at all (in particular to those developing such experiences), how does this suit as a working hypothesis?

Discuss, etc.

Whoops and hashbangs

Wed, 01 Jun 2011 13:12:26 +0000

Three people in the last week have told me I should be blogging more. Flattered, and probably more helpfully than leaving nuggets of half-baked comments on everyone else’s, I’ll do my best.

I dust off the cobwebs by apologizing for a tweet in which I misattributed Scott Jehl. No thanks to strange avatar positioning, I thought he’d made a provocative comment about the destiny of URLs on a post about everyone’s favorite topic, the hashbang.

(Hopefully I’m not the only one who can barely see #1e1e1e on #141414)

It did sound out-of-character from a champion of jQuery projects, and perhaps I was tempted to acknowledge the comment because it seemed such an extreme position from him. Sorry Scott!

But onto the comment itself. Why did I take a shine to it? It certainly takes a provocative stance.

“We are long past the point where URLs have any utility” is strong language. I of course enjoy the benefits of links and URLs myself every day, and I’m sure the commenter does too: bookmarks, links, emailed or tweeted, the ability to return through a browser’s history, open new browser tabs with target content and so on. All very useful. All very cool.

But does this mean that the URL is so sacred we can’t discuss its role and relevance in the real world? Think about whether it’s actually doing its job? Wonder whether it’s productive to shield it from the creative ways in which the web is evolving? And, as this commenter did, consider whether search engines are in fact coping with these changes effectively?

(Heretical to most people… but the sort of thing I like to think about – probably for that reason, actually. And what else are blogs for, anyway?)

So, yes, yes; URLs are used as a key for locating documents and resources across the web. That is all well and good. But I’m thinking; what happens when the web hosts things other than documents and resources? Like applications? Like games? Like physical objects? What happens when we need to serve humans based on other signals, such as their location, the time of day, their context, their intent?

It might just be possible, as the commenter asserts, that a single string-based identifier is not, in fact, sufficient to describe the infinite things that a 21st century, multi-dimensional web can do, offer, and represent.

I’m not completely sure. But I am convinced (and excited) that the web is evolving in these sorts of ways. Client-side applications, for example, seem to be a perfectly valid and compelling architectural way to use web technologies. And yet what role does the URL play there? Obviously as an entry point to the app as a whole, but then what? Does Tim Berners Lee’s plea require me to use a URL to describe every possible state, every view and every data point within it?

Documentistas would have it so. I can’t possibly build anything for the web without every piece of it being addressable like a document. Users must be able to deep-link into any ~~docu~~ state of my application. These URLs must return content to robots too – because where would we be without web crawlers? – and of course it all needs to degrade nicely for legacy browsers and screen readers. In fact, I may as well just fake the whole thing with server-side markup and progressive enhancement anyway. Many do.

But if I’m an applicationista, I create true client-side web applications, probably programmatically. I use little, if any, content-bearing markup, and I provide a suite of complex functionality to users, and pull in content from server- or cloud-based APIs in my own particular way. I acknowledge that my application needs to be accessible somehow, but in the corresponding state machine, the concept of a linkable document can quickly become tenuous, if not entirely inappropriate. Yes, I could conceivably use URLs to describe the finite states of a game of tic-tac-toe. But is there a http://angrybirds.com/level4 ? Or a http://angrybirds.com/level4/just-before-the-red-bird-hits-the-big-block ? Not that I know of.

If this web of applications is our new operating system, I see URLs as our command line switches. They can open apps, and sometimes drop you into well-understood states within that app. But by no means is the developer obliged to let any user reproduce any arbitrary state within it. A desktop developer can choose to let users launch a classic native application with certain pre-defined states – start this tool with a particular file open, for example – but does so in a very controlled and discoverable way. No native OS I know mandates that an application’s command line switches must be capable of describing all of its possible states. So why should the web?

In reality, certain web apps will benefit from deep-linkability, but many do not at all. And just because a large part of the web (the documenty bit) holds URLs self-evident and axiomatic might not mean that a different, growing part of the web (the applicationy bit) must do so too. Nick Morgan, admittedly opining on a subtly different topic, states:

The problem is that because everyone building stuff online is using the same technologies, there can be a tendency to think that there is one true way of using those technologies, independent of what they’re being used for.

And this is the crux. We might all be using web technologies (HTML, JavaScript, CSS and the like), but in radically different architectural configurations, and best practices for some may not be good rules for others. What this touches on might be the primary root cause of the hashbang debate (if not also others): the web is being used in challenging and unexpected ways and we’re finding it hard to re-examine practices and principles that were intended for a different age.

Yes, hashbangs are ugly. A hack. Sometimes they’ll need to be replaced with judicious use of the HTML5 History API. But other times they’ll need to be removed altogether: “it depends“.

But I believe that their usage – and the debate that has raged over that usage – tells us more about the culture of the web and those who create things for it than it does about syntactic purity or semantic elegance. It has shown us that we still find it hard not to think about the web in terms of documents, and that a web of applications can seem strange and opaque. And maybe that we are in a tighter symbiosis with search engine crawlers than we’d like to admit. Is that really what is meant when we’re told we risk breaking the web?

(It might be no co-incidence that our greatest cognitive dissonance occurs when we see something that probably should have remained document-based turned into an application, such as Gawker’s blogs. I notice that the vehemence of this debate never erupted over the non-linkability to arbitrary internal state of my GMail inbox, or to my high score on Entanglement for example. But I’m trying not to miss the wood of the web’s ambition for the trees of one particular implementation.)

Probably drawing ire, or confusion, from most at this point, I guess I leave it there. Please file under ‘verbose trolling’, and yes, for a developer, I’m veering dangerously close to amateur anthropology.

But let me finish with the commenter’s radical assertion that search engines ‘have long given up on indexing the web’ – crazy, surely: they still seem to do a great job with documents.

But applications? I’m not so sure. He might be on to something here. We’ve clearly got a long way to go in terms of describing and indexing application state, purpose and functionality on the web – without resorting to human curation. I’ve heard of these things called app stores, for example…

Mobile, One Web, RWD &c – an unbuffered comment

Fri, 10 Dec 2010 01:22:00 +0000

Jeremy Keith’s blog post entitled ‘One web‘ is good summary of many of the points of view around designing and developing web sites and services for mobile devices. I think he has a staggered commenting system, so I thought I’d share my response here in the meantime. Don’t worry; it’s not inflammatory (or at least, is not meant to be!)

I’m still convinced there’s something bigger going on here.

The (paraphrased) ‘one-url-for-one-document’ mantra is great when the web is one of essentially immutable documents.

But isn’t it time to bust through this assumption? – as we (and even consumers) start to think of the web as being more one of apps? One which should flex and adapt to give the user the best experience (by which I include content, functionality as well as user interface and pixels) possible, given everything we can divine about the human using it?

If an application is to provide the service that its user needs, the more clues about what that human is doing the better. If they are using a mobile device, there’s already a big clue about what that user’s state might be. I’m intrigued by things like Nokia’s Situations project too, as it permits more insight into what the user is doing, where they are, and what state of mind they’re in. Imagine how you might be able to optimize a web experience – to the human – given such clues!

So as you can tell, I’m excited about this. A far more fluid web that is truly responsive like this. Responsive to human context (in all its possible forms) and not just the temporary challenge of smaller numbers of pixels. It’s not that I’m not a fan of RWD – just that it’s far too superficial to help move the web to this higher plane.

However, I also still believe in ‘thematic consistency’, by which the W3C means that the same URL should get you to the same content. BUT that is not the same as saying that the same users actually want to use the same content or that web providers want to give it to them.

In practical terms, this might mean promoting or demoting certain types of content that the designer thinks are more or less useful for users known to be in the mobile context. (I’ve talked about promoting ‘contact us’ from the conventional end-of-secondary-menu to front-and-foremost on mobile sites, for example.)

But why not create entirely separate services? I certainly don’t find it condescending when a user-interface designer has thought about what I actually want to do in a given context. More likely I’ll be thrilled.

And by the way, with this point of view, separate URLs or domains are entirely consistent: “we don’t mind which device you actually use, but you should be aware that the content on our mobile URL is better suited to humans on the move”.

Finally I should add that this is really nothing more controversial than using country-code top level domains. The reason there is an amazon.co.uk is because users in the ‘UK context’ want (or need to be given) different content and functionality. No-one ever complains about detecting IP ranges to encourage users from different countries to go to the best service for their likely location.

I’m a proud citizen of Mobile Web country 😉

A Web of Sync

Thu, 09 Dec 2010 10:22:52 +0000

I’m excited about how the rise of HTML5 (and related technologies) will change the way we think about the web, and how they will further encourage developers to build richer applications instead of mere document-oriented sites.

(At Sencha, for example, we spend a lot of time thinking about what this really means, and how it changes the skills, tools and frameworks we’ll all need to be effective web practitioners)

But here, I’d like to consider three particular changes that are happening, and one particularly overlooked impact they might have.

The first is the rise of powerful application architectures on the client side. Sencha has added Model-View-Controller support in both Ext JS 4 and Sencha Touch, for example, and this makes it possible to implement entire data schemas, rich business logic, and well-structured user interfaces – entirely on the client side. (Other frameworks are following a similar path: SproutCore, JavaScriptMVC and so on)

Secondly, the way in which HTML5 provides support for local and offline storage makes the autonomy of these apps a real possibility. Viewing, filtering and manipulating data can still be performed in the browser, even when completely disconnected from the server (or the entire network, in the case of a mobile device that loses coverage).

Finally, there are the possibilities of being able to use Javascript on the server-side of the web. The rise of interest in node.js, for example, is largely prompted by the opportunity to be able to use the same programming language throughout the entire web stack.

But such changes mean that this stack is changing shape.

Historically, the entire logic of delivering web-based services to browsers was built on the server-side. Databases, security layers, business logic, user interface creation – all of this was within the realm of the web server, and the browser merely took the resulting HTML and dumbly rendered it for the user.

Of course, this is incredibly inefficient: the entire stack is executed (and a whole page of HTML generated) for almost every single user interaction. To mitigate this, web developers turned to AJAX & AHAH to start placing more of the user interface logic in the client’s runtime environment, and to reduce the size of the payloads involved. The stack started to span both the server and client sides of the picture.

But with client-side MVC and support for local storage techniques, we can take this stack evolution a whole step further. With Sencha Touch, for example, an application constructs its entire user interface from scratch, and can synthesize the entire business logic, validation ruleset, and storage schema that would have traditionally been encapsulated on the server side.

Now, islands of independent data on each and every user’s device might make for a useful service, but it is far more likely that most applications will continue to operate in conjunction with a server – which, with the appropriate layer of security to protect access to it, will provide a central storage repository.

Our stack has now been neatly split in two.

(Note that, in the same way that we’ve long learnt to run both client-side and server-side validation of data submitted from HTML forms, it will probably remain wise to mirror business logic on both sides of the network to prevent inconsistency. While the rise of Javascript on the server theoretically makes it possible to do this with one set of common code, in reality, most server stacks will remain non-JS based for some time.)

All well and good. But in one very particular respect, an architecture like this is deeply ambitious. We have added a significant new programming challenge into the mix: and that is one of data synchronization.

When the browser is merely displaying read-only HTML or AHAH, the definitive copy of the business data is one place only: the server. But in this new architecture, we have the same logical data in two places – and, assuming we’re allowing users to interact with their copy of it, quite possibly off-line, we have to deal with the matter of keeping the two (or N) data sets consistent.

At a protocol level, this is simple enough. We can easily use JSON to transmit data bidirectionally over an HTTP wire, and Ext JS and Sencha Touch’s model store classes, for example, take care of all the plumbing for us. But when we should do so, what the payload should be – and how we reconcile any conflicts between client and server – can quickly become interesting design questions.

Consider a web-based corporate price list application, build using a client-side MVC pattern, and providing up-to-date information about a company’s products to its mobile salesforce. On its first instantiation on a mobile device, say, such an application might easily pull the entire list of product records from the server over JSON and store them locally for fast, possibly off-line, access.

So far, so easy. But of course the records might frequently change on the server: the company creates new products, discontinues old ones, and often changes their prices. How should the ‘create’, ‘delete’ and ‘update’ operations be applied to the mobile device’s version of the data? Should it regularly refresh the whole data set again? Should it request all changes since the last sync and then incrementally apply those changes to its local copy? If certain data is not updated for a certain length of time, should the client application mark it as stale?

These are already thoughtful decisions for the application developer to have to make.

But now imagine that the company’s product managers are given more powerful rights within the same application, and they can actually edit the product descriptions on their mobile devices. When connected, these changes can be immediately sent directly back to the server. How can we ensure that other users’ apps can have that change broadcast to them?

What about when the product manager is off-line, perhaps editing the portfolio on a plane? Should the application prohibit updates to the local data? Preferably not, but if changes can be made, how should the application poll to see when it is reconnected, and send those changes back in the most efficient way?

Taking it to extreme, what happens when two product managers edit the same pieces of data? What happens when each have added a new product to which their client applications have assigned the same supposedly unique ID? The system needs to reconcile those potentially conflicting changes – and very quickly this becomes a non-trivial task.

In the broader computing world, these challenges are common and have been frequently, and successfully, addressed. Many proven solutions exist for synchronization in the realms of distributed file systems, versioned source control, disk, database and site mirroring and so on – and even to manage our MP3 collections. But what is new is that this will soon becoming a challenge that web developers will need to tackle, and it is a challenge that might be unfamiliar and daunting to many.

In the general case, of course, there is no single approach that will answer all these questions. Effective synchronization across a ‘split stack’ architecture will depend very much upon the sort of data that is being manipulated and what the application is setting out to achieve.

Frameworks will certainly provide us with all the tools we need to implement the choices we make. But considering these synchronization-related scenarios and use-cases will be an increasingly important part of bringing compelling applications to users in increasingly diverse contexts. Reconciliation will lie at the heart of how we bring complex applications to life – not just an after-thought.

The web is no longer one of documents or of simple uni-directional data: it is fast becoming a web of synchronization. And I fear it might not be as easy as we think. As developers, we all need to go into this new world with our eyes wide open and be prepared for new challenges around the corner.

Sencha Touch + DeviceMotion APIs (= a small plastic toy)

Wed, 01 Dec 2010 12:08:03 +0000

Here at Sencha Towers, we’ve been having a bunch of fun with the new accelerometer & gyroscope APIs in the iOS4.2 web browser.

Rob Dougan has put together a tilt-controlled list and Ariya Hidayat a box of marbles. Both require an updated iPhone or iPod Touch (although Ariya’s also works on a MacBook Pro if you use the Chrome browser).

The APIs are pretty easy to use, and seem to follow the W3C (draft) standards.

I thought I would have a go to, and so I wrote a small Sencha Touch app that mimics one of those small sliding puzzles we all had as kids – but where the tiles are moved not with touch gestures, but by sliding the pieces under gravity.

From a Sencha Touch point of view, I’ve tried to use a best-practice application structure, and both the grid and the tiles are Ext.Panels (which makes them easy to treat in an object-oriented way and, in the case of the tiles, instantiate arbitrarily).

I have set up Ext.EventManager listeners for devicemotion and deviceorientation events, and fortunately, the callback can access the underlying browser event to get the motion-based properties I need.

The tiles themselves are placed on the grid using CSS transforms, rather than top/left positioning, along the lines of:

Ext.Element.cssTransform(this.getEl(), {translate: [x, y]});

This makes coding the sliding movement unbelievably easy: I simply have to change the transformation to where I want the tile to move to, and then

-webkit-transition:-webkit-transform .8s ease-in;

does the gentle slide. Wow. Transitions and transforms have been a spectacular epiphany for me in the last few months.

One catch with web-based tilt control: tip the device more than 45 degrees, and you might find yourself switching between portrait and landscape mode. I don’t know of a way to disable this in Mobile Safari.

The issue with this is that the co-ordinate system of the device’s physical orientation does not rotate, but the web page does. So in my case, I check the window’s current rotation and subtract the appropriate multiple of 90 degrees so that the elements still slide in the direction expected for the device’s physical position.

To test it out, get an iPhone or iPod Touch with iOS4.2 installed. Put the device level on a horizontal surface, go to http://tinyurl.com/ioslide – then tilt the device about 15 degrees in various directions to make the tiles slide.

Also feel free to look at (and be tempted to improve!) the code. Small, simple, and good fun: let me know what you think.

tinySrc is now part of Sencha

Wed, 01 Dec 2010 06:28:37 +0000

I’m extremely pleased to announce that one of my projects, tinySrc, has become part of Sencha, alongside such awesome projects as Raphaël JS, jQTouch, Connect, and InfoVis – as well, of course, as the company’s core products like Ext JS and the revolutionary mobile framework Sencha Touch.

tinySrc has been going from strength to strength over the last 18 months. I think its underlying growth is a reflection of the huge interest in developing for the mobile medium. Mobile web and app developers quickly realize they need to make sure that their graphical experience is correctly formatted for a wide range of screen-sizes and form factors.

There are no intentions to change the API and the way in which the tinySrc runs, so you can continue to use it with confidence.

You’ll see lots of new cool features coming in the future though: the service has some exciting times ahead of it!

CSS3 goes walkabout

Thu, 28 Oct 2010 04:59:10 +0000

Yesterday, Sencha released Sencha Animator: a tool designed to build CSS3-based animations.

Like a few others today, I thought I should get familiar with it, and gave it a whirl this morning. My artistic genes don’t even pass their unit tests… so if I can make something work (admittedly with some help from Preston Blair), then anyone can.

If you have a WebKit-based browser like Chrome, Safari or their mobile brethren, you should be able to see the results of my efforts in an <iframe> below, or on the standalone page:

It’s somewhat scary to know that I’m basically drawing line-art with bordered <div> elements, but certainly it’s fluid and reliable enough on all the appropriate browsers I’ve tried.

I have no idea what it looks like on non-compatible browsers. For now, I daren’t think.

But the same page works like clockwork on suitably (that is, ‘highly’) capable mobile browsers. This screenshot is from the iPhone4 emulator:

Help yourself to my .anim file if you want to use this skeleton for your own animations.

Some say that using CSS3 for animation is going to be a standards-based way to replace Flash, and it may well become so at some point. Others say that it means we’re set for another decade of bad splash screens and corny animations. That may also be true – but you don’t ban paintbrushes just because there are bad painters.

Anyway, for now, I had a lot of fun. I’m excited to have seen a glimpse of what CSS3 Animations are capable of; even if they’re certainly not something I would ever have wanted to craft by hand: view source to see what I mean.

Modernizr on the server-side

Mon, 25 Oct 2010 20:55:00 +0000

The modernizr-server library is a way to bring Modernizr browser data to your server scripting environment.

There are a host of emerging techniques for adjusting web content to suit different types of browsers.

The current vogue seems to be to do as much of it as possible on the client-side: media queries, progressive enhancement, adding CSS body classes, and so on.

These are all cool, and hit a resonance with those who deal entirely with the front-end of a web site, and who prefer CSS (and a little Javascript) to Python, Ruby, PHP and the like.

In my opinion, this approach won’t always cut it. I’ve already pointed out that the users of radically different devices might want downright different things. Sometimes the differences between browsers are just too great to be able to deal with once the page has reached the client. And dealing with structural changes to a site’s information architecture based on browser capabilities gets messy, fast.

(Imagine if my site had a conditional a ‘photo upload’ feature that I wanted to place in the site’s menu for mobile devices that supported it. Do I have to feature test <input type=’file’> on every page, simply so I can add or remove nodes from the menu’s DOM? Ugh.)

So anyway, sometimes it’s far better to have had the server emit the best content in the first place – or at least as close as possible.

With this in mind, I’ve a new project called modernizr-server.

Modernizr itself is a great way to find out about your user’s browser capabilities. However, you can only access its API on the browser itself, which means you can’t easily benefit from knowing about browser capabilities in your server logic.

To address this, the modernizr-server library is a way to bring Modernizr browser data to your server scripting environment. For example, in PHP:

<?php

    include('modernizr-server.php');

    print 'The server knows:';
    foreach($modernizr as $feature=>$value) {
        print "<br/> $feature: "; print_r($value);
    }

?>

The server knows:
canvas: 1
canvastext: 1
geolocation: 1
crosswindowmessaging: 1
websqldatabase: 1
indexeddb: 0
hashchange: 1
...

Exactly the same feature detection is available through this (PHP) API on the server as is available through the (Javascript) API on the client.

Currently, there is only a PHP implementation of the server-side API, but other languages would be easy enough. Stay tuned to the project for more (and let me know what might be a priority, or fork!).

For instructions on how to use, and information about how it works, you’re encouraged to consult the readme. Also this is a young project, so please use in high-traffic production environments with due caution.

Your feedback is welcome! Hope it’s helpful.

Not a mobile web, merely a 320px-wide one

Sat, 16 Oct 2010 04:28:39 +0000

A school of influential web designers are pioneering ‘Responsive Web Design’ as a way to render content on different types of browser screens. They must fix the fledgling technique’s technical faults before it propagates into the wild. And it is certainly not yet worthy of its name: designers must think beyond the glass of a screen and build experiences that respond to the humans beyond it.

A little while ago, renowned web designer Ethan Marcotte wrote an article on the popular web design site A List Apart. This seminal article is titled ‘Responsive Web Design’, and has seemingly been very well read and much admired.

‘Seminal’ because it proposes that sites should challenge many of the established conventions that have been prevalent in contemporary web design: rather than exclusively using a fixed print-like grid, for example, sites should be more fluid and flexible with respect to screen size. (Of course this is how all web pages used to work in the mid-1990s, so the concept’s novelty is probably dependent upon the age of the beholder.)

In case it isn’t obvious, there has never been a single screen size upon which web sites should be expected to render: computer screens and browser viewports have always come in a range of sizes. But now, the obvious logic goes, the big screens are getting bigger, the small (ie. mobile) screens more popular, and a huge host of new browsing form factors – from tablets to car dashboards – are radically reshaping the web’s diverse physical canvas.

By building sites which can respond to these different screen sizes using open standards, the chances of it looking nice on all of, say, a regular laptop, a tablet, a games console, and a 27″ cinema screen are greatly increased.

The real novelty of Mr Marcotte’s argument is not that you should find and remove all the fixed {width:960px} rules from your stylesheets, but that you can use CSS Media Queries to selectively apply styling rules based on certain criteria. This allows you to have a page layout which changes as a function of browser screen size. (The properties available for evaluation in media queries are exclusively related to screen display dimensions and color capabilities.)

Take these two renderings of ‘The Baker Street Inquirer’, for example:

In the narrower example on the right, the title decoration changes, the menu items rise to the top of the page, the images appear in twos instead of threes, and so on.

This looks fantastic. Apart from being a lovely piece of graphic design, viewers also know that this page will look good in their desktop browser whichever size they have it set at, and they won’t have to risk lots of empty space on each side (on a too-large window), or lots of left-to-right scrolling (on a too-narrow window) – both concerns when a browser’s viewport doesn’t match a web designer’s assumption.

Six months on, the fruits of this article are starting to ripen. The good, the great, and the brilliant of the web design world obviously read it and took every word of it to heart. Two oft-discussed examples are Simon Collison’s and dConstruct 2010’s web sites: narrow your browser window on both to see the magic happen.

More recently, Jeremy Keith is notably flying the responsive flag, and has designed a number of sites (and redesigned his own) using a similar approach. Just last week, the mighty Happy Cog launched a very attractive new blog that narrows elegantly, and the talented Mike Kus (with Think Vitamin‘s redesign) has also joined the party.

So, the wheels of evolution turn. Designers are innovating, trying each other’s new techniques, and pushing this worthy idea onwards. They are influencing each other, and in the way these things cascade through imitation, influencing the approach that many thousands of developers who look up to them will take when next asked to design or redesign a site. At this rate, it will only be a few years before more web sites use media queries than don’t. It’s a smart solution, using well-known, standards-based technology, and users with different screens the world over will undoubtedly be happier.

Sadly, this technique is not the revelational panacea that some might present it as. While it copes well with the challenges presented by size-diverse browsers on a desktop, for example, it is flawed when presented as an single solution to the challenge of the mobile web. A more-or-less explicit tenet of the ‘Responsive Web Design’ school is that contemporary mobile browsers are served neatly by this technique, so it deserves to be put under this scrutiny.

Before we go any further, and for the avoidance of doubt, it is thrilling that the ‘mobile web’ has finally garnered some sort of interest amongst the web design community. For a decade, lonely pioneers have been hacking about with little more than monochromatic text on cramped and feeble browsers. Seeing a new wave of talented web artists thinking about the medium is very inspiring – spurred on by the rise and rise of brilliantly capable mobile browsers. Mobile, the historically gloomy little corner of the web, is ripe to welcome fresh and smart ideas – clever and efficient ways to deliver exciting content to mobile users.

Sadly ‘Responsive Web Design’ is not yet one of them.

To start off with, there are some technical and tactical issues. Experienced mobile web designer Bryan Rieger has most notably illustrated these concerns, and strategist Jason Grigsby has explored similar points. Their main concerns stem from the facts that:

Media queries only affect the styling once the markup and other resources have reached the browser. Whatever the device – whatever the network it’s connected to – the browser will download the entire markup of the page, and any (probably large) images in it. Yes, a ‘responsive stylesheet’ can resize media or hide it from the user, but designers should not presume that they’ve done anything to improve the performance or network utilisation by this sleight of hand. Cellular network usage is free in neither the financial nor performance sense. Ironically, Mr Keith’s article about the technique itself has a total size of about 1.6Mb – a payload that no mobile device this side of LTE will sniff at.
Media queries are not supported by most of the world’s web browsers. Certainly all WebKit-based browsers handle them well enough, and most other contemporary desktop browsers do too. But anything else will struggle: this includes legacy desktop browsers (which certainly don’t seem to concern the web’s great and good) and, more seriously, most mobile handsets in the market today.

Both issues are present in Mr Marcotte’s initial expression of ‘Responsive Web Design’. Perhaps understandably: while the exposition of technique focusses on the aesthetic of flexible design, there is little discussion of performance optimization. Further, many of these concerns pale if you’re a designer who lives in a world where everyone has an iPhone 4. Perhaps the article set out to merely present a prototype which the author knew would of course be iterated upon and refined.

Certainly some refinement could be applied to the mathematics, which apparently advocates daft rules like {margin-right: 3.317535545023696682%}!

But thankfully none of these concepts are necessarily deal-breakers: tinySrc (created by this author) allows you to have already dynamically-resized images arriving at the browser in response to a static piece of markup. Mr Reiger illustrates that by rethinking the assumptions about which browser is the default (i.e. a basic mobile one) and which receives the conditional styling (i.e. the clever, or desktop ones), one can mitigate a lot of the problems caused by serving up too many irrelevant resources. That’s probably not entirely what Luke Wroblewski was getting at when he said ‘Mobile First‘, but it’s good enough to work.

Hopefully, Messrs Marcotte, Keith, Kus, Zeldman et al will take these considerations on board and refine their logic accordingly. Theirs is the work that will be widely aspired to and derived from, and this is some basic hygiene that should be encouraged as soon as possible. The practices are not yet best practices – and we should hope that this technique doesn’t become a precedent for playing fast and loose with mobile payloads.

Technical issues aside, the primary concern with using ‘Responsive Web Design’ for mobile web sites remains, and it is far more fundamental.

Firstly let’s look at the name – or at least the origin from which is was purloined. ‘Responsive Architecture’, a term coined by Nicholas Negroponte, is a school of thought that says that buildings and structures should be able to react to changes in their environment, altering their shape or surfaces accordingly. Indeed this is what ‘Responsive Web Design’ does too: change the browser size, and the site within it will respond.

But Mr Marcotte posits that it is also about ‘how physical spaces can respond to the presence of people passing through them’ – in other words, that buildings should react to the way in which humans behave, and implicitly, to what it is that they need or want. This is where the ‘Responsive Web Design’ aspiration falls flat. Nothing about the technique is explicitly related to the human actually using the site, nor his or her context.

The problem of course, stems from the reliance on media queries as the key input to the layout’s alterations. Complex criteria can be built to segment styling based on width, height, orientation or color depth – but nothing else. The design is responding to the glass on the front of the gadget that the user has in their hand – not to the flesh and bone beyond it, where they are, what they are doing, and what state of mind they are in.

In the world of mobile, this matters. The fact that the user has a small screen in their hand is one thing – the fact that it is in their hand at all is another. The fact that the user may be walking, driving, or lounging is yet another. In fact, it’s quite likely that they really deserve different content and services altogether – or, at least, a differently prioritized version of the default desktop experience.

Is this too abstract? Too theoretical? Absolutely not. As a commonplace example, consider the FourSquare mobile web site and its sister web site. The former, of course, is designed as a slick and efficient way to check your location in to the service – and not much else. The latter provides a chance to review previous activity in the comfort of a desktop environment.

Is this responsive? Of course it is – at least in terms of responding to what humans in different environments want to do. The user, by specifying which site they want to receive, gets a design and an interface that is wholly appropriate to their context, not just their screen width. (Sadly, visitors with mobile handsets do not get automatically forwarded to the mobile version of the site, which would have made the service even more ‘responsive’.)

Consider, on the other hand, the St Paul’s School website. It looks lovely and exhibits all the hallmarks of the ‘Responsive Web Design’ school. Resizing the browser window demonstrates the page’s fluid grid, and on a narrow, mobile screen the layout becomes vertical and flows respectably down the page.

But let us just think about the use cases for this web site. Clearly the desktop site is designed to target prospective parents – St Paul’s is a top-notch fee-paying school in London – and the design, menu structure and layout reflect that. The ‘about’ page is first and foremost in the menu, followed by a sequence of pages designed to give the reader an insight into the workings and philosophy of the school. One can imagine well-heeled parents poring over the site for hours, deciding if it is the place for their child to attend and getting a feeling for the institution.

But a mobile user? Let us think about what a mobile user might want from their interaction with the school’s online presence. Are prospective parents so busy that they research making one of the biggest investments in their lives by spending a few moments on a mobile browser? Well, possibly; but it is hard to imagine that reading the school’s lengthy prospectus should top of the list of important mobile use-cases.

If one is accessing this site on a mobile device, there are other far more likely reasons. Imagine an existing parent or student keeping abreast of the (well-populated) school news, or upcoming calendar of events. This is something they might easily snatch a few moments doing in the car on the school commute, say. Or perhaps the user is a prospective parent or visitor who wants to check on the address and location of the school en route, or wants to put a call through to the school office.

Has the design responded to these, now very different, requirements? No. In the mobile display of the site, the news and contact pages are still at the bottom of the menu, below the admissions information and exhaustive list of school sports. The contact page (once you have reached it) does contain telephone numbers, but they have been turned into callable links by the browser’s automatic number detection, not the designer’s hand, so rather curiously you can also click to call the school’s fax number.

And the location page, to get a map and directions to the school? Most of the screen is taken up with an aerial portrait of the school – of arguably marginal help for navigation – and the map itself is only available within a 1.5Mb, three-part PDF document. You couldn’t make this up.

Surely a mobile user deserves and expects a map image embedded in the page, or even a link to Google Maps (which, incidentally, certain mobile browsers will parse to invoke the native map client). Apparently a few of these clever new gadgets have GPS in them.

Responsive to the user’s needs? Barely.

Anyway, the purpose of this article is not a hatchet attack on one particular site. It’s merely being used as an example of how using what is currently called ‘Responsive Web Design’ is often nothing of the sort – or, at best, a single cosmetic tool that needs to be used in conjunction with other, mobile-centric ideas and sympathies.

One gets the sense that those promoting and using ‘Responsive Web Design’ in its current form secretly hope that this is all they will have to do to be able to call their sites ‘mobile-ready’ (although whether that is what they commit to their clients, of course, one cannot say). We should sincerely hope this is not the case. These are smart and insightful individuals: surely they understand that juggling a few pixels around does not amount to designing for different types of user.

Mr Keith in particular appears to understand the dilemma. He points out that ‘I don’t refer to this as mobile optimisation’ and that media queries are not the ‘silver bullet for the mobile context’. Nevertheless, the screenshots of his portfolio sites are 480px in width (conveniently the landscape size of an iPhone), and he is somewhat disparaging about the idea of ‘the rabbit hole’ of creating a different site for mobile devices.

(Of course that isn’t technically required. A small snippet of server logic would have have been all that was required by St Paul’s to move news and contact to the top of a mobile menu, and to replace the PDF link with a Google Maps resource, for example.)

But this may give us a clue why so many others seem desperate to will the current implementation of ‘Responsive Web Design’ into being as the sole way to develop services for mobile users: it’s all client-side, and requires nothing more complex than a few extra tricks in existing CSS files. It may be that many web designers are daunted by the thought that they may be required to think about mobile device detection and conditional logic on the server-side, and are clinging to the hope that they can claim to support mobile users without having to do any, well, programming.

Sadly for those involved, this probably can’t be avoided. It’s not that media queries aren’t an excellent way to resize layouts (of course they are), nor that they don’t act as a reasonable proxy for identifying a mobile devices (which is also more or less true for now) and in turn mobile humans.

It’s a more fundamental issue – which is that any site should be ruthlessly scrutinized for ways in which it can behave in better ways for all of its constituencies of users, and that the differences between those ways are often going to be more significant than can be papered over with some stretchy images and fluid grids on a conveniently powerful mobile browser.

The real fear is that this subtlety is lost on those disciples who want to rattle off a site design that works on mobile devices as well as desktop browsers. The result of their efforts might look lovely on the client’s iPhone, but the speed at which that magic trick was performed will certainly have come at the expense of someone actually sitting down and thinking about what that mobile variant of the experience should actually offer.

The result? We won’t have a mobile web, but merely a 320px-wide one. A web for which the humans using it matter less than the width of the glass it is displayed on.

As a postscript, an analogy: we are in an age which, in many ways, resembles that of the birth of broadcast television. The mobile web is a new medium that, yes, is able to deliver services similar to its precursor, but which can also be developed and enhanced in ways that have yet to be dreamt of. Reflowing today’s web sites for mobile devices is a philosophy akin to that of the first broadcast television programs: “let’s stick with what worked before, and just put well-dressed radio presenters onto the screen”.

Did that work? Sure it did – as a start. But was it these dull talking heads that made television the greatest medium of the 20th century? Hardly. It was when program makers started to explore the visual capabilities of the their new canvas – and the increasingly demanding expectations of the viewers who expected to see something more interesting on the wooden box they had just spent a lot of money on – that innovation occurred.

Today’s ‘Responsive Web Design’ is a lukewarm response to a similar seismic shift – that of the sedentary web into expectant mobile hands.

Our approaches need to be bolder, more structural, more experimental, and, frankly, more considerate of the diverse audiences we should all be trying to cater for.

monomi: mobile middleware for node.js

Fri, 15 Oct 2010 00:26:47 +0000

monomi is node.js middleware that provides tools for handling mobile (and other types of) browsers.

It relies on the excellent Connect layer, and is easy to install with npm.

Currently, monomi analyzes incoming HTTP requests to detect which type of browser they come from. Default values are ‘desktop’, ‘tablet’, ‘touch’, and ‘mobile’ (meaning non-touch), and the type is put into the request.monomi.browserType property.

The order of preference for the detection, as well as the algorithms used, can all be optionally overridden when the middleware is instantiated.

It’s early days for the project… I have plans to allow the middleware to adapt the outgoing content to be appropriate for the detected device – although this needs to be sensitive to the asynchronous philosophy of node.js

Try it, fork it, experiment, have fun.

Google Instant: 37 Golden Tickets

Fri, 10 Sep 2010 21:11:34 +0000

Google Instant provides results as you type. This is bound to keep SEO experts and marketing wonks awake at night trying to figure out what new user behavior it might engender.

For one thing, there are now a small number of golden tickets: if a searcher hesitates for even the shortest time between typing letters, auto-suggestions and results show up… and presumably many searches start with a Latin character.

So I thought it would be interesting to find out what the first suggestions are for queries searching with each letter of the Latin alphabet. And here they are:

A	Amazon	N	NetFlix
B	Best Buy	O	Orbitz
C	Craigslist	P	Pandora
D	‘dictionary’	Q	‘quotes’
E	eBay	R	REI
F	Facebook	S	Sears
G	Gmail	T	Target
H	Hotmail	U	USPS
I	Ikea	V	Verizon
J	JetBlue	W	‘weather’
K	Kohl’s	X	XBox
L	Lowe’s	Y	Yahoo
M	MapQuest	Z	Zillow

Note that only D, Q and W bring up a generic word, rather than a brand name directly. This might seem slightly surprising (since appending ‘.com’ to all these brand names will get you straight to their web site), but entirely consistent with this sort of behavior.

Note that these are not the same as the results brought up if you simply enter a single letter in to the search box. If you simply search for ‘H’, you’ll be told about Planck’s Constant and hydrogen – but if you start to type a search with ‘H’, Google thinks you’re most likely to then type ‘otmail’, and the results show accordingly.

Because of that distinction, I’m sure that SEOing your web site for a targetted single letter won’t help – the suggestions are presumably based on vast statistics about which phrases users end up typing after initial stems.

I also tried the same test on Google’s mobile search, vainly hoping that there might be some sign that people might be looking for different things when they are mobile. Maybe ‘directions’ might beat ‘dictionary’ when on the move, eh? But no: they were all exactly the same – bar one. (Strangely YouTube beat Yahoo on the mobile auto-suggest.)

I am sure this list isn’t curated: one hopes that would have put paid to dusty old MapQuest… But there are a few interesting entries in the list. Do more people search for REI than ‘realty’? (Who are REI?) And is ‘Sears’ really the most popular search starting with ‘S’?

For completeness, here are the top suggestions for single numeric digits:

	007	5	50 Cent
1	14th Amendment	6	60 Minutes
2	24 (TV Series)	7	7-ZIP
3	Nintendo 3DS	8	84 Lumber
4	4chan	9	90210 (TV Series)

And finally, one that made me hopeful for the future of web design:

@	@font-face

Mobile Analytics With Python, Django, ASP.NET, Java, and node.js

Mon, 30 Aug 2010 12:12:30 +0000

A few weeks ago, the PercentMobile team came to me to see if I could help write some new libraries for them. Contemporary web and mobile web sites are written on a vast array of different platforms… and obviously the more that PercentMobile supports, the better.

Something I love about programming is that there are so many languages to choose from – why restrict yourself to learning or becoming an expert at one when the same problems are also being solved in other, sometimes better, ways? Each language or platform has strengths and weaknesses of course. But I believe that understanding the differences – and more often, the similarities – makes one a better programmer.

So, generous polyglot that I am, I took the challenge, and plunged in.

(Sign up for the free PercentMobile service to get the libraries described in this post.)

Python & Django

I love Python – its readability, its libraries, and its overall philosophies. In a web server environment, Python can be used in a fairly raw way, behind a generic Web Service Gateway Interface (WSGI), but there are also a number of powerful web application frameworks using the language – most notably Django. PercentMobile want to provide painless Django support, but also to make sure that other Python server environments were not precluded.

percentmobile.py is the single file that provides everything you need.

If you are running code in a WSGI environment, you will have a handle to the WSGI environment. This is normally called environ by convention, and is passed in to your application via your top-level WSGI callable. To make the PercentMobile tracking code work, you need only make one call to the percentmobile.tracker_cookie_insert function. It returns two values: the cookie that you’ll need to set in the HTTP response headers, and the HTML that you should insert into your page.

Say, for example, you had a very simple WSGI app. This responds to requests with an HTTP 200 status code, a single header and some simple HTML:

def my_app(environ, start_response):
    status = '200 OK'
    response_headers = [('Content-type','text/html')]
    start_response(status, response_headers)
    return ["Hello world"]

To add PercentMobile tracking to this code, you need to firstly import the tracker library of course, and then call the tracker_cookie_insert function:

import percentmobile
cookie, insert = percentmobile.tracker_cookie_insert(environ, '1234555')

(Of course you should replace the final string with your own site ID!)

The cookie return value is actually a dictionary of the different parts needed to construct its string serialization. This will allow you to splice together multiple cookies, or alter the expiry time, path scope and so on. To convert the dictionary to a string, and to get the Set-Cookie header sent back in the request headers, the following code will suffice:

cookie = "%s=%s; expires=%s; path=%s" % (
    cookie['name'],
    cookie['value'],
    cookie['expires'],
    cookie['path']
)
response_headers = [('Content-type','text/html'), ('Set-Cookie', cookie)]

Finally, you need to make sure the HTML fragment, in the insert variable, gets placed in the HTML response:

return ["<html><body>Hello world %s</body></html>" % insert]

And that’s a wrap. The whole, PercentMobile-tracked WSGI application looks like this:

def my_app(environ, start_response):
    cookie, insert = percentmobile.tracker_cookie_insert(environ, '1234555')
    cookie = "%s=%s; expires=%s; path=%s" % (
        cookie['name'],
        cookie['value'],
        cookie['expires'],
        cookie['path']
    )
    status = '200 OK'
    response_headers = [('Content-type','text/html'), ('Set-Cookie', cookie)]
    start_response(status, response_headers)
    return ["<html><body>Hello world %s</body></html>" % insert]

Pretty easy, huh? Well, not as easy as tracking an app if you’re using the amazing Django framework! Contained in the same percentmobile.py file is a class that can be used as Django middleware. It uses the same underlying function as the WSGI implementation, but also takes care of the headers and insertion for you.

Assuming you’ve placed the library file in your Python or Django path, you simply need to add two lines of code in the settings file. Firstly add the percentmobile.PercentMobileDjangoMiddleware class to your list of middleware:

MIDDLEWARE_CLASSES = (
    ...
    'percentmobile.PercentMobileDjangoMiddleware'
)

And secondly, add your PercentMobile site ID to the settings file too:

PERCENTMOBILE_SITE_ID = '1234555'

Um… that’s it. The middleware will intercept the request, figure out the cookie that will need to be sent in the response, create the insertion code, and place it just before </body> in the response. You’re golden. I love Django.

ASP.NET: C# & VB.NET

Switching over to another world altogether, let’s take a quick look at the ASP.NET implementation of the tracking code. One of the great things about .NET is that you can choose between all sorts of different languages to write your applications and pages in. I decided to write the tracking library in C#, but you can use it declaratively in your page code, or programmatically from C#, VB.NET, or any other supported language.

The library is implemented as a User Control – that is, as a .ascx file. You need to download and add PercentMobile.ascx to your web application project.

To embed the tracking logic into a page (or probably preferably, a master page), you simply register the user control as residing in that file:

<%@ Register TagPrefix="pm" TagName="Tracker" Src="~/PercentMobile.ascx" %>

And then embed the control straight into the .aspx file contents, wherever you want it to be:

<pm:Tracker runat="server" SiteId="1234555" />

So a simple, tracked .aspx file might look something like this:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Register TagPrefix="pm" TagName="Tracker" Src="~/PercentMobile.ascx" %>
<!DOCTYPE html>
<html>
    <head><title>Hello World</title></head>
    <body>
        <form id="form1" runat="server">
            <div>Hello World</div>
            <pm:Tracker runat="server" SiteId="1234555" />
        </form>
    </body>
</html>

To be honest, this is so simple that I would expect most people to use the control declaratively. But if, for some reason, the control needs to be inserted programmatically, that’s pretty easy too. You need to use the Reference directive, instead of Register, at the top of the file, but otherwise it’s not much harder. Here, we’re using VB.NET to programmatically achieve exactly the same result as above:

<%@ Page Language="VB" AutoEventWireup="true" %><%@ Reference Control="~/PercentMobile.ascx" %>

<script runat="server">
    Private tracker As PercentMobile.Tracker
    Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs)
        tracker = CType(LoadControl("~/PercentMobile.ascx"), PercentMobile.Tracker)
        tracker.siteId = "1234555"
        form1.Controls.Add(tracker)
    End Sub
</script>
<!DOCTYPE html>
<html>
    <head><title>Hello World</title></head>
    <body>
        <form id="form1" runat="server">
            <div>Hello World</div>
        </form>
    </body>
</html>

(It should be fairly straightforward to see how to do this in other .NET languages – PercentMobile includes some examples in their install instructions.)

Java

Onwards. Let’s take a look at the tracking code for Java. There are numerous ways in which Java can be used for web or application server environments. To keep things simple, I decided that supporting JSP was more or less the most familiar and reusable approach.

JSP doesn’t enjoy the rich page event model that I was able to use in ASP.NET to intercept headers, write cookies, and insert HTML, all with one include. <jsp:include> is OK for adding the HTML snippets, but wouldn’t let me access the HTTP headers. <jsp:forward> does, but would only work if you weren’t planning to emit any HTML of your own after the tracking code – something of a radical assumption.

So I settled for an approach where an include directive creates an instance of an inner PercentMobile class defined within the JSP class. To cut a long story short, this means you merely add a reference to the library file at the top of the JSP file:

<%@ include file="percentmobile.jsp" %>

And then call the track method on that instance, somewhere within the page:

<%percentMobile.track("1234555");%>

The included JSP file takes care of instantiating the percentMobile object and giving it references to the request and response stream. This means it can read and write cookies, and later emit HTML. Your tracked Hello World in Java then? It’s as simple as this:

<%@ include file="percentmobile.jsp" %>
 <html>
  <body>
    Hello World
    <%percentMobile.track("1234555");%>
  </body>
</html>

node.js

OK, OK. Python, ASP.NET, Java. No big deal, right? That’s all so 2003 or so, right?

Well, there’s an alternative future for web server technologies. It’s one that’s blazingly fast, lightweight, event-driven, and… where you write your server logic in Javascript.

node.js is one of the most exciting things I’ve seen for a long time, and I know I’m not alone. Fresh, fashionable, and somewhat unproven, admittedly, it’s had a lot of gushing coverage. But since it turns the web server model (almost literally) inside out, I do believe there’s something important going on.

Would it be possible to write a web app with node.js and still have it tracked by PercentMobile? My challenge.

I decided to rely on Connect, a middleware framework for node.js, which, if you are writing web applications, provides a whole host of other helpful web logic. Using Connect to create a simple node.js app is extremely easy:

var Connect = require('connect');
Connect.createServer(
  function (req, res, next) {
    res.simpleBody(200,
      "<html><body>Hello World" +
      "</body></html>",
      {
        "Content-Type": "text/html"
      }
    );
  }
).listen(88);

To add PercentMobile tracking to this application firstly requires you to pull in the PercentMobile module:

var PercentMobile = require('./percentmobile');

(Where the percentmobile.js file has been placed in your node.js environment or in the common modules location.)

The module needs to be initialized as a piece of Connect middleware in the createServer function:

PercentMobile.init('1234555')

There are then two module functions, cookie and html, which both take a reference to the response object, and which return the cookie string and HTML to insert, respectively. These can be used in Connect’s simpleBody function, for example, meaning that our tracked application is as simple as this:

var Connect = require('connect');
var PercentMobile = require('./percentmobile');
Connect.createServer(
  PercentMobile.init('1234555'),
  function (req, res, next) {
    res.simpleBody(200,
      "<html><body>Hello World" +
        PercentMobile.html(res) +
      "</body></html>",
      {
        "Content-Type": "text/html",
        "Set-Cookie": PercentMobile.cookie(res)
      }
    );
  }
).listen(88);

That’s a wrap

So that’s it. A whistle-stop tour of the new languages and frameworks supported by PercentMobile. I’d love to hear your feedback on how easy (or hard!) these new APIs are to use.

And, oh… who will be the first to build a mobile web app on node.js? 🙂

WhitherApps

Sun, 08 Aug 2010 08:40:20 +0000

Why spend your life recompiling native client apps when you have HTML5 and the mighty mobile web at your disposal? WhitherApps sets out to debunk some contemporary mobile myths.

WhitherApps is a bandwagon-busting experiment. I believe there are far too many native client apps which could have been far better written as mobile web apps. What I’m trying to do with the project is take a few particularly obvious examples, apply a little reverse-engineering, and rewrite them, warts and all, with web technologies.

I’m focussing on native client apps that are free to download. These wouldn’t have suffered commercially had they been written this way in the first place. Obviously, I’ll also focus on feasible genres of apps. No 3D games or background apps, for example. To start with, informational media apps (such as newspapers and broadcasters) will be in the spotlight.

But otherwise, I may not need to pull too many punches. Offline access? Through the wonders of HTML5, that should be OK. Native device API access? Well, BONDI and proprietary libraries permitting, I’ll have a go – and there’s always PhoneGap too.

Each post on the site will be a walkthrough (or part of a walkhrough) of the process. As I get my hands dirty, from the protocol-sniffing to the pixel-jiggling, you can follow the steps I took.

Stay tuned and wish me luck!

Mobile Trends 2020 – a brief review

Sun, 10 Jan 2010 04:05:26 +0000

A curious affliction of the mobile blogosphere is its propensity for annual predictions about what will happen next in our industry.

It’s a badly-kept secret that this frustrates me. Mostly because:

A year really isn’t a very long time, whatever the cliché tells you… very little surprising happens in 12 months an industry dominated mostly by large companies and continuous market dynamics.
It doesn’t take a lot of research into any topic to be able to make a handful of sensible predictions about it. (Flat rate tariffs more common? Really? I should think Antarctic will thaw quicker than last year too, and there will be progress in HIV research.)
They’re rarely actionable. I’m unlikely to buy shares on such vague tips, and I can’t wager against their accuracy at my local bookmakers. Do these lists exist to bolster the reader’s wealth or knowledge? Or perhaps demonstrate how perceptive the writers think they are?
Wouldn’t it be better to spend the same effort actually helping to make the future come true in the first place? 🙂

But this week saw the publication of a collection of 40 or so pundits’ predictions mobile trends for the coming decade. Should I dislike this 400 times more? Well, fortunately no! Ten years gives more room for the predictions to breathe, and the collective nature of the project should mean broader trends can be spotted.

The document is curated by Rudy De Waele, for whom I have lot of respect. He’s got the enthusiasm and boundless energy that fits well with the promise of mobile. It must have taken a fair bit of effort to pull this project together: a set of slides containing the predictions from a large number of contributors. The document has already been very successful and well circulated. And there are some very clever people involved.

In choosing the contributors, Rudy describes them as his personal ‘mobile heroes’. Fair enough – but how has that affected the overall roundedness of the project? This, to me, is potentially a worry.

For example, it might have been interesting to have heard from at least one handset manufacturer. This will be a decade of bitter rivalry in that market between the old telecoms guard and already-successful new entrants. Exciting times: and I would love to know what the contenders foresee? And only 3 network operators? However conservative their ambitions, the networks’ plans and predictions are quite likely to shape mobile’s decade somehow.

Facebook is a good scalp – although not as revealing as I’d hoped – and so are the financier contributions. Most of the remainder of the contributions are from small startups, bloggers, authors, entrepreneurs, ‘strategic thinkers’ and ‘keynote speakers’.

Now, I have nothing against such individuals (since I know many of them, they’re very smart, and that’s how I’d probably describe myself too!). But having so many casts a slight pallor over the project: the patina of the developed world’s well-trodden mobile conference circuit. Punditry that’s been trotted out for years: affluent, Western, urban- and professional-centric reflections of how we’d like the industry to fulfill our own personal use-cases.

This is a shame. I wanted this document to surprise me more. The entire world – economically, politically, climatically – will change a lot in ten years. I would expect the mobile medium will flex to adapt to those seminal changes far more interestingly than it does to some tactical contemporary challenges.

In the same vein, a missed opportunity may have been to look further abroad. True, there are valid mentions of mobile’s cultural impact in Africa, but try keyword-searching the document for ‘China’, ‘India’, ‘Brazil’, ‘Russia’ (or even ‘Japan’!) and you’ll be out of luck. Who thinks nothing of interest will happen in those places in the next decade? (Now that would be a surprise).

This all made the predictions, a little, erm, predictable. Yes, yes, I think we all know battery technology will improve, but who was brave enough to make predictions like this?:

most mobile web sites in 2020 will be in Chinese
at least one major European operator will have been bought by an Indian conglomerate
the Rio De Janeiro Olympics’ web site will have more mobile visitors than non-mobile
Google’s home page will default to being mobile in all countries except the US
roaming agreements will be used as collateral in carbon trading markets as the mobile-wielding populations of low-lying countries are resettled

Crazy? Sure. But these are just off the bat. I think the aims of such a project should be to inspire, question and provoke. Don’t give me some short-term platitudes about app stores and widgets. At least not when history is on the move like it will be in this decade.

OK, so perhaps I’m protesting too much. Despite these flaws, there are some real gems to be found in this document. “Digital syllogomania” is a brilliant piece of insight. A few touch on the very likely “always-on backlash”, and the promise of mobile-device-as-sensor is tantalizing. I also applaud those predictions that wonder whether mobile technology can change basic human behavior. I’m doubtful, but it’s a good question. As Tom Hume asks: “What happens to conversation when it’s all recorded, or any fact is a 5-second voice-search away from being checked?”

Anyway, it’s a few days old now, but do go read the document here. And more importantly, make up some of your own. Even more importantly, go and try make them happen. “It’s good to talk”, but the mobile world in the next decade probably belongs to those who make. And those who make the predictions come true.

The WordPress Mobile Pack is back! And here’s how.

Sat, 19 Dec 2009 00:43:09 +0000

Just a quick post to confirm that the WordPress Mobile Pack plugin is back online at wordpress.org.

Most WordPress plugins, if ‘GPL-compatible’, are hosted on wordpress.org – it provides an easy way for people to view and upgrade them. The increasingly popular Mobile Pack is no exception, and we’ve been happily listed there for over 6 months.

But what do you do when it suddenly disappears?

About 3 days ago, that’s exactly what happened. I’m the administrator of the plugin and could see it when I logged in. But suddenly none of my collaborators – nor the general public! – could see or download the plugin.

Our sole channel for software distribution had mysteriously dropped into a black hole – without a word of notification from WordPress themselves.

Assuming it could only therefore be a bug with the wordpress.org web site, I filed a number of support tickets. No response.
Assuming it could only therefore be a permissions or licence issue, I raised a number of forum threads on the site (as, kindly, did Dennis Bournique, over at WAP Review). No response.
Assuming I was somehow falling between the cracks, I even emailed Matt Mullenweg. Less surprisingly, no response. UPDATE: I received an apology shortly after this post.

Hmm. All rather unsatisfactory.

Well, this morning, a breakthrough. My WPMP partner in crime, Andrea Trasatti thought of joining the WordPress IRC channel. (Obviously he’s a bit more old school than me). But finally found someone who would be prepared to answer the puzzle.

At this point, I need to point out there there are (true!) other mobile plugins out there. One particularly popular one has been Andy Moore‘s. He hadn’t hosted his on wordpress.org due, I guess, to his choice of license, and his – disclosed – use of automatic ads in the resulting pages, which WordPress does not permit.

For whatever reason, Andy recently closed down his plugin’s page, and had kindly redirected it to ours. This probably accounts for our nice increase in traffic in mid-November. Thanks Andy!

However, one of Andy’s previous plugin downloaders apparently complained about an error message they had received. The WordPress administrators investigated by visiting Andy’s site, and of course got redirected to our Mobile Pack page. Thinking our plugin was at fault, they then disabled our plugin for violating the no-ads rule.

Oh, and no-one thought to drop me an email to tell me.

But Andrea’s investigations and protestations prompted us to get re-approved, and we’re back!

(In the process of investigating this, it also turns out that when WordPress says ‘GPL-compatible’ and points you to a list of licenses, that doesn’t mean much at all. You also have to work out that they actually mean ‘GPL2-compatible’, and not ‘GPL3-compatible’, as our more permissive Apache license is. So I guess we’ll have to change our license too – which is a shame.)

I don’t think WordPress covered themselves with glory here. In the interests of constructive criticism, I would suggest the company should:

Inform a plugin owner whenever there is a complaint raised against it. I would have been able to point out the complaint was aimed at a different piece of software.
Inform a plugin owner when – or better, before – disabling a plugin from the listing. I could have had a grace period to have investigated any issues, rather than hear it first as complaints from users.
Respond to ‘site bug’ tickets raised on the site.
Make the licensing requirements for plugins more clear. The phrase ‘GPL-compatible’ here, (and its link), is certainly not precise enough.
Remember that plugin authors work hard to support your business of running the most popular blog platform in the world. Those individuals’ reputations, to a fair extent, rest on your responsible syndication of that code, and they get the grief when you pull the plug.

Anyway, thanks guys (and Mark in particular) for putting it back. And special thanks to Andrea, who now overtakes me in the chocolate-for-favours race.

Now… back to the roadmap of Mobile Pack coolness. Stay tuned.

WordPress Mobile Pack v1.1

Wed, 15 Jul 2009 10:14:09 +0000

The dotMobi WordPress Mobile Pack is a complete toolkit to help mobilize your WordPress site and blog.

We just launched v1.1, compatible with the latest version of WordPress. Download it, read the changelog, read about the features in full, or even join the team.

The plugin includes a mobile switcher to select themes based on the type of user that is visiting the site, a selection of mobile themes, extra widgets, device adaptation and a mobile administration panel to allow users to edit the site or write new posts when out and about.

Features include:

Mobile switcher to detect mobile visitors and provide an appropriate experience
Base mobile theme for quick-and-easy XHTML-MP compliance
Extended mobile themes so you can unleash your mobile creativity
Transcoding and device adaptation to optimise the mobile experience
DeviceAtlas integration for world-class adaptation
Mobile admin panel for when posts can’t wait
Mobile ad widget to make you some money
Barcode widget to help users bookmark your blog

I have a lot of fun writing this plugin and there’s a bunch of cool ideas we have for the future. Check out the Assembla project to see the work as it happens – and maybe toss us some new ideas too.

It’s always a work in progress, but thousands of users seem happy enough so far. See what you think…

Simple ‘on-server’ mobile AJAX in Django

Wed, 17 Jun 2009 11:30:52 +0000

–or–

“How your mobile site may not be much more complicated than building one with a data API or AJAX”

I am working on a project called ‘IvyRoot’ that is predominantly mobile and which is going to make me fabulously rich and famous.

OK, OK. It’s predominantly mobile, at least. It’s all in Django.

There’s a ‘desktop’ web site to go with it, and this contains panels within pages. Some of these panels might take a few moments to process and so I use XHR to call back to get them once the main page has loaded, displaying a pretty spinning icon in the meantime.

I also use XHR to populate in-page tables which might have many rows – so that pagination and sorting are fast without having to load the whole page again.

I also want to expose a number of data APIs (providing XML, JSON, basic HTML and the like) so that people can build 3rd party clients, their own consuming sites, and widgets.

Finally, I want to provide a mobile web version of the site. I’ll probably do some sort of device detection to refine the behaviour, but I should assume that plenty of browsers will not be able to do the XHR bit, and should have the page (containing all the panels) in one go – admittedly after a slightly longer wait.

Well, it occurs to me that these requirements can all be solved at the same time. Switching templates based on URL (or other HttpRequest clues) is pretty easy, so one thing I could do is have a filename extension convention for all my URLs. Imagine a ‘things’ view that lists things.

http://ivyroot.com/things – this is the human-consumable page: the view surrounded by menus, logos, graphics and the like. Knows how to switch outer template, based on various things, between desktop and mobile.
http://ivyroot.com/things.html – this is the table at the heart of the page, perhaps using unstyled markup containing the list of things itself.
http://ivyroot.com/things.xml, http://ivyroot.com/things.json etc – data APIs that list things in various serializations.

So perhaps we can set up URL routes like this:

...
(r'^things$', things),
(r'^things.(?P<mode>[a-z0-9]+)$', things),
...

And have a view that looks something like this:

def things(request, mode=''):
    if not mode:
        mode = desktop_or_mobile()
    template = "things.%s" % mode
    ...

(Or, I suppose we could pass the mode into the template via the context and have some sort of a switch statement in the template itself. It might be good to pass it in, anyway, in case there is any further refinement required within each template.)

Anyway, let’s also assume that the things list is very long and takes a while to generate. For the desktop users, we might want to either load the table as HTML asynchronously using XHR, or paged into a jQuery grid control. For these two approaches, I can call back to /things.html or /things.json respectively (and do a little extra plumbing to make sure the JSON is in the right format for the grid control to consume).

But what of mobile? Well, for many devices, I can’t expect any XHR activity to be supported, so we need to insert the table HTML into the body of the things.mobile page before it departs for the client – and we may need to pre-page it too (if it’s long). But the good news is that, if I made it simple enough, the HTML generated by things.html might be good enough for either type of browser.

(And if not, I could easily do a little adaptation on that view too – perhaps turn my table into a list.)

So what I would like to have a is a way of embedding the output of one view (or even URL) into another, whilst the response is still being put together on the server. Try as I could, there didn’t seem to be anything in Django to do this.

Enter my first DjangoSnippet!

This basically allows me to put a template tag into the mobile template that pulls the output from one of the other views (identified by view name, with arguments; or a verbatim URL which would be the same as the one used in the desktop’s XHR request – nifty!)

It also makes sure that the context for that view is sandboxed with what it needs to render itself – so that I don’t have to worry about getting the context ready in the ‘outer’ view. That’s not necessary in our simple example above – but it might be useful later on if I am dynamically choosing which panels to place on a page, and I want them to gather together their own context prior to template rendering.

Now, I’ll need to be careful to make sure that any interaction elements within the table – say, some actions available on each item in the list, or a paginator – behave suitably for their location. But this may be as simple as toggling between further XHR requests (for desktop) and simple anchor links (for mobile). Forms-in-panels will be harder but similar.

So… there we are, a glimpse at the inner workings of a mystery application that’s many weeks away from seeing the light of day.

But hopefully I’ve raised a few thoughts about how you can treat the mobile version of your site as being a cousin of the data APIs that you might have written anyway. And also how you might be able to sneakily bring some of the funky XHR – that you wanted to impress your friends with on the desktop – up into the server to keep your mobile pals happy too.

Maps & mobile

Tue, 07 Apr 2009 17:29:44 +0000

I’m somehow dissatisfied with mobile cartography.

On the Hollywood Walk of Fame site, we’re currently using Google Maps. When I first saw Google Maps on the web, I was thrilled with the cartography. The craft of good map-making started to shine through after a decade of turgid MapQuest vectors.

(In a previous life, I lived for maps… so I take this very seriously!)

And on HWOF, sure, it does what it should. The now-familiar style has a comforting effect for users I suppose.

But, both with and without the ‘mobile’ option set in the API (shown on the right – worse I think!), and despite the huge watermark on the limited real-estate, I’m personally tiring of it.

Maybe it’s the burnish of familiarity. I’ve seen this style so much that it holds no allure or beauty any more. Maybe because it appeals more to drivers than pedestrians. Maybe because of the uninspiring Arial font. Or maybe just because I’d like to be more in control? All of the above.

Anyway, I’ve started to look at alternatives. On one hand we’re looking at some commercial possibilities with other map (and location data) providers.

But on the hand, I’ve been sucked into the thought of using CloudMade. Built on top of the excellent OpenStreetMap project, it allows everyone to become a cartographer – or at least, to apply new themes and styles to the map structures from OSM.

A great example? Check out Matt Jones’ lovely map:

Which, interestingly, immediately made me think of John Speed:

Nothing new in the world, eh?

Anyway… this is now interesting. I’m no graphic designer, but I’ve done my fair share of map-making. I do know how to make important features rise to the foreground. And make irrelevant aspects fade to the back. Serve specific purpose. A map is not just a dry record of geographic fact: it should be created entirely with the context of the user in mind.

Hey! Just like mobile web applications.

So I am on a crusade to in find the perfect mobile map. A cartographic style that jumps out of a handheld screen. A visual vocabulary that caress a mobile user’s spatial awareness. Maps that blend seamlessly into the device’s user interface, rather than merely rectangular crashups. A panache that brings vectors to life. That crosses the boundary into art.

And that can do so, effortlessly, in 176 pixels or less.

The world is full of brilliant maps of many kinds. But do any of them cut it in the mobile medium? Is that medium so different that we have to start again with some of our cartographic assumptions? Will I ever be satisfied?

Well, I don’t know yet. But I do know that I’m going to have a lot of fun fiddling with CloudMade.

What’s your favourite mobile map, cartographic style or service? And why?

New blog design & apologies

Sun, 29 Mar 2009 23:05:02 +0000

Welcome to my new blog theme. It includes a pseudo-portfolio for my various mobile activities in 2009.

I had to generate some new resumé-style posts and they probably all showed up in your feeds. Sorry.

If you’re on the new site, I hope you like it.

If you’re reading this on RSS, maybe it appeared above.

Well, now we’re back on track.

The site now serves as much as a business card as it does a blog… but I will try to put the occasional post up to remind you that I’m still alive. Well, outside of Twitter and JaJaJeEv anyway.

By the way, I’m quite please with the favicon.

Mobile & Web Sites

Sun, 29 Mar 2009 22:02:21 +0000

I help run the Hollywood Walk of Fame web sites for desktop & mobile: HWOF.com & HWOF.mobi.

I run metajam.mobi. With 14m page-views per month, it’s a surprisingly popular mobile web site.

Also launching sometime this year: vumi.mobi…

Developer Tools

Sun, 29 Mar 2009 21:39:42 +0000

I co-wrote dotMobi’s DeviceAtlas with Andrea Trasatti, and created the interactive Data Explorer.

I led the ready.mobi team, and have a mobile WordPress plugin ready for release soon. I just launched an image resizing service.

Development Communities

Sun, 29 Mar 2009 21:05:04 +0000

I like to try to help my fellow mobile developers.

You may vaguely remember WAPtastic from 1999. Then AnywhereYouGo.com. Then Argogroup’s DevZone.

But the mighty (neé dev.mobi) was also one of my babies, and is still going strong.

Data into Information

Sun, 29 Mar 2009 19:45:33 +0000

I like to use data and graphics to tell stories.

For Argogroup, I built BoxOffice, a reporting and analysis platform for large-scale monitoring systems.

The dotMobi KPI platform uses registry data to track domain trends. And I think I have another one in me.

Living the World

Sun, 29 Mar 2009 19:08:48 +0000

I like to move about – and so do my family. I’ve lived in the UK, New Zealand, Sweden, Australia, and most recently a happy two years in Ireland.

Now we’re in Nashik, India – and excited to live in one of this century’s rising superpowers.

The Day Jobs

Sun, 29 Mar 2009 18:10:43 +0000

Most recently I’ve been CTO at dotMobi, and previously the same role at Argogroup.

My telecoms heritage comes from Sema Group and AnywhereYouGo.com. And the obligatory management consultancy at Ernst & Young.

Playthings & Personal

Sun, 29 Mar 2009 13:17:46 +0000

JaJaJeEv is my family blog: photographs by my talented children and a few from me.

SquigglySquares provides barcode fun, using a QR-code API and a slab of jQuery. TwitterLap lets you see how Twitter users’ followings intersect. It’s quite popular.

Python Google AdSense for Mobile code

Fri, 20 Mar 2009 20:27:21 +0000

I was amazed to discover that Google don’t currently support Python as a language for their mobile ads. AdMob doesn’t either (thinking it’s more likely that people might use perl or VBScript for a contemporary web site).

But it’s a particularly strange omission for Google, since it’s one of their three ‘official’ internal languages (together with Java and C++), and because their Google App Engine platform mandates it. Do they assume that no-one would create a mobile application in their cloud?

I don’t know – it’s probably just left-hand and right-hand out of sync.

Anyway, The Hollywood Walk of Fame mobile site has been a recent hobby for me, and I chose Django on Python for a bit of educational fun.

It was going well until I decided to throw some ads onto it.

So of course I needed to port the ad code. It’s very simple, although cuts a few corners (this does not support AdSense’s custom colour feature for example):

def google_ad(request, publisher_id, format='mobile_single'):
  scheme = 'https://' if request.is_secure() else 'http://'
  params = {
    'ad_type':'text_image',
    'channel':'',
    'client':'ca-mb-' + publisher_id,
    'dt':repr(floor(1000*time())),
    'format':format,
    'https':'on' if request.is_secure() else '',
    'host':scheme + request.META.get('HTTP_HOST', ''),
    'ip':request.META.get('REMOTE_ADDR', ''),
    'markup':'xhtml',
    'oe':'utf8',
    'output':'xhtml',
    'ref':request.META.get('HTTP_REFERER', ''),
    'url':scheme + request.META.get('HTTP_HOST', '') + \
          request.META.get('PATH_INFO', ''),
    'useragent':request.META.get('HTTP_USER_AGENT', '')
  }
  screen_res = request.META.get('HTTP_UA_PIXELS', '')
  delimiter = 'x'
  if screen_res == '':
    screen_res = request.META.get('HTTP_X_UP_DEVCAP_SCREENPIXELS', '')
    delimiter = ','
  res_array = screen_res.split(delimiter)
  if len(res_array) == 2:
    params['u_w'] = res_array[0]
    params['u_h'] = res_array[1]
  dcmguid = request.META.get('HTTP_X_DCMGUID', '')
  if dcmguid != '':
    params['dcmguid'] = dcmguid
  url = 'http://pagead2.googlesyndication.com/pagead/ads?' + urlencode(params)
  return urlopen(url).read()

I presume I’m allowed to do this, I know it’s only 15 minutes saved – but if it helps someone, great. No warranties – but it works for me!

Incidentally, in Django, I am placing this in a context_processor so that it gets put into a template variable that I know will turn up in every view when the site is in mobile ‘mode’. I use a switcher like this to toggle between http://hwof.com and http://hwof.mobi.

Hm. This post looks terrible in this theme. I think I need to change WordPress template soon.

A mail I couldn’t send

Mon, 09 Feb 2009 16:43:30 +0000

After someone I respect got banned from the WMLProgramming mailing list, I wrote to agree with one or two other members who were disappointed with the state of affairs.

I’ve been a member since, I guess, the first few weeks of the group’s existence – even if I haven’t been a day-to-day contributor. Sadly it’s gone downhill over the last year or so.

Why? It’s a long story. The mobile developer community has a desire to have a strong position on unprovoked content transformation. This is a good thing.

But the approach taken to get their message across involves some of the most inflammatory, derogatory, and unprofessional behaviour I’ve ever seen online. This is not a good thing.

I was disappointed that the reputation of the group was sinking so low. It also occured to me that, as a member, this behaviour was implicitly in my name.

But not for long! I was promptly banned from the group. Well, I suppose I was leaving anyway, so maybe it was no big deal.

But shortly after, a rather rude mail was written in response, making some outlandish claims about some corporate conspiracy I’m supposed to be part of. But could I respond? No! I’d been banned. I guess to make sure you get the last word, the best way is to limit the other party’s ability to respond.

So anyway, I don’t really want to labour the point. But here’s what I wrote as my last post to the group and couldn’t send – thanks to the membership button being grayed out.

After all that fruitless typing, and in the interests of free speech, I just feel it needs to see the light of day somehow 😉

—————————————-

Luca,

You do indeed deserve huge thanks for the many years of hard work and success. The manifesto and it could have been a memorable agent for good on behalf of the industry as a whole. It may still become so.

I fully admire your goals, but with them comes an attitude that ruins the external reputation of the group – and the chances of those goals ever being met. Further, the reputation of the group is projected onto its members.

That is why I’m leaving. This brand of militarism does not represent my broader interests in the growth of the mobile web.

Let me also state clearly that my opinions about the situation have absolutely nothing to do with my recent employer or its investors: I’m sorry to disappoint you, but there really is no conspiracy.

I hope that one day this famous list will return to being positive and friendly again.

(Doubtless you’ve more positive and friendly things to say on the matter too. But since you banned me, do note I won’t be receiving further replies.)

James

So What Happens Next?

Wed, 31 Dec 2008 12:47:39 +0000

So, my wife has a new job in India. We’re leaving Dublin to have a flavour of life in the sub-continent. It was a dilemma to figure out how to fit this in with my own career.

After much deliberation, we figured that it wouldn’t really be possible to continue my current role of CTO. As well as the traditional CTO-like activities (evangelism, slideshows, strategy, whiteboard death-match), I’ve also been leading the, now quite large, development team at dotMobi. Doing that properly needs someone nearby, and not offset by five-and-a-half hours. So the CTO (aka VP Technology) role is now in the hands of a very able replacement – there’s certainly a world-class team to continue the good work in Dublin.

But the good news is that I’ll still be involved with dotMobi, despite my geographic and temporal displacement. I’ll be consulting for the company as VP Emerging Technologies – which makes me a sort of a one-man research team. I’ll be slightly decoupled from the engineering activities of course – but, because there are still lots of innovative things that the company needs to do, I can make the most of my slightly remote perspective by pushing those inventions forward.

There are a couple of things I’ve got in mind. Firstly, I’d like to to help understand how dotMobi’s existing tools can be better used. I’ve got a DeviceAtlas WordPress plugin up my sleeve, for example – and I think there’s lots more we can do to make that platform easier to use in familiar runtime environments. We’d like to push DeviceAtlas further in the area of AJAX and CSS support. I expect I’ll rattle off a few posts for mobiForge. And I expect I’ll also be chipping in some ideas for Instant Mobilizer.

Although it will be a change not to be in the office every day, bouncing thoughts off everyone else, I think I’ll be very able to see these projects through without too much day-to-day distraction. Of course we’re a heavily connected team, so (Indian broadband permitting) I’ll still be able to stay in touch via Skype, email, Twitter and so on.

Co-incidentally, I’m pleased with the word ’emerging’ in my role as I think will be wholly appropriate for my locale. We’ll be in a place called Nashik, a few hundred miles north-east of Mumbai. It’s small enough not to appear on most maps, but it’s got a population of 1.5 million or so. India of course, is emerging as both an economic and mobile phenomenon, both in the cities and rurally, and I think I’ll be well placed to watch these developments unfold.

What do I mean by by mobile phenomenon? Well I don’t know what that means on the ground yet – but I do know the country’s been gaining something like 10 million new subscribers a month. (That’s the population of Dublin every, um, working day). As well as the staggering numbers involved, I fully expect to discover that these millions of newly-connected mobile users are using the medium in exciting new ways. And surely many of them won’t already own a PC: so mobile web usage is undoubtedly going to feature heavily.

But I don’t really want to say too much about what I think I will see and experience – I know it’s going to be a huge adventure, but I also know that most of my assumptions (whether about the local mobile market or India in general) will be wrong. I’ve been a few times on holiday, but this is an altogether different kettle of fish, so I’m going with an entirely open mind. My Twitter account and blog are a blank canvas upon which I will try to describe what I see, smell and observe once I get there. (I’ll endeavor to keep a regular ‘mobile letter from India’ going).

Anyway, all in all, it’s daunting, but the situation looks like it will work out well. I’ll be spending more and more time researching some of the technical challenges that face the company – and the mobile industry as a whole – and hopefully coming up with some innovative solutions and neat technology. I’ll be able to see, first hand, a completely different side to the evolution of mobile communication, and I’m looking forward to blowing some of my Western preconceptions out of the water. Finally, of course, I’m hoping this will be a great experience for my children – who, after all, will consider India to be one of the major world economies when they are my age.

So, as of next week, good bye Europe (for a little while) and stay tuned!

Two Years @ dotMobi

Tue, 30 Dec 2008 21:42:29 +0000

This New Year marks my second anniversary of being CTO at dotMobi.

I’m making a big deal of this because, as of Thursday, I won’t be CTO at dotMobi. My wife Jayne, has landed a marketing job at a vineyard near Mumbai in India, and both of us, together with our two young children, are emigrating to live there.

Everything changes. So humour me. Rather than endless industry predictions you’ve been reading everywhere else this week, I’m going to indulge myself in a retrospective.

In my next post I’ll talk about what’s happening next. (Clue though: I’m not leaving the company!)

dotMobi was a fairly different place when I joined two years ago. The .mobi domain name had recently gone on sale, the company was focussed on being a domain registry, and most of the company’s technical capabilities were outsourced. But not entirely. Ronan and Ruadhan, who were both incumbent technologists when I arrived, had already started developing early versions of the developer community and the ready.mobi test tool. And through the work of Jo Rabin, the company was keenly supporting the mobile work of the W3C too. The seeds had been sown for the organisation to be able to play an important role in the mobile world – as well as for the domain community – and that’s why I took the job. During my two years, I’d like to think we stayed true to those ambitions.

Looking back, I spent relatively little time on the domain registry business per se – when I did it was mostly evangelism, blogging, and a bit of data mining. Of course we like to articulate why a mobile URL or domain is important if you want to let your users choose their experience via their address bar, and how you can use such a trustworthy mobile domain in conjunction with your existing web properties.

But dotMobi has other missions. For example, we want to help designers, web developers, marketeers, and businesses appreciate the potential of the mobile web as a whole. I’m passionate about the role that mobile will play in our on-line lives of the future, but I also recognise that someone’s got to actually build it. Given my recent career, it was natural that that agenda would shine through – and that’s been a large part of my work. With its highly reputable investors (not to mention a decent cashflow from the domain name business), the company’s uniquely placed to offer assistance to mobile developers and other companies throughout the ecosystem. It’s able to solve some nasty problems that would be unrewarding for, say, a more financially-backed company to undertake.

The hassle of mobile handset diversity, for example, is a huge pothole in the mobile web superhighway. We felt dotMobi had an obligation to help fill it in for the good of all the travellers on such a road. And so was born DeviceAtlas: designed to become the world’s leading database of mobile device information. I was lucky enough to be able to recruit WURFL founder Andrea Trasatti to the team in the summer of 2007, and convince him that dotMobi was the place to build such a thing. We launched just over 6 months later, and, although it’s a work in progress of course, we’re thrilled by what the team have created so far. (I still suspect it might end up being what we are all remembered for in years to come).

ready.mobi has also changed hugely in the last two years. It’s gone from being a fun little mobile rating tool to becoming an important part of many mobile developers’ toolkits. We’re supporting thousands of testers every day from around the world who are committed to producing quality mobile sites. With full site testing now available, and the recent release of a machine API, it’s never stood still. It remains the tool that many people know dotMobi for most.

The jewel in dotMobi’s crown is undoubtedly its developer community mobiForge (nee dev.mobi). Well over 20,000 developers regularly turn to the site for a stream of high quality material about the state of the mobile development world. Editor Ruadhan, together with all the team members and authors who contribute, deserve the credit for this. (I merely pull a few levers and press a few buttons behind the scenes; plus the occasional article). Sister site mobiThinking is also starting to make real strides.

In 2007, one of our major, if left-field, projects was find.mobi. At that time, we thought that mobile search was really an unsolved problem and that a lot of traditional search companies didn’t really understand mobile – and what mobile users want. (Hint: it’s not mangled PC web sites). Since we had to crawl an awful lot of .mobi sites for compliance reasons anyway, we started crawling other top-level domain sites as well, looking for made-for-mobile sites to flesh out a contextually-targetted directory and search service.

The technology is clever and at the time the UI was pretty unique: as an experiment it was very worthwhile. Not surprisingly, we weren’t able to give it the love and care it needed for a consumer launch. Also, incumbent services have improved since then. But… well, I still think mobile search is unfinished business: there are still some exciting possibilities being explored for the find.mobi technology.

Another technical excitement this year was the purchase of Mowser from Russell Beattie and Mike Rowehl. They’ve moved on to other things now, but the Dublin engineering team have been pouring effort into its reincarnation, dubbed ‘Instant Mobilizer’. Yes, it’s a transcoder that takes non-mobile content and adjusts the syntax to better suit a mobile device, but it comes with a few twists.

Firstly, it’s an opt-in service: small businesses for example can subscribe to the service instead of having a new site built for themselves. Secondly, we don’t just perform markup gymnastics to hack a site to pieces: we also enhance pages with additional services that might be useful for mobile users. Thirdly, we don’t think that transcoding non-mobile sites is a particularly satisfactory end-game for the industry anyway. This, if you like, is a taster service that can open businesses’ eyes to the possibilities of mobile – but one which, if it does its job well, will help to promote the advantages of building mobile services properly subsequently.

Anyway, Ronan’s been leading that project, and it’s due for a launch in the New Year, so I’m not particularly due any credit! But it’s very neat, and keep an eye open for it in months to come.

I’ve had a fantastic couple of years living in Dublin. The city’s been warm and welcoming to both me and my family. Professionally, the city has been a great base for the company. Although it’s been hard hiring world class people, we’ve always made that a non-compromisable priority – and I’m really happy with the large, talented team of mobile-centric engineers that we’ve cultured. Outside of the technical team too, there’s a great team of people at dotMobi overall. It’s always been a pleasure to work with smart, international colleagues from across all the disciplines: Neil, Trey, Paul, Amy, Norbert, Vance – and many, many others.

The last two years have seen dotMobi play a more mature, supportive role within the mobile industry, and it has broadened its brief from domain names to many other, perhaps more altruistic, activities. I won’t ever be able to say that the mobile web has taken off because of us, or because of the small part I personally played – but I certainly know that when it comes to mobile, I’ve been in the most exciting place at the most exciting time.

In the next post, a bit more about the next chapter of our lives.

Plans, projects, places

Wed, 26 Mar 2008 22:09:30 +0000

It feels strange blogging these days. Everything appears to fly past on Twitter instead.

But just an update on some things going on here. Firstly my movements, recently and soon:

Mobile World Congress, Barcelona (it was OK)
SXSW, Austin (not much mobile zeitgeist, and I felt old)
A family skiing holiday (amazing snow for late March)
CTIA in Las Vegas (my favourite city, ahem… but Mobile Jam will be cool)
WWW2008 in Beijing (4 years since I was there last – will I recognise it?)
MoMo Summit in Malaysia (2 years, but ditto)

There’s certainly no shortage of mobile-related shows on at at the moment. Plenty of gigs containing the words “mobile”, “web”, “2.0” again this year. I think there are another two Spring events in London that I’ve missed from my list – and after all that I know I’m still, sadly, missing another sponsoree, Over The Air.

Secondly, things going on at dotMobi and elsewhere:

DeviceAtlas (launched last month, roaring success, 1,000 users already, yes I wrote some of the code)
Find.mobi (none of my code! but try flight codes and currency questions…)
Dev.mobi (going from strength to strength…. 10,000 users)
http://447867554666.mobi/ (and similar… interesting idea, no?)
MetaJam (already paying some of the household bills; thanks AdMob!)
HotTwit (a bit of malformed fun; probably could do more with it)
IvyRoot (not even ready for prime-time on my own brain yet)
Erlang (a solution looking for me to find a problem for)

So, I guess this blog post is sort of an almanac of what’s going on in my life, circa Q1 2008.

If you’re at any of the upcoming events above, I’ll see you soon. If you have any comments on these various projects, let me know 🙂

Mobile Monday x 2 tonight

Mon, 10 Mar 2008 14:50:58 +0000

I am speaking in Austin (as a satellite event to SXSW) alongside Taptu and BlueFlavor. Should be a very good one.

And on the European side, Andrea is doing Barcelona, where the subject is mobile travel. Also set to be a great evening.

If you’re going to either, one of us will see you there 😉

I am in Private Eye

Sat, 08 Mar 2008 21:15:20 +0000

This is an odd feeling: Standing in line for security at O’Hare… Idly reading Private Eye… Turning to page 27… WAIT a minute! That looks familiar! I wrote that!

Yes, yours truly has the dubious honour of having made Pseud’s Corner.

For those of you not familiar with the aforementioned organ, Private Eye is a satirical UK magazine that has a regular spot where outrageous quotes from the pretentious and precocious are paraded. Authors, actors, art critics and such like.

This week, a mobile CTO!Seems the editors look a shine to my Mobile Monday Barcelona introduction.

OK, so maybe it was a little heavy on the rhetoric, but still… I get to share this (perhaps dubious) honour with Fay Weldon, Ozwald Boateng and A.A. Gill – so it can’t be entirely bad.

What’s on a mobile CTO’s desktop?

Wed, 20 Feb 2008 16:39:02 +0000

Along the lines of “how to [..] feed your CTO“, and “N things you didn’t know about blogger X“, I was staring at my cluttered desktop, wondering what it all means.

Featuring…

A variety of development tools (Eclipse, Visual Studio, MySQL, Wireshark, FTP, SCP, JMeter scripts, a JSON parser)
The Android SDK
Portions of a mobile web book I am writing
Slideware for various products & projects
Domain analysis results
An Ubuntu ISO image and an Apache install
An OPML file of mobile blogs
My registration form for MWC
A JPG helpfully named “graph”
A bunch of browsers
The hiring plan for my team
MetaWeb Query Language documentation
Mobile Monday Dublin’s Peer Awards application forms
Two mysterious text files called “yes” and “no” (?!)
Some social network clients
Something to listen to
Armadillo Run
…and a folder named “temp” – where all this rubbish is shortly headed.

Yes, that pretty much sums up the last 3 months of my life. What’s on your desktop – and why?

My obligatory MWC write-up…

Sat, 16 Feb 2008 14:12:36 +0000

…but I’ll keep it short. That I can so easily tells you everything you need to know about the show.

There’s a lot going on at the the Mobile World Congress, and of course there are lots of sub-markets and sub-industries being represented. But the thrust of the show is pure telecoms. Device and infrastructure vendors trying to wow network operators.

Everything else (in particular, hall 7, complete with porn and prayer room) is really just a side show. However important you think content provision are, you can guarantee the telecoms world doesn’t.

So, on that basis, the show was rather disappointing.

If the handsets launched were supposed to be some sort of comeback, then Cupertino will sleep easily. That side of the show was dominated by one company – who didn’t even turn up – and I thought everything else was utterly underwhelming. (At most I might see myself with an X1)

And on the network side, I’ve rather lost track. The acronyms are getting farcical. Too long for me to remember which ones are which, and which ones are actually synonyms for something else. So forgive my naive conclusion that there was little news there either.

In previous years, the implicit message from GSM was “We are the Masters of the Universe”. This year, there’s nervousness. This is an industry that knows it is about to be disrupted, but doesn’t quite know what to do about it.

On a personal note, the show was most notable for the number of virtual folks I finally got to meet: James Whatley gets special thanks for finding me a personal mobby. After days of being locked in with analysts and journalists, it was nice to come out blinking into the sun and meet people who speak my language 🙂

My MoMo Peer Awards Introduction

Mon, 11 Feb 2008 14:26:41 +0000

I was lucky enough to be invited to speak at the introduction of this year´s Peer Awards in Barcelona.

I hope it´s not to precocious to post the conent of a three minute speech! As it happened I deviated a fair deal, but the spirit was about right. 🙂

——–

Hello Barcelona. And welcome to you all.

We have an amazing afternoon ahead of ourselves. An amazing venue. An amazing city. An amazing organisation team, and of course amazing people. You know, this is not Mobile Monday Barcelona. This is Mobile Monday The World.

I feel honoured to have the chance to welcome you all today. To see such a talented collection of individuals in one room together – all under the banner of mobility – is truly exciting to me. Somehow I feel we are coming of age.

It is so easy to forget what the mobile industry is all about. Yes, its economics are very enticing. Yes, its trade shows are awe-inspiring. And of course the technology is always mind-blowing!

But it’s not really about any of those things. Our industry is about something else. About communication. And communication is about people, human beings. You might call them “users”, “subscribers”, “audiences”, or “eyeballs”. But they are human beings.

In fact you could say that the mobile world is the ultimate social network. One day it will be the size of the entire species. A vast and intelligent network of human beings. Our fellow human beings, wherever in the world they are.

And I have no doubt that that mobile environment must be used for good.

It is the human beings in this room that are making that happen. You, your friends and your colleagues around the world, are

the creative, disruptive, and pioneering force that must lie behind the grand mobile ambition.

All I am going to say about dotMobi is that we are here for no other reason that to help you realise that ambition.

What I see in front of me today is not a safe and lazy industry. You are not faceless brands, multi-national monopolies, or sanitised and defensive incumbents of some dull grey ecosystem.

No. You are the mobile mammals. You are the individuals, the entrepreneurs, the artists, the merchants, the craftsmen and women, the smart, ambitious, bright young things of all our mobile tomorrows.

So. The next time you are rewriting your business plan again or pitching your startup to yet another jaded investor, the next time you are up at three in the morning writing software to launch the following day, the next time you are in a sales meeting, telling sceptical potential customers that you have what it takes – I’ll be there with you. We’ll all be there with you. We’re a community. The Mobile Monday community.

And we have got what it takes.

And you do know that we are doing something quite special, don’t you? Nothing less than the formation and refinement of an entirely new medium. The reinvention of communication for the whole human species. Somebody in this room might be doing something that can change the human race, and that can change the world to make it somehow a better place.

That is a huge privilege and a huge responsibility. I trust we all take it very seriously.

Nevertheless, that is why this afternoon’s competitions are going to be very exciting. Good luck to you all and thank you!

Changing the world… two products at a time

Sat, 09 Feb 2008 00:21:10 +0000

Wondered where I’d gone? Thought we’d been a bit quiet at dotMobi for a little while?

Sorry 🙂

Next week is the Mobile World Congress in Barcelona. And if you’re blogging, you can’t also be flat out trying to release something seismic for the mobile world.

DeviceAtlas. A huge lump of tarmac falling from the sky to fill in that huge pothole in the middle of the mobile superhighway (the one labelled “too many damn devices”). And Find.mobi. Start all over again and re-imagine search for mobile from the ground up. What would it look like?

Any idea of how involved these are? I only just realised I’m doing an introduction at the MoMo Peer Awards on Monday.

If you’re one of the 1,000 people waiting for email from me, don’t panic. I am alive. Just. (“Yes! We found the memory leak!”)

Sleep can wait. All coming soon. I’ll see you next week.

A Mobile Democratic Dilemma in Dublin

Fri, 01 Feb 2008 18:30:56 +0000

Dear Mobile Blogosphere, your advice please.

I run Mobile Monday in Dublin. We put 4 local mobile startups up for vote for nomination to the MoMo Peer Awards in Barcelona. Final results were as follows:

3G Doctor, 6 votes, 4.51%
Nubiq, 6 votes, 4.51%
Sentry Wireless, 118 votes, 88.72%
AdCafe, 3 votes, 2.26%

Now obviously, there’s a fairly comprehensive win for Sentry Wireless. However, we also had about 120 new members to the group in the last 24 hours, and there’s a decent correlation with the voting.

On one hand I welcome new members! On the other hand, I’m not sure that this results accurately represents the balance of our traditional membership. Quite a few of the new subscriptions immediately unsubscribed.

I now feel a little like the UN trying to make sense of a country’s democracy after failed elections. Should I …

A) Leave the poll results as they stand

B) Void the results of anyone who joined after the poll was announced

C) Put the vote back out to the 9,000 members on dev.mobi

D) Make my own independent professional judgement based on the applications

Two things I have learnt about the Irish

Tue, 29 Jan 2008 22:12:06 +0000

1) They seem to love politics, and 2) throw great parties

TechLudd this week exhibited the best of the latter and the worst of the former.

Whether or not you think it’s fair to veto events that others are working hard to put on, far more impressive was the bar brawl that followed, weeks before the thing had even taken place.

And – in a brilliant piece of politik and self-promotion – the critics manage to take credit for the changes that were made to result in the resounding success.

So I am about to slag off next week’s MobileMonday. I think I can then take credit for it being a great event.

(Which is my way of saying “see you there”…)

“How to care for and feed your CTO”

Thu, 10 Jan 2008 23:12:46 +0000

This doing the rounds (thanks to ceo), which of course makes me wonder what type I am.

Well, my golf is certainly not up to scratch, so I think I’ll plump for a blend of the first and second.

I think it’s phrases like “neither nocturnal nor diurnal”, “temporally ambiguous”, “drawn towards alpha software like a moth to a flame”, and “prototypes that they quietly whip up and surprise the company with” that seem to ring true with my life.

Oh and a “whiteboard deathmatch” sounds like fun.

Er. Guilty.

Predictions for 2008, yawn. Must look further.

Mon, 07 Jan 2008 23:22:44 +0000

It must be time for more obvious punditry from the augursphere.

“2008 will be the year of mobile data, flat rates, Apple & Google phones, mobile advertising… blah blah blah”

No kidding.

Me? I just got back from holiday and I’m chilled in a rum punch sort of way. So no frantic soothsaying from me. But I had one interesting prefiction for a few years out.

Can you imagine a day when Google Maps for Mobile becomes their primary search interface?

(Oh. Don’t forget you heard it here first 🙂 )

The Ultimate Social Network. Step 1.

Wed, 19 Dec 2007 07:50:47 +0000

Having often claimed that (mobile) telephone networks are already the ultimate social network, I’m trying a little experiment.

http://447867554666.mobi/

Having a personal page tied to my mobile number seems like a good way of eternally tagging myself.

So this page sort of acts as a mobile business-card / vCard / shared-items / presence / personal dashboard.

(I currently pull in RSS feeds and my Jaiku presence to give you the idea)

But imagine if… browsers had access to contact lists, and contact applications could launch browsers… now that’s interesting. I could even see operators providing such sites to discourage churn.

Ha ha! Maybe just a bit of fun. But if not, you saw it here first 🙂

When politics blows up the semantic web

Tue, 18 Dec 2007 07:33:55 +0000

– or –

“Don’t vote for Hillary; it might break FreeBase!”

Bush hid the facts

Thu, 06 Dec 2007 21:58:13 +0000

If you are lucky enough to run Windows, open Notepad, type “Bush hid the facts” (without the quotes), and save the file.

Open it back up again …indeed, the facts are hidden.

(NB: I find this completely amazing. Why the hell would it do this?)

.mobi auctions: Music, Games, Sports, WTF?

Wed, 05 Dec 2007 22:55:26 +0000

Results in from the latest domain auction at Sedo:

music.mobi – $616,000
games.mobi – $401,500
sports.mobi – $101,000

Very exciting. This proves that there’s significant economic heat building up in the mobile web. A medium starting grow up.

It’s a shame that some people will undoubtedly whinge about the fact that this is pretty amazing income for something as simple as a domain name.

But most importantly to me, and, I hope, to the entire mobile community, is the fact that this is helping fund all the other stuff we do. It certainly doesn’t feel like money for nothing.

Ever wondered who pays for the essential dev.mobi, ready.mobi and …Device Atlas? Answer: the bidders in these auctions. And we’ll continue to do our best to make the community benefit from it.

(and PS: yes, we will be making sure these winning sites are .mobi compliant)

How can I get out of this house without going anywhere near your garage?

Sat, 01 Dec 2007 02:31:07 +0000

Inspiring stuff (in a way)

And thanks to (http://opengardensblog.futuretext.com/archives/2007/11/the_anti_portfo.html) for the link.

Mobile Monday Dublin… The Christmas Do

Tue, 27 Nov 2007 17:44:40 +0000

We have search specialists Taptu coming to Dublin to present and sponsor our December meeting. Thanks guys.

And for anyone else in the Dublin or London area who would like food, drink, mobile conversation and Christmas cheer (as well as this year’s hottest news in mobile search), please see more details here, sign up here, or simply mail me.

See you there!

dotMobi staff sites hit the big time

Mon, 26 Nov 2007 22:47:58 +0000

Following our little competition last week, we’re amazed to learn that 6 of our sites have been selected for the “Best of the Internet” section of one of our national operators’ portal.

Well, that was just in our spare time. I wonder what we could do if we really tried.

(Although I do wonder what that says about today’s mobile web… 🙂 )

I did my part and updated MetaJam.mobi. It now includes musical artists and albums along with movie and actor pages. And I’ve earned a healthy 68 cents on AdMob already. Bling!

The dotMobi Site Building Competition

Thu, 22 Nov 2007 23:18:27 +0000

The folks at dotMobi are a fairly creative bunch, so we thought it would be fun to run a site building competition amonst the staff.

Competing in two categories – my engineering team vs everyone else – the staff were all in the running for two shiny iPhones. Plus, of course, the opportunity to try and avoid bricking them on Irish networks.

The competition has just finished. All in all, not bad work for a few weeks of our (little) spare time.

A quick fanfare for Ronan Cremin (of http://find.mobi fame), who built quite simply one of the coolest – or should I say most useful – mobile apps I’ve seen in a long time. SVG maps! PNG trains! MP3 dictation! It’s all in there 🙂

You can get to the full list of sites directly on your mobile at http://metajam.mobi/m/ …here are some of the best of the bunch:

The non-technical category (i.e. marketing, finance and the executive team)

Bear in mind (and I am sure no-one in this category minds me telling you) that none of them know how to write HTML or perhaps even recognise it 🙂

Amy Mischler; mobile yoga

http://mobiyogi.mobi

Caroline Greer; ICANN travel log

http://icanntravel.mobi

Gesu Sood (category winner); fun on the run

http://gesusood.mobi

Norbert Grey; “Gone to the dogs”

http://mtld.mobi/team/ngrey/

Zico Moro; Dublin city guide

http://mtld.mobi/team/zmoro

The technical category (i.e. the engineering team)

These guys know a little magic – or so they assure me, at least

Cyril Couffignal; Send picture-messages via email to a web gallery

http://uspot.mobi

James Pearce; a movie database for your pocket (disqualified for being the judge)

http://metajam.mobi

Jo Rabin; A W3C test tool for mobile

http://rabin.mobi/dmplbit

Ronan Cremin (category winner); how to commute in Dublin City

http://tjamm.mobi

Ruadhan O’Donoghue; directions and traffic information

http://Go4th.mobi

Stephen Stewart; The dotMobi Advent Calendar

http://1.61803.mobi/advent/

What creativity and invention! Yes, it turns out that there are lots of uncharted opportunities for the mobile medium.

When motivation and decent tools are put into the hands of people who have interesting ideas, you never know what will happen.

I named 52 HTML elements in 5 minutes

Tue, 20 Nov 2007 21:16:22 +0000

(I was just typing in

Cool fun. And hard. Anyone for a mobile version? WML, say.

52{#mingle2_badge}

Carnival of the Mobilists #100

Mon, 19 Nov 2007 16:45:21 +0000

It’s here. Number 100. I’m linked. Thanks 🙂

[Ego blog] I made SF Chronicle

Wed, 14 Nov 2007 22:30:21 +0000

I don’t usually get excited about media coverage, since it’s usually some obscure telecoms trade rag.

But now I’m in the San Francisco Chronicle as a quoted expert! The topic being Google Android and its impact on developers (which could be great, of course)

So please forgive me this one 🙂

Ha ha ha. My quote follows Sergey Brin’s. That made me smile. I mean, I only read the API like everyone else…

Google Android – as told and used by its own developers

Wed, 14 Nov 2007 12:44:49 +0000

While other protagonists nipped off to London, I stayed at Mobile Internet World to provide the drinks for MoMoBoston.

The event’s headline scoop was a couple of developers, David Carson and Alan Blount, from the Google Android team. In fact I think they work just across the river.

It was a well-filled room of several hundred people, but when they started by asking how many developers were in the room, I only saw one hand (perhaps they’re just shy). I guess most of the MIW delegates that crashed the party aren’t coding kids.

Never mind. The presentation deleved into a component-by-component analysis of the entire device stack anyway.

The centrepiece of the presentation of the demo was them attempting live development in front of our eyes. With nothing more than Eclipse, the Android plugin, and some nervous copy-and-pasting, they managed to show how one can wire up a text box to a browser control to act as an address bar. Cool enough although hardly warranting the “we’re going to build a web browser in 5 minutes” anecdote.

For most of the crowd, I think the pace dropped a little at this point. We watched masters-of-the-universe wrestle with Eclipse autocomplete, on-stage typing nerves, and a few run-time exceptions. But they lashed together something in the end, and they got applause for coaxing WebKit to render CNN.com. Cute, I suppose.

(Aside: for me the most interesting part is not the Java particularly, but the declarative XML for GUIs. There are so damn many of these things now!)

Then questions. And the, perhaps unwitting, audience focus in on Dalvik extremely quickly. Why did you build a new virtual machine? Why not use existing approaches? Why not go direct to native Linux? And so on. Standard party line: designed specially for small devices, optimised for Linux, open, etc etc. Well done, no mention of Sun.

Also some inevitable questions about hardware support & integration, and security & ubiquitousness of the APIs. Yes, it’s not just a high-end phone platform – it’s aimed to be suitable for mass-market. Yes, of course different handsets will expose different hardware functionality. And yes, there are things like the location-based API which might be secured, but of course it’ll be down to the individual implementations.

Perhaps undue bravery & even naivety here. Surely every operator and handset manufacturer is going to be sorely tempted to bend and mould and constrain what the device exposes or what the applications can do. The default starting position will not be complete openness.

Despite the presence of the word “Open” in the alliance’s title, I expect reversion-to-type by old school telecoms, and that could be the project’s biggest nightmare. The developers suggested further such tricky questions were brought up at the following day’s keynote. “We just write the code” was probably the right thing to say.

Nevertheless, I remain enthusiastic overall. If Android becomes a dominant platform, then a lot of developer’s problems go away. That may happen. But of course it will only do so over many, many dead bodies – including those of plenty of companies of some significance. So success will be hard and bloody.

But even if Android does not become dominant, it will have shown that there is another way of looking at handset development. As Tom Hume says, it is, at the least, shaking things up a little. What other handset platform has ever exposed a developer’s API a year before any handsets are even likely to reach the shops?

Received and traditional telecoms wisdom is to build handsets for consumers first, operators a close second, and developers a distant third.

What Google seems to be trying to do (with no insignificant bribery too) is to see what happens when you reverse that order – or at the very least make developers feel like first-class citizens in the ecosystem. Build up a head-of-steam with third-party apps before the handsets ever emerge, and as such, an admirable experiment.

But will that be enough to make their force truly unstoppable when it meets the immovable object of today’s ecosystem? I’m certainly looking forward to finding out.

I’m at Mobile Internet World

Tue, 13 Nov 2007 17:21:32 +0000

W3C Workshop this afternoon, MoMo tonight. Presentations, panels & briefings tomorrow and Thursday.

Give me a shout if you are about.

It’s a pre-conference workshop right now, so just figuring out the crowd. Seems a bit telecomsy. The conference poster shows a woman in a speeding car with laptop surfing the web (with husband speaking into phone). WTF.

Occasional Jaiku coverage until my N73 battery dies each day.

Russian dance music

Sat, 10 Nov 2007 09:41:06 +0000

There seems to have been a revolution in Russian music over the last 12 months. House and deep house in particular – genres that have traditionally been strong in the UK, Germany and Holland.

Does it seem odd to think of Russians as composers of dance music? Not particularly… Tchaikovsky, Stravinsky and Prokofiev anyone?

Also composers of world-class dance music 🙂 … and interestingly too, composers from a period following one dominated by Germanic influence.

My $10bn mobile idea

Sun, 21 Oct 2007 20:53:05 +0000

The Web2.0 event has a strange effect on you. Creates a little suspension of reality.

I came away with a business idea that could be worth (at least!) as much as Facebook. And yes, it involves mobile!

Want to know what it is? Do you?

(Well… have you got $10bn dollars? 🙂 )

Web 0.1: and the mother of all demos

Fri, 19 Oct 2007 03:06:10 +0000

Amongst the bluster of the Web 2.0 Summit, if you ever think you are being innovative, if you ever think you have discovered something new, and if you’re ever brave enough to think you might be shaping the future…

…then watch this and be humbled:

(and the context)

Mouse, email, hyperlinks. In 1968.

Kyte.tv rocks Mobile 2.0

Mon, 15 Oct 2007 23:41:11 +0000

Winner of coolest demo definitely goes to Kyte.tv

As Dan says, “Magic From The Future”.

See our ugly mugs here:

/Mobile\s((Web)|(Internet))\s(2\.0)?/

Mon, 15 Oct 2007 05:03:03 +0000

London, Orlando, Boston. This week it’s the turn of [London](http://dev.mobi/node/609), [Orlando](http://www.mobilewebexpo.com/), [Boston](http://www.mobilenetx.com/index.shtml). This week it’s the turn of to host the next of what appears to be becoming this Autumn’s fortnightly conference-series-just-with-different-names.

Signs are good that this is going to be the best one though. To some extent, there are a few of the usual suspects there. But slides have been banned (yay) and that should stimulate discussion. And I rate the organisers highly – they’ve brought together a good crowd.

Personally, I hope we spend as little time as possible bolstering our own cliquey reputations, and more time trying to figure out how to make sure that next year, we’re down the road (storming the palace) rather than sitting it out on the periphery.

Still, the mobile revolution has to start somewhere I guess.

(And I don’t mean with dodgy regex!__)

The biggest mobile news this year

Tue, 09 Oct 2007 20:01:01 +0000

Google buys Jaiku

A big week at dotMobi

Sun, 30 Sep 2007 05:26:52 +0000

Apart from a Apart from a of domain activity going on, the dotMobi Technology Team sneaked out not one, but two important pieces of work this week.

Jo Rabin (our W3C representative extraordinaire) has created an addendum to our current styleguides. We think developers should know that HTTP headers like cache-control and vary are excellent tools for ensuring that transcoding platforms don’t disrupt content that’s been made for mobile.

We know that a little bit of a holy war has spilled out across the internet between mobile developers and Vodafones UK & Ireland: who have recently introduced transcoding proxies to improve the experience of users accessing not-made-for-mobile-sites.

We thought it was helpful to actually provide some constructive ideas for how developers can deal with the transcoding vogue. And at the same time, we’re hoping our relationship with standards bodies and network operators will help others to understand and mitigate the pain that developers feel.

I’d actually believe that transcoding is really just a safety net for users (who probably don’t actually know that many made-for-mobile URLs off the top of their heads). If, over time, such sites became more ubiquitous, one would hope that the need for blanket transcoding might decline.

2. As if that wasn’t enough, we launched a beta of our mobile web directory this week. We call it find.mobi because we think finding things when mobile is more important than searching for them.

We have a web UI on the front of the directory (which you can go ahead and try at http://find.mobi). We think there are some interesting aspects to the way this works, specifically intended for the mobile context. Ronan has the details.

We’re not trying to compete with existing search providers (including our own investors!). Rather, we are demonstrating how it is possible to showcase and champion made-for-mobile sites – which Find.mobi contains exclusively – and we’re able to syndicate the directory and the indexes to other parties to help them improve their knowledge of made-for-mobile sites. Enjoy.

Oh – and do I need to say we’ve still a global device database in the works? 🙂

Google mobile ad revenue: 74% growth… day-on-day

Sun, 23 Sep 2007 06:21:52 +0000

An interesting set of stats came in over night from Russell Beattie.

He’s tracking his new Google Mobile AdSense revenue to see how it catches up or matches AdMob‘s.

Regardless of the quality of the ads, their mobile contextuality, or the two providers’ relative brands, I maintain that most mobile web developers will go with the provider that helps them fill their pockets quickest.

And because I suspect Russell is particular AdMob fan, the result he presents is particularly noteworthy.

$3.50 on Wednesday.

$18.54 by Saturday.

That’s something like 74% average daily growth.

Russell claims these have now “caught up to my AdMob earnings in just 4 days”. Judging by the table, the growth is being fuelled by new clicks, despite the impressions being stable. So perhaps the quality and contextuality of Google’s ads are their driving forces.

[…disclosure: Google is an investor in my company. But even if they were not, this would still be pretty amazing]

UPDATE: I got the maths wrong. It’s higher than I originally stated!

iPhone and the wobbly O2 logo

Tue, 18 Sep 2007 10:07:49 +0000

Few surprises, but here it is.

The wobbly O2 logo looks like it’s a mirage… from the heat of sudden interest in the operator?

Certainly the O2 corporate web site, as at this moment, doesn’t have quite the Apple gloss (or even the announement itself!). This will certainly be a mismatch of corporate cultures. I’ve worked with O2 – they’re great people, but a fair way away from Apple in terms of corporate values 🙂

UPDATE: it’s on the O2 UK site… but the target of the banner ad seems to be struggling under the load. Hopefully not a sign of things to come.

UPDATE 2: O2 logo isn’t wobbly any more. Maybe the interest has died off? 🙂

Apple and O2 stores down for maintenance

Tue, 18 Sep 2007 09:28:39 +0000

Co-incidence? You decide…

Me? I’m betting on a medium price, with a loooong contract.

Free beer, free food, and free mobile demos

Tue, 18 Sep 2007 08:51:18 +0000

(not in order of interest of course!)

Mobile Monday Dublin‘s September event is next week, on the 24th at The Hairy Lemon pub.

It’s Demo Night, and the good mobilati of Dublin will be enjoying demos and presentations from the likes of Mobile Aware, Sentry Wireless, and Mobile Complete.

There’s more detail here. You’ll need to quickly register to come, and for those of you able to make it, I look forward to seeing you there!

Mobile on Wireless

Sat, 08 Sep 2007 17:26:48 +0000

I am just about to speak to Dave Mason on his live radio show, and if you’re listening Stateside, you’ll hear from me soon.

“Nothing short of amazing”

Thu, 30 Aug 2007 10:33:40 +0000

We’re deeply chuffed that the mighty WAP Review has reviewed dotMobi’s recent efforts so positively. Thank you Dennis.

And it’s just the start of things to come!

(Can’t stop now… got to get back to building them 🙂 )

LUAS whitenoise

Thu, 30 Aug 2007 06:50:38 +0000

As the only passenger on this morning’s tram without headphones on, I enjoy a multi-track, second-order musical assault from everyone else’s.

I wonder… How many distinct musical sources can a human ear distinguish? Does it help if they are different genres? How many iPods are required to create perfect whitenoise?

Drupal, AJAX, Scriptaculous

Tue, 28 Aug 2007 19:22:24 +0000

Following my assertion that the only problems in Drupal are the ones you haven’t found modules for yet, I discover Drupal meets Scriptaculous

Exactly what I need to let users define their own layouts of mobile device information web parts.

Oh… did I just give away a secret?

Calling the mobile old-school!

Sun, 12 Aug 2007 19:23:25 +0000

Ericsson R380 touchscreen over the iPhone anyday? Wish “Mobile Monday” was “WAP Wednesday”? Wonder where AnywhereYouGo.com went? Ever wanted to “Surf the mobile internet?” Think that compiling markup is the coolest thing?

If you’re old school, you might like to join me for a quick trip down memory lane – before the mobile web goes stratospheric and we forget the hard work that yesteryear’s pioneers put in.

I’m planning a blog post on the mobile web circa 1999 and I’m looking for contributions.

(Hmm, turns out I’m not the virgin mobile blogger you had me for)

Were you there? What do you remember? What makes you laugh, and what makes you misty-eyed?

🙂

Drop me a line at wml.was.woefully.misunderstood@tripleodeon.com

Mobile Web Irony

Tue, 07 Aug 2007 17:10:46 +0000

I shouldn’t laugh, because these flip cards are very cool and are the tip of an iceberg of lots of hard work.

But of all the pages to exhibit a CSS interoperability issue, this was cruel luck, and I’m afraid it made me smile 🙂

(Looks fine in Firefox of course. I wonder about mobile browsers…)

Otherwise, great work W3C!

I am Officially a Technology Stakeholder of the Web

Tue, 07 Aug 2007 14:27:05 +0000

Or so it says here. And whatever it means 🙂

The question was “In your opinion, what parts of the Web need to be improved or fixed in order for the Web of today to evolve into the Web of the future?”. And I said…

Fundamentally this question assumes that the Web can be consciously improved or fixed at all! In fact the Web on any given day is really just the result the motivations of the people and organizations that have created content and services on, and via, it.

We believe that the evolution of the Web to become mobile is absolutely inevitable. In the future we will look back at ourselves in the early years of the 21st century and laugh that we used to have to sit at a lonely PC screen to enjoy our on-line existence. That will seem as antiquated and quaint as the idea of the 1950s family gathering around a box radio in their sitting room to listen to music.

The Web will lose the shackles of immobility and start to meld itself ever seamlessly around our human life, which of course, is rarely static for very long.

The Web’s technology will not need to evolve very much to start working well on mobile handsets (which have increasingly reliable browsers); however it needs to be used in a sympathetic way. There’s no point going crazy and showing off with bloated heavyweight content, not because of network speed, but because users on the move are by definition impatient and want to cut to the chase.

That makes mobile Web development quite a cathartic experience: in fact there’s a certain Zen in creating a streamlined on-line service that is primarily designed for mobile.

But ultimately the successful content and services of the coming years will be those that not only take the mobile browser’s behaviour into consideration, but which are primarily aimed at users in the mobile context. Not surprisingly, users rarely want to have pieces of a large Web presence squeezed down to their mobile phoneâ€”they rather want a compelling and beautifully designed web that suits their mobile lifestyle.

So my answer to your question is this: for the mobile Web (which is the Web of the future), Web developers should think different.

Anyway. I am not a fan of that stock photo 🙂

There’s no such things as a problem in Drupal…

Fri, 03 Aug 2007 11:39:22 +0000

….just modules you haven’t found yet

More Than Just Us

Wed, 25 Jul 2007 07:09:30 +0000

I just discovered there is such a thing as a “social group for bloggers in Hindhead, Haslemere, Grayshott, Beacon Hill“.

– approximately 2 weeks before I leave the area to go and live abroad.

So I guess I can’t help them be more than just them 😉

A big red kangaroo…

Wed, 25 Jul 2007 06:38:59 +0000

…gives me an upgrade. Silk pajamas and duvet all the way to Hong Kong.

Now back to work… here for the ICANN regional meeting.

Google Reader tracks my mobile life

Wed, 11 Jul 2007 23:42:33 +0000

I use Google Reader. Sometimes on a PC, but mostly on my Nokia N73.

The trends feature is cool (give or take a little CSS overflow and a Javascript error 😉 )

Well, well. Monday is when I normally travel abroad – and spend my time standing in queues for security.

I’ve been caught! Seems that’s when I catch up on my news.

Notch up one for mobile. Blogs and RSS are, of course, perfectly suited for that context…

iPhone? iSmoke!

Wed, 11 Jul 2007 15:43:04 +0000

Completely nuts.

Mobile Web Testing and Web 2.0: the love-child

Wed, 11 Jul 2007 15:25:20 +0000

Cool new software alert!

If you know a bit about my background, and what I did at Argogroup, you’ll smile when you see what dotMobi has just done.

Mobile quality assurance meets Web 2.0. And it rocks.

I can’t take any of the credit! The kudos goes to Ruadhan for the code, Ronan for the algorithms, and Stephen for the design, while I fly around the world mumbling about mobile user experience and telling the world how cool all their work is.

Invite yourself to take part in the beta trial, login and have a go, and tell us what you think we need to improve before we launch.

Does it seem mad busy at dotMobi – or is it just me? But trust me, two bigger projects are still to hit…

Big dotMobi news

Wed, 11 Jul 2007 00:35:05 +0000

I’m itching to be the first to blurt this out. (Although it was a poorly-kept secret, to be honest 😉 )

Yes, I’m back on the “everything you ever wanted to know about mobile devices in a structured way” tip.

But this time, I’ve got more help. One or two well-known dotMobi investors, for example. But also, the one and only Andrea Trasatti, who I’ve managed to persuade to join us from the WURFL project.

(I think he’s just as excited as I am about the plan, so it seemed to be an easy sell… but I’m sure he’ll blog extensively about it himself)

One of the most important things is that this shows we’re trying to make dotMobi far more than just a registry of domain names.

To help the mobile web fulfil its opportunity, we have to tackle big problems. And, oh yes, this is a big one.

It’s going to take a month or two of feverish development, but it’s already starting to take shape. Stay tuned – this stuff is important for the future of mobile.

Pearce Fogg takes mobile a bit too literally

Fri, 22 Jun 2007 19:40:41 +0000

With a wedding anniversary on Sunday and son’s birthday the following Saturday, fitting in a few important business trips visits to Beijing, San Francisco and New York (not to mention central London to pick up a visa) appears impossible.

But in a Vernian moment, I remembered the date line. So, in fact, it turns out I can…

apply for visa on Monday morning
receive visa and fly from Heathrow Monday afternoon
have 2 days of meetings in Beijing, Tuesday and Wednesday
speak at a conference in San Francisco on (my replay of) Wednesday
do an interview with the WSJ in New York on Thursday
get home on Friday morning

And still get home in time to help prepare for the aforementioned birthday.

3.5 days and all the way round. I think that beats my day trip to the Rockies. Is this why they call it the mobile web?

Dallas Mavericks and out

Fri, 22 Jun 2007 17:47:48 +0000

Well, I forgot to mention it… but the MaxJet flight we got reseated on was the Dallas Maverick’s private jet.

Hilariously, I was in “Ultra First Class” – which is preumably where the 7-foot+ basketball players sit. I did in fact have 10 feet of leg room. Thank you Mark Cuban.

Less impressed were those ‘business class’ travellers who were relegated to the economy seats at the back of the plane (for the physiotherapists and score-keepers?). Oh, and we did arrive fairly late and I had to run for the connecting flight.

Coming home even my humour didn’t last though… at the JFK check-in desk: “We’ve got bad news; the flight’s just left the UK”.

Well, there’s no way I’m waiting eight hours for a departure at 4am, and a wrecked weekend. So, a nifty hop onto the monorail, a phone to the travel agency, and two hours later I’m flat, asleep, and on my way home – no thanks to my scheduled carrier.

So a skeptic proven right I guess. And I still don’t know what a MaxJet plane actually looks like.

Can MaxJet keep a skeptic happy?

Mon, 11 Jun 2007 12:52:33 +0000

I live near Guildford UK, and I need to get to Charlotte in North Carolina.

Now, there’s a direct flight from Gatwork (45 mins away) to Charlotte. But it’s a bit pricey this late in the day.

So we’re trying MaxJet. MaxJet appears to me to be to business class what EasyJet is to economy. But let’s see. I’m game.

But they fly from Stanstead to Washington, and then I connect down to Charlotte. So I’m already grumpy. It’s at least 2 and half hours to Stanstead, and then I have to change. It makes it almost like a 3-leg journey.

I get to check-in. Oh dear – their plane’s out of action. We’re having to use someone else’s. Lots of people complaining that their seats don’t recline (and so on)

I’m not cheerful at this point. I could have been half way to Greenland by now. (And I’m stuck in Essex – the horror of it all!)

But… someone’s smiling down on me. They’ve reassigned all the seats. This other plane has different classes and I seem to have been put right up the front in “Ultra Premium Business Class”. Well; that sounds interesting.

I struggle past hoards of package flights to the MaxJet lounge. At least I can get some peace and quiet.

Oh. Whoah. They have free wifi in the lounge.

I love MaxJet 🙂

A day trip to Canada

Tue, 08 May 2007 07:13:54 +0000

I bet that’s not a big deal if you live in, say, Detroit.

But I live in London, and I’m going to Banff. For a day 🙁

I’m taking part in the W3C track at WWW2007, and talking about the mobile web with the MWI folks.

I’m really looking forward to it – but not the abrupt return flight (thanks to the need to return for an important investor meeting in London on Thursday). Sadly that means I won’t spend as much time as I’d planned at the rest of the event. It was great last year.

See you there if you’re there.

The Mobile Web is Generation Y’s

Thu, 05 Apr 2007 19:56:04 +0000

Those born between 1978 and 1997 are often collectively described as “Generation Y”. That’s 10-30 year olds.

Wikipedia cheerfully suggests the Y-ers also enjoy classifications like “the Net-“, “the i-“, “the Google-“, “the MySpace-“, and “the MyPod-Generation”. The preceding generation (mine!) is Generation X: those thirty-somethings born between 1965 and 1978.

But despite Wikipedia’s assertions, and assuming this is even a valid question, who’s generation actually lays claim to today’s web?

It’s got to be the latter.

Generation X’ers founded eBay, Google, Paypal, and no doubt thousands of the web sites that the world uses today without a second thought. Look around at all the A-list bloggers out there too; almost all in their 30’s I would say.

While the basis for the world’s networking infrastructure was probably a baby-boomer thing, it was undoubtedly my generation that developed the web as a mainstream medium.

And – wait a minute – that suddenly makes us the on-line establishment.

Start looking at it in these terms and it’s a bit of a shock (and certainly no help in helping me avoid an inevitable mid-life crisis!)

So this got me thinking. Each generation generally has a desire to overturn – or even revolt – against their established precedents.

And if we learn from the many times this has happened throughout human culture in the past, one can easily see that it’s going to happen again. Today’s web is undoubtedly due for such a shake up. And I’ve no doubt that mobile is going to be the significant factor in that coup.

Yes. The evolution of the web on to the mobile medium is completely inevitable.

(Look: take the really long view… can’t you see yourself reminiscing about those good old .com days? When folks used to have to sit down in front of a lonely screen to interact on-line with the rest of the world? How quaint.)

But what is dawning on me is this: that the coming revolution isn’t something that will be driven through the adoption or innovation of today’s establishment. Those lonely PC screens are Generation X’s comfort zone. We find ourselves struggling with small screens and small keys to even glimpse the potential of the next decade’s on-line experience.

So I’m looking to Generation Y. They’re the mobile generation. They’re the ones looking for a new angle. They’re looking for a paradigm that they can adopt, pioneer, and make their own. And they’re going to be the guardians of the web in the coming decades – the web that will finally call itself truly mobile

(Oh, and they’re the ones with the small fingers)

Most importantly, they will do wonderful things with the mobile web. Darwinian things that the now-conservative institution of today’s web would probably never grasp, risk, or predict.

Should we be surprised? Should we react? Should we stifle?

No. Of course not. We should roll with it. We should encourage, guide, and then, when required, stand back and watch with awe. Don’t milk the calf. Yes, we can help to provide the the base technologies, the open ecosystems (and, oh yeah, the domain names), but the medium will never be ours.

We’ve done our bit. Now it’s our responsibility to allow our successors to build their own legacy. That’s the real Web 2.0.

(At least, until 2030 or so when Generation Z starts an even more radical revolution… riffing on .implant domains perhaps)

Wall Street Journal discusses mobile web

Thu, 05 Apr 2007 16:00:18 +0000

There’s a great article at the WSJ about the mobile web.

Yes it mentions .mobi, but more importantly it highlights the role that smaller business and grass-root sites will play in the growth of the medium as a whole.

To quote, “The wireless Internet is just beginning to take shape”.

Personally, I’d have used the word mobile instead of wireless – but again, it serves to capture the zeitgeist of the roller-coaster that we all know is just beginning.

Have a good Easter everyone!

An E61 with that, Mr President?

Thu, 29 Mar 2007 22:07:37 +0000

George Bush (snr) and Bill Clinton addressed the CTIA keynote this morning in Orlando, and then went for a stroll around the show.

They seemed to spend a fair amount of time at the Nokia booth (clearest part about 2 mins in), admiring the customised car, and accepted two E61 devices from the company.

Just minutes earlier both had been seen chatting to a 6-foot tall Blackberry. Too bizarre for words, and sorry – no video of that.

At CTIA, blog service is rubbish

Thu, 29 Mar 2007 11:05:52 +0000

(Bad joke, yes. Could benefit from Photoshop? Yes.)

I’ll see you at CTIA

Sat, 24 Mar 2007 22:45:24 +0000

On a plane tomorrow to Florida. If the show is anything like this year’s intriguing 3GSM, it will be time well spent, even though it’s crazy triple-booked busy in my calendar right now.

I’ll be on the dotMobi stand a bit: Hall 3, stand 1995 if you want to come by.

On Tuesday I’m doing a keynote for the the dotMobi Advisory Group workshop. It’s a group of companies and individuals – outside of our investors – of that helps steer the .mobi company and its strategy.

I’m pretty sure anyone can come along to the session. Details here.

Wednesday night is Gala night. I’m hoping to add another notch to my “Was I the only blogger at?” series.

Thyng.mobi goes live

Wed, 21 Mar 2007 21:53:43 +0000

I’ve finally made the effort to finish off my little experimental .mobi site.

It’s 5 common phrases (Thank you, Hello, Yes, No and Goodbye) in a variety of common languages.

To be honest, it’s mostly for me to use! OK, so French & German I’m OK with, but I always struggle in Iberian taxis. So this should help.

(Mental note: are the killer apps for the mobile web those that you build for your own use?)

And as I travel, I’ll probably add more languages.

Hardcoding all the pages just seemed like a drag. So it seemed natural to autogenerate them. But of course languages don’t change that fast so it’s a build-time generation, rather than request-time.

And how? Well, a grid of phrases vs languages – it just had to be Excel! I drop new vocabulary into a spreadsheet and a little VBA macro spews out perfectly formed XHTML files (that, surprise… just happen to score 5 on http://ready.mobi)

I realise I’ve deviated from my “.mobi sites for beginners” vibe here.

Next stop: advertising.

dotMobi Developer’s Guide: 23,000 downloads and counting…

Tue, 20 Mar 2007 21:08:53 +0000

Over at dotMobi, we’ve just released our mobile developer guide.

I’ve just seen the astonishing download statistics: an incredible 23,600 downloads in less than 2 weeks.

OMG.

Congratulations to the team! Please take a look – and I hope you enjoy it.

X-Series: the catch :-(

Wed, 07 Mar 2007 23:39:49 +0000

OK, I’ve been thrilled with my new X-Series tariff from 3 UK. Mostly because I spend most of my time travelling between the UK and Ireland: which means that, in addition to great voice & text bundles (not to mention flat rate data!) I am essentially roaming for free.

It all seemed to good to be true.

And unfortunately for me, it was.

For this week I am in the USA 🙁

I am so used to being able to get a service-like-home when I go abroad that I was completely shocked to see my phone failing to get a data bearer in Los Angeles airport.

(My N73 admirably flashed up an ‘E’ for a few seconds as it tried – and failed – to establish what would have been my first experience of EGDE)

But a few calls to Three later revealed an ugly truth. No data roaming in the US. Cue world-falling-apart music.

Apparently, the friendly chap told me, “there is no mobile data in the US”. What he meant of course, was “for roaming 3 subscribers”: I’ve always been well served by GPRS on Cingular in the past.

So for the last few days I’ve spent more time than usual hunting WiFi spots to fire up the laptop to get email and web connectivity. And plenty of voice calls to make up for it.

Until that is, just now. Another surprise. “You are reaching your credit limit” chirps an SMS arriving from some automated accountant back in Maidenhead. Hmmm… turns out that I’ve been paying either £1.20 or £2.40 per minute for my calls!

So here’s my advice. If you’re going to move to 3, think carefully if you go to the US a lot… or at least read the roaming tariff charts more carefully than I did. 🙂

.mobi keeps storming Google

Wed, 07 Mar 2007 15:10:31 +0000

The Google result counts for common TLDs continued to slide dramatically during February. So significantly that it seems the company is really doing a ruthless clean-up of their indexed content (or are tightening up the algorithms)

Bucking the trend, by a country mile, is the .mobi TLD, which has risen an 35% (which seems astonishing in the context of the others’ trends).

The numbers this month (to be compared with these from the start of February):

site:.com	5,700,000,000	(down 14%)
site:.org	2,180,000,000	(down 11%)
site:.net	354,000,000	(down 19%)
site:.info	46,500,000	(down 20%)
site:.biz	15,600,000	(down 38%)
site:.tv	16,800,000	(down 20%)
site:.mobi	496,000	(up 35%)

Now, when I started out, I genuinely thought I’d just do this as an interesting analysis of mobile web growth trends. Now I’m a bit worried it’s starting to look like corporate propoganda (disclosure disclosure!).

However, the numbers are real (even if, as ever, doubtful as an absolute measure of real content).

So I will continue. And I happen to know that the TLD’s name sales are surging up, so I suspect the trend will too. All I can think of doing is at least automating it so I don’t have to remember to every month.

Mobile Monday Dublin kicks off in April!

Thu, 22 Feb 2007 12:45:48 +0000

Dublin, Ireland is one city notably missing a Mobile Monday chapter.

Hopefully this can be fixed… with the inaugural Dublin meeting on the 2nd of April 2007.

It should be a great opportunity to chat, network and mingle with friends, colleagues and experts from in and around the mobile industry.

We’ve booked some room at the Library Bar at the Central Hotel, Exchequer Street.

The event will be casual, friendly, and should definitely worth coming down to. Expect a little food & drink to help the mobile conversation flow more freely…

We use YahooGroups as our mailing list, and anyone can join by entering their email address here:

(Use the poll on the YahooGroups site to indicate if you’re planning to attend this particular event.)

So… for all of you in or near Dublin, keep the evening clear in your diaries. I look forward to seeing you all there!

The Miracle of Mobile

Thu, 22 Feb 2007 10:31:40 +0000

Jesus up a basestation

I don’t usually just post gratuitous links, but this one is a good one. Jesus on toast, Jesus in a log. And now fixing Uganda’s connectivity.

Google Maps for Mobile can have my children

Thu, 22 Feb 2007 08:55:28 +0000

(except, oh – I’m already married)

So this app is not a complete newcomer to the party, and I’ve even been caught using the AJAX version on the S60 browser in the past.

But I recently moved my mobile account to a new provider, and suddenly this make sense…

A blazing UMTS connection thanks to 3
A slick client-side app thanks to Google
A beautiful N73 screen thanks to Nokia
Satellite imagery thanks to NASA
Utter ignorance of the data volume thanks to X-Series

The mobile ecosystem working in perfect harmony…

…to get me as close to feeling like James Bond as possible 😉

Or did you mean .mobii ?

Mon, 19 Feb 2007 22:03:59 +0000

Ajit’s got a great blog, but I never seem to get my comments to his posts approved (whole articles, no problem though!)

In particular, I take small issue with this one. The insinuation is not veiled enough for me to resist responding to (and hence the usual disclosure about my current role, and a cross-post).

I have to say that relaxing on my sofa using Opera on a Wii is a pretty similar experience to relaxing on my sofa using IE7 on a media PC. So yup: no point in having a .wii top level domain (or .console, or .couch or whatever).

But walking down a street in a strange city in the rain, looking for somewhere you can can get a taxi home safely? Sounds like a totally different context to me. One that .mobi serves well (for example in the form of http://cabbies.mobi/)

Yes, that’s right. Top-level extensions are about context, not the way markup is rendered. (The latter is something that browser manufacturers rightly obsess about).

So here are two interesting thought experiments I always keep in mind…

a) You’re walking down a street. You (somehow) have a full-blown version of Firefox on your mobile phone. You need to access some pertinent information urgently on it, and know the relevant publisher runs both a .mobi and a .com site. Which would you enter into your phone’s address bar?

b) Opera develops a client-side language translator for their browser. It can turn English web sites into French. You’re in France. Do you access ebay.fr or ebay.co.uk?

Hopefully the former in both cases: .fr is about the French context, not French markup. And .mobi is about the mobile context, not mobile markup.

(Although dotMobi still has a role to play with the markup too, because not every phone is yet blessed with Mr Jon von Tetzchner’s rendering magic)

It’s all about the context, baby.

And, by the way, I don’t recall anyone ever claiming that ebay.fr broke the ‘one web’… 🙂

Was I the only blogger at the GSM Awards?

Wed, 14 Feb 2007 18:02:09 +0000

Was I? Well maybe not, but I’ll put that claim to the test.

The GSM Awards are most obviously described as the Oscars of the 3GSM world (in contrast to the MoMo Peer Awards which are perhaps like Sundance). As the CTO, I was lucky enough to be there, seated on the .mobi table.

Showy they certainly are, and with what must have been at least a thousand black-tie guests from the industry, Clive Anderson hosting, and the great and the good coming up to accept the awards (to barrages of light and the sounds of late 90’s dance music) it certainly felt the part.

I thought I’d be cynical about this sort of thing, but to be honest, I’ve got to say I did enjoy myself.

The organisation was great, the food excellent, and the host edgy – even if the humour was somewhat British. “Ringtone? I thought that’s what George Bush does when he wants to invade a new country”. (And the etymology of GSMA Chairman Rob Conway’s name, whilst best not repeated here, was pretty funny.)

But most of all, the winners seemed genuinely chuffed. I guess that when you’re honoured by your industry peers, you know you’ve done something special. (disclosure: my previous company, Argogroup, won an award a few years ago, although I missed the event that time.)

So, whether it was Turkcell humbly (or Virgin eloquently) accepting their advertising awards, iPlay amusingly name-checking their game developers (“who rightfully aren’t here, but still home developing the next one”), or the Sony Ericsson representative accepting an award for the K800 device (“I only just joined the company, but thanks anyway”), the histrionics were kept to a minimum, and the plaudits genuine.

But one really interesting observation was the prevalence of awards focussing on what you might call the ‘application layer’ of mobile. The awards for best network, best infrastructure, best coverage (and so on) were quickly dealt with, and a healthy proportion of the awards and winners during the evening itself represented areas like music, sports, and download services – as well as general innovation throughout the ecosystem.

So it was fantastic to see the future of the mobile medium shining throught an event like this.

Another overwhelming theme of the event was the expansion of 3GSM connectivity into the developing world. We saw a BBC television piece on the digital revolution that mobiles are bringing to the African continent: “as big as fire, the wheel and the railways“. And at end of the evening, the Chairman’s Award went to Mo Ibrahim, an early GSM pioneer who is now working hard to bring the medium to developing continents, countries, and communities.

It was enough to leave this skeptic, at least, with a warmed heart, and some optimism that, beneath all the stage-managed glamour, gloss and glitz (3G, right? 😉 ), this is an industry that can genuinely do something good for mankind. Nice wine too.

.mobi sites grow another 40%

Thu, 01 Feb 2007 10:10:37 +0000

Another month, another run at these numbers.

And another job (which needs to be a disclosure: I’m now the CTO of MTLD 🙂 ).

Anyway here are the stats, as ever using Google’s site:.tld query syntax:

site:.com	6,610,000,000	(down 3%)
site:.org	2,180,000,000	(down 7%)
site:.net	439,000,000	(down 17%)
site:.info	57,800,000	(down 9%)
site:.biz	25,200,000	(up 6%)
site:.tv	21,000,000	(up 4%)
site:.mobi	496,000	(up 40%)

Need graphs!

Fixed web shrinks! Mobile web grows!

Mon, 01 Jan 2007 12:36:40 +0000

It’s almost a month since I did this before, and I’m doing it today in case I am disciplined enough to start doing it the first day of every month.

This is the Google page count, using the site:.tld query syntax:

site:.com	6,610,000,000	(down 12%)
site:.org	2,340,000,000	(up 4%)
site:.net	530,000,000	(down 8%)
site:.info	63,500,000	(down 22%)
site:.biz	23,700,000	(down 10%)
site:.tv	20,100,000	(down 7%)
site:.mobi	354,000	(up 50%)

It seems fairly unlikely that the web is shrinking quite as much as that… so this probably highlights changes to Google’s page counting algorithm more than anything else.

Certainly the dubious science of this study 🙂

But anyway, it was worth it for the title. And makes us all feel cheerful for the start of the year.

Surfing the augursphere

Mon, 01 Jan 2007 12:10:18 +0000

Why does New Year make everyone believe they are talented soothsayers of the impending twelve months?

Or worse, the retrospective variant: “here’s how clever I was at predicting last year a year ago”.

(Bah humbug)

I can’t move for “bubble x.0”, “web y.0”, “mobile z.0” predictions filling up my Google Reader. And I’m not going to fall for the temptation of making any predictions myself (this was merely an idea 🙂 )

But one silver lining is notable: nearly every one of these (from the web, technology, and mobile blogospheres) seem to think 2007 is the year when the mobile web will be a success.

I don’t think anything so undefinable ever becomes a success in a single calendar period. What year did the Internet “take off”?!?

But I think I know what they mean.

All the technology ingredients are there. The economics are starting to take shape. The public seems to be supportive of change on the web as a whole – so why not mobile too?

And I’m putting my career where my mouth is. So stay tuned.

Happy new year everyone!

The Mobile 2.0 Tariff

Sat, 30 Dec 2006 00:10:32 +0000

An idea that popped up during a lunch; and something I would love to see in 2007:

“The Mobile 2.0 Tariff”

The world’s driven by market forces. And the best will in the world behind “thou shalt use the mobile web” isn’t going to work unless it’s economically stimulated.

Open gardens and open data usage are a start.

But (and forget here for a moment you are a jet-setting telecoms professional whose bills get paid), the vast majority of the human population – or at least those who have a mobile phone – are concerned with 1) communication with their social network, and 2) how much it’s going to cost.

It’s called telephony. These days, at least.

But the ingredients of mobile 2.0 are about bringing more variety to that social network’s communication. Keep the telephony, sure. But mix in more exciting forms of messaging, web 2.0-like services, and richer media types.

All the technology stuff the works. We’ve seen the template for these services on the non-mobile web, and we know it can work over the mobile medium too.

But it still doesn’t mean that the second criterion is met: that of economics. Remember, for most of the population, tariffs are intimately mixed up with whole mobile usage experience.

So imagine this. An enlightened operator launches the “Mobile 2.0 Tariff”: a mobile bundle, pricing plan, and service portfolio designed to appeal to the 21st century social networker.

What do you get? Obviously a capable phone and unlimited data. So far, so X-Series.

A) Then, provide a pre-paid option. Today’s on-line society isn’t solely comprised of well-heeled credit-worthy early-adopters. Students, kids, the unemployed, the casual user. Shouldn’t they get the mobile web too?

B) Pre-configure settings, bookmarks, or client-side apps for big mobile or web 2.0 apps. Maybe this is web-side configurable, using OMA DM – you can enter your account settings etc. YouTube, Twitter, MySpace, SoonR (although even that’s a bit enterprise), etc. Typing URLs and re-logging in is so QWERTY.

C) Host a (mobile) web presence for each subscriber. Give them a blog engine, ready-skinned for mobile usage:

http://wordpress.operator.com/447867554666

– or howabout

http://447867555555.mobi? Make this stuff really easy.

D) Tie up as many commercial web services’ accounting into the consolidated billing. Could I have my mobile AdSense account appearing on my bill or spent against my pre-paid credit? (OK – maybe not always, but I should be able to choose so)

E) Do a f***-off advertising campaign. Hey! Surely we’re ready to revisit “Surf the Mobile Internet”!

I’m sure that’s not even the start of it. But I hope you get the idea. Basically, we have to make this exciting mobile paradigm as easy as falling off a (b)log.

– or perhaps what I’m saying is that we get so easily tied up in what can be done, and some funky demo we saw last week, that we sometimes lose sight of what the human population thinks about and really wants to do. Creating a path of least resitance to that is key.

Oh, and I’m sure I don’t know wholly know what the human population thinks about and really wants to do. So any more ideas? 🙂

Optimize for mobile search engines

Tue, 26 Dec 2006 21:58:29 +0000

I discovered a great little article summing up some data on mobile search and trends. Of course ‘short queries’ and ‘limited screen real estate’ are a given.

But I also noted these various recommendations:

Write short, concise titles.
Adhere to mobile standards
Connect, or link to, legitimate and popular Web sites.
Make sure you are not disallowing mobile crawlers from spidering your site.
Submit your mobile site for inclusion And…
Design for low-end phones
Keep the URL structure as simple as possible
Specify the doc type in the XML preamble
Specify the character encoding
Keep links descriptive Seems the broader web community is starting to pick up on the W3C and dotMobi zeitgeist…

You are the Time Person of the Year

Sun, 17 Dec 2006 10:22:59 +0000

It’s true. Read it here.

“It’s a story about community and collaboration on a scale never seen before. It’s about the cosmic compendium of knowledge Wikipedia and the million-channel people’s network YouTube and the online metropolis MySpace. It’s about the many wresting power from the few and helping one another for nothing and how that will not only change the world, but also change the way the world changes.”

You beat off stiff competition from, amongst others, Mahmoud Ahmadinejad.

Next year, the mobile browser is rumoured to be a candidate.

dotMobi uptake

Fri, 08 Dec 2006 02:01:32 +0000

A totally unscientific technique, and not even my idea (being, as it is, stolen from a colleague who never published 😉 )

However, this is the Google page count, using the site:.tld query syntax:

site:.com	7,490,000,000
site:.org	2,250,000,000
site:.net	580,000,000
site:.info	81,500,000
site:.biz	26,200,000
site:.tv	21,600,000
site:.mobi	236,000

Interesting though. I guess I should do this every now and then to track change.

(And perhaps also work in length of TLD availability to get an idea of uptake as a function of time).

Characteristics of (Mobile) User Experience

Fri, 08 Dec 2006 01:48:16 +0000

Need to big this one up. A dissertation (don’t panic) on mobile web browsing from Nokia Research.

Some interesting discussion on some of the S60 browser patterns: minimap vs narrow layout for example, as well as coverage of the mobile web ecosystem as a whole.

Basically – a paper to consider how all of these factors affect the users’ experience. Damn – you know we always forget those guys.

Now what is Verizon doing?

Thu, 30 Nov 2006 09:28:20 +0000

YouTube/Verizon has been much blogged. But what about this?

Revver is a tiny, tiny YouTube, but has revenue at the root of its DNA.

So this is interesting. Verizon hedging two bets, taking on an advertising-based model, for an internal play off against the mighty YouTube brand?

Yes, very interesting.

(A cynic might also suggest they want to make sure they don’t end up completely beholden to Google.)

Just when you thought the gardens were opening…

Wed, 29 Nov 2006 09:25:50 +0000

…Verizon grabs a sliver of YouTube content, walls it up, and charges 15USD to get it.

I guess I can’t begrudge anyone trying to get a return on an (astronomical infrastructure) investment.

But it is interesting that just as the walls for mobile web are coming down, the walls for what everyone thinks is the next big thing are going up.

It’s like a castle seige (I’m thinking Lord of the Rings here, or something) – as soon as the first barricade is breached, there’s a cry of ‘fall back!’ to the next line of defence. And newsworthy as this has been, I can’t help thinking there’s more defence to it than innovation.

There’s a famous ‘hype curve’ model along which new technologies progress. Lots of hype, then a crash of reality, then a gradual re-acceptance and maturity as adoption returns. Think WAP.

Well I can imagine an inverted ‘walled garden curve’ that has a similar lifecycle: service providers don’t see some new phenomenon coming, and it gains community momentum. Then they suddenly ‘get it’, ramp up the tariff, and strangulate it. Eventually, market forces take over, and openness gradually returns. (That’s where we are with mobile web I believe).

We, the community, need to make sure the golden eggs survive the duress of the goose.

(And I’ll leave the discussion of any causality between these two curves as an exercise for the user.)

So is that the mobile quality gorilla…?

Wed, 29 Nov 2006 09:03:38 +0000

IBM has just swallowed up Vallent (itself a fairly recent merge of Watchmark, Comnitel and Metrica). Add NetCool and this is a pretty compelling platform for mobile telco QoS.

Back at Argogroup, we often pondered which of the biggies would join the mobile quality dots first – an Agilent?, an HP?, an Ericsson? IBM was never on my list, but if you look carefully, they can do more in the area of mobile than some realise.

What does this mean for the mobilist in the street or the grass roots of the mobile web? Well nothing immediately – but I think this sort of tectonic M+A shows that the mobile medium as a whole (by which I mean much, much more than voice) is under strong scrutiny in the powerful boardrooms of the world.

Which is only going to be good for us all – capitalism’s OK, you know…

And IBM has just a little bit of web in their genes 🙂 so it will be interesting to see whether that, together with their growing mobile muscle, will further influence the medium’s evolution towards the dream we all have in mind.

Death to the G

Mon, 27 Nov 2006 12:36:58 +0000

‘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.

More virtual living

Mon, 27 Nov 2006 10:27:10 +0000

For reasons at worst trivial, I find myself in hospital overnight.

Say what you like about the UK health service – all that matters to me is that the bedside telephone doubles up as an internet terminal!

So here I am cut off from the real world, but completely immersed (as usual) in my on-line existence. The only downside is the lack of mobile, but I think writing my blog from an NHS bed trumps Dan Applequist’s Blackberry. 🙂

Mr Pearce builds a .mobi site (part 3)

Sat, 25 Nov 2006 09:31:11 +0000

…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 🙂

Mr Pearce builds a .mobi site (part 2)

Sat, 25 Nov 2006 07:12:16 +0000

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.

Good words for mobile

Sun, 19 Nov 2006 21:15:32 +0000

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{#p18} (~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

Mr Pearce builds a .mobi site (part 1)

Sun, 19 Nov 2006 20:09:09 +0000

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.

Mr Pearce builds a .mobi site (part 0)

Sun, 19 Nov 2006 10:27:36 +0000

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.

The mobile walls come down

Fri, 17 Nov 2006 14:31:59 +0000

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 🙂

What makes a successful company?

Fri, 17 Nov 2006 09:15:25 +0000

I recently swapped some e-mail with some old colleagues from AnywhereYouGo.com – which at the time, 2000, was the ‘leading worldwide mobile developer community’ (http://www.anywhereyougo.com is a pale imitation today. Archive.org is closer).

It was broadly agreed that we had been ‘ahead of our time’. The bubble came and went, mobile data didn’t spring into life as we’d all hoped it might, and the idea of stimulating a community was just a few years early for the web 2.0 excitement of 2004 onwards. The company got bought (admittedly in two / pieces), and most folks moved out.

Now it’s nearly 7 years on, the mobile web appears to be entering some sort of a renaissance, and communities (and developer resources) are all the rage. The valley is still climbing the side of a new bubble (or is it a spike?), and one wonders how AnywhereYouGo.com would have been riding that were it around today.

Since then, at Argogroup, the trick has been to to keep the momentum of interest in mobile data (and its quality) going. As a member of a very exclusive club of mobile startups that existed in both 2000 and 2006, Argogroup had to learn how to survive the trough between two bubbles.

Did we do it by being ‘ahead of our time’? Well yes, to a certain extent. To keep investment coming, and to keep the company focussed and motivated, it’s very powerful to be developing products and propositions that are unique. And of course it’s the only way you’ll ever get an exciting valuation.

But at the same time, you can’t do that in an ivory tower without disappearing into a technology-oriented world of cool products that don’t pay the bills. So while we worked hard to build exciting new technology, we put a lot of effort into building up commercial strength and going where the dollars were. And yes, of course, always being prepared to adapt a utopian vision of one’s product roadmaps towards what customers are actually asking for. So that’s about being ‘on the time’.

Finally, after a while of making an apparently lucrative market, no-one is surprised when competition springs up – and that’s an important factor in driving a successful business too. As we all know, only the paranoid survive, and it’s not unusual for a competitor to rise fast to match some of your capabilities in the market place. In some cases exceed them – and that’s when you realise you’re ‘behind the time’. The level of concern – or paranoia – that that engenders can be a great catalyst to motivate a company to succees. (Watch Intel and AMD go at it).

Conversely, if you are late into the market, having a pace-maker to aspire to overtake also seems to be a recipe for success.

So… I think you need to be all three:

1) Ahead of your time – providing thought-leadership, entrepreneurialism, pioneering world-class R&D, and a sales channel prepare to operate outside of a comfort zone

2) On the time – providing products that people need hear and now. Listening to short term requirements and catering functionality to meet tactical needs; a.k.a. ensuring revenue 🙂

3) Behind the time – not entirely of course, but being stung into action by other innovators and knowing how to deal pro-actively with that threat and shortfall – or having an earlier innovator in your sights.

Take Google for example. 1) Check (writ big), 2) Check (ditto), 3) Check (but closing fast)

So what makes an unsuccessful company? Well, failing to tackle all three of these facets certainly doesn’t help. With AnywhereYouGo.com, we had lots of 1), basically no 2) and very little 3). I’ve been there – it’s not pretty – although I think we all did the best we could in the circumstances.

But companies can also fail if they forget how to do 1), or don’t know how to deal with 3). The here-and-now comfort zone of 2) securing cash takes priority over innovation and competitive leadership.

Kiss the valuation goodbye, watch the tail lights of the rest of the industry get smaller and smaller… sooner or later that’s not pretty either.

No half measures

Tue, 14 Nov 2006 21:33:03 +0000

Even genius has to pay its dues. It’s goodbye to the shortcuts, hello to the grind. Nobody ever said it would be an easy ride. So push more, risk more, feel more. How much is just a question of courage, a matter of heart (and taurine)

The most expensive web cam

Tue, 14 Nov 2006 20:00:22 +0000

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…

Burning the midnight oil

Tue, 14 Nov 2006 02:16:57 +0000

Up at 4.45am this morning, still going 21 hours later. Ah, the start-up life. Back to the day job tomorrow.

Hmmm. What can he be up to? Well I’m not telling. But it involves a little blue logo. You read it here first.

Speaking in Budapest

Mon, 13 Nov 2006 09:36:27 +0000

Hey, I get a mention in GoMo News. It was a slightly bizarre event, as it was right next door to http://www.aoexpo.com/.

Anyway, I was speaking on mobile video and its future. I was fairly clear that the IP-streaming ‘Mobile TV’ paradigm is in some sort of a sweet-spot at the moment, but I also covered some of the other technologies available, as well as the usual challenges (quality etc etc etc)

Before and after me were two speakers who both represented vendors in the ‘video shortcode’ space. Completely unknown to me, the world isn’t interested in video streaming – they only want to use their video phones to dial up shortcodes to see the telly. Or perhaps it was just a slightly biased panel…

Anyway, personally I don’t care whether it’s streamed over packets, or called in over a circuit. I’ll be happy for anything that evolves mobile phone usage to realms outside voice. And good luck to the gentlemen from MXTelecom and D2See 🙂

BBC 2.0

Mon, 13 Nov 2006 06:45:35 +0000

Hey! Free party! Mobile Monday members invited. (Better brush up some RoR to keep the small talk going).

But wow. I’m fascinated by http://backstage.bbc.co.uk/ – if the BBC can pioneer like this, then anyone should be able to. I love the idea of all these underlying data sources exposing APIs to a broad community of application developers.

It’s just like an operating system. Is http://code.google.com/ the new MSDN?

Planet Mobile Web

Mon, 13 Nov 2006 06:35:35 +0000

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.

Initial thoughts on .mobi

Mon, 13 Nov 2006 06:06:53 +0000

[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)?

The evolution of quality measurement

Sat, 28 Oct 2006 06:20:25 +0000

I’ve worked for Argogroup for the last five years or so, and we’ve been focussed on trying to help mobile data serices take off – by helping operators and content providers improve quality.

We did that using ‘active test’ techniques. Basically you simulate real users accessing your services and see what experience they would have had. It’s a great improvement (or complement) to using passive techniques to measure data traffic within the network to deduce quality.

But what’s next? I think even ‘active test’ needs to evolve. After all, how can you truly represent millions of users synthetically?

So I’m thinking a lot about this. “Quality of Service v2.0” I’m calling it. Basically, why not use the power of the ‘crowd’ (your users) to measure your quality for you?

Instead of benchmarking your web site, or mobile application, you’d ‘crowdmark’ it.

Or to put it in grandiose terms, imagine every terminal, every web browser, every laptop, every phone, hooked up to a vast, virtual, peer-to-peer instrumentation space. Every application or service comes with an embedded quality deduction tool – that not only measures its own performance, but encourages the user to record their own experience, and so shares and collaborates in measuring the performance of this and other applications.

If I am using an application like Placeopedia, imagine if my session was be able to give something back to the underlying ‘Internet Operating System’ services that it uses. Record the user-experience, for example, and share it back through the mashed-up APIs, to Google maps, Digital Globe, NAVTEQ, Wikipedia, Yahoo broadband, BT Wifi etc etc. My simple behaviour has added a small drop to the QoS data ocean. But that’s an essence of web2.0: act locally, interact globally.

And it’s not just about tracking protocol-level quality. Talk to the user, ask them how they are doing. Ask them to rate what they see. Let them tag their user experience!

What does Tripleodeon mean?

Fri, 20 Oct 2006 05:29:57 +0000

Well, I can safely say it means nothing!

I registered it back in about 2002, when I was intrigued by a number of things happening in the Semantic Web space. That’s a world full of ‘triples’. I also like my film. And for some reason a familiar kids cartoon network popped into my head. Before I knew it, I had a name.

Actually, I rather wish I’d gone for ‘Semantic Cinema’. Might still do 🙂

Er. The Beginning

Sun, 15 Oct 2006 01:52:58 +0000

Well I’ve had this domain for years, and never really did anything productive enough with it (except use it as my catch-all email domain).

Right now I’m feeling motivated to do something with it. Primarily a blog, I think, but also somewhere to put my Google Reader shares!

I’ve been impressed over the last few months with the collective enthusiasm around properly bootstrapping the mobile web. I’ve worked in this area since about 1997 (when the Unwired Planet products started crossing the pond) so it would be wonderful if it turns out that it took only 10 years for it to finally reach some sort of fruition.

I’m no environmentalist, and certainly far from green. But I’m scared about climate change. Rather than resorting to the common euphemism of ‘save the planet’ (which can probably look after itself), I’d go for ‘save the species’ (meaning ours). Bad times ahead.

And of course the web. It’s become a cliche to say ‘I hate buzzwords, but let’s talk about web2.0’. I think it’s great to unashamedly talk in terms of buzzwords! It’s that ‘collective enthusiasm’ thing again.

Probably also a good place to chuck links to a variety of other projects I’ve got underway.

Enjoy.