James Pearce

Moving on

James — Fri, 02 Dec 2011 14: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

James — Thu, 01 Dec 2011 18: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 tag, b) after the 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 and after the , 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

`screen.width` & `.height`

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 , 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.

`screen.availWidth` & `.availHeight`

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 availWidth and availHeight 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 width and height, 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.

`window.outerWidth` & `.innerWidth`

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 window.outerWidth, we have a good news story.

iOS v5.0 uses window.outerWidth 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 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, innerWidth takes exactly the same value as outerWidth – 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 window.innerWidth (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.

`window.outerHeight` & `.innerHeight`

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 window.outerHeight and window.innerHeight, it meets our expectations on the latter of these two properties at least.

For Android, window.outerHeight 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.

`body.offsetWidth`, `.clientWidth`, `.offsetHeight`, & `.clientHeight`

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 tag has closed – but the offsetHeight will be completely different. Secondly, when there is a doctype, the clientHeight and offsetHeight 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 document.body 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 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 `device-width` & `width`, `device-height` & `height`

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.

`window.orientation` & @media `orientation`

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 on Android. (Just remember not to evaluate orientation before the – 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 , 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.

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

James — Mon, 31 Oct 2011 22:30: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

James — Fri, 14 Oct 2011 19:00: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

James — Sat, 10 Sep 2011 23:13: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.

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

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 -like document whose main purpose is merely to include a 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.

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

James — Wed, 01 Jun 2011 07:42: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

James — Thu, 09 Dec 2010 19:52: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

James — Thu, 09 Dec 2010 04:52: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)

James — Wed, 01 Dec 2010 06:38: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

James — Wed, 01 Dec 2010 00:58: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!