discussion

Wednesday 15 June is but six days away now, so if you're in Oxford you should make sure you have Oxford Geek Night 22 in your diary for that evening. Not only are my employers Torchbox sponsoring as always to make sure it's free entry, but Historic Futures are putting some money behind the bar, enough for a free drink for every geek. Doors open at the Jericho Tavern from 7.30pm, so get there early to make sure you nab a pint or similar before the thirsty geeks work their way through it all.

Even as I speak, our two keynoters are girding their loins and exercising their generic-brand presentational software for the benefit of Oxford's finest geeks. Louise Crow will mark the very welcome return of mySociety to the Jericho's stage by talking about their forthcoming project Fix My Transport. Next up will be Tyler Tate, UX lead and designer, who wants us to look at how people learn, and apply that knowledge to improving usability for everyone.

We've also got four excellent microslots to look forwards to, volunteered by four plucky Oxford(shire) geeks. They're a mixed bag of subjects as always, and we'll also have the even more mixed bag of The Pitch, our sixty-second open-mic slots. Anyone can use these to announce or advertise whatever they want for a minute. There are also still a few spare Pitch slots left, so if you've got something you want to get off your chest, email ogn@torchbox.com to reserve one.

Right. Only six days to go and I haven't even printed posters yet. Or done any of a dozen other things I need to get done before then. What am I even doing, still writing this stuff? I've got work to do. Now clear off and I'll see you on Wednesday at OGN22.

Most web developers, when they find they have no other choice than to turn their hand to CSS, find margins a pain in the rear. This is because, unlike padding, the margins on a given element don't always appear the same on the page; the resulting space depends on what other elements are near them. But while rigid predictability is sometimes the most important aspect of some page structure, other arrangements of elements need a more subtle approach.

Padding is easy

Padding feels like a physical thing, analogous to the metal spacers once used in letterpress typesetting. It's like a second, inner border: inviolable, rigid in their shape. So a programmer "knows where he is" with padding, and if you convert ems or points to pixels on the fly you can pretty much "count the number of pixels in an element's padding" based on the original CSS declarations themselves combined with the size of that one element. You don't need to worry about what the neighbouring content will do, unless you've already made it behave weirdly with your own CSS rules applied to e.g. the other element's overflow.

You know where you are with padding. A declaration of { padding: A B C D } on an element of browser dimensions w × h yields an element area of wh and padding area of w(A+C) + h(B+D) + AB + BC + CD + DA. Always.

This means that padded elements will always take up the amount of extra space that you specify. On the one hand, this is very useful for pixel-perfect design implementation. If you have headers and footers - site livery - which have pretty much the same content on every page of a site, you can add paddding to the relevant elements and know that they will look just right. Because padding is simple, it's also less likely to be buggy (you avoid the IE6 double margin bug on your floated-left and -right devices).

However, padded elements are simple in another sense: they're stupid. Sometimes it feels like they're behaving like a man who's forgotten about the plank he's carrying across his shoulders, and barge other elements out of the way when a more subtle effect is required. 

Margins are hard

Margins, unlike paddings, pay attention to what's around them. The top and bottom margins of adjacent elements will, in certain circumstances, collapse onto each other. This sounds like either: just something you have to take into account; or, worse, a tricksy annoyance. But it's really because margins are not about pixel perfection, in the sense of making sure that a given element is a precise number of pixels from its parent, or from the top of the page.

Elements decide where they are with margins. The top element 1 has { margin-bottom: M }, whereas the lower element 2 has { margin-top: N }. The actual space between the elements (assuming no padding or borders) is M or N, whichever is greater: max(M,N).

Margins are intended to improve legibility and overall presentation when the designer cannot predict in advance the order of every single element. Content flow on the page can be improved by margins in a way that padding can't achieve: they attempt to lay out the content using whitespace that's as aesthetically and readably pleasing as possible, given many combinations of elements. This can be more important than you think in pages with a lot of (potentially user-generated) content: when you have lists, headings, paragraphs and blockquotes all jumbled together in any old order, how can you dictate the padding between any given two elements?

No rules only heuristics

Margins sound like they provide a lot of flexibility, but how should they be used in practice? If margin-top and margin-bottom are likely to collapse into those of other elements, is there a straight choice to be made between them; or, as a (probably too discursive) Stack Overflow question has it, which do you prefer and why?

The simple answer is that there is no simple answer. This is a conversation you must have with the original designer, if you're not sure what to implement. But generally unless the design has some odd layout that screams "ask the designer what they meant by this", here is a rough guide - a set of heuristics rather than rules - to establishing good margin and padding usage in your CSS. You don't need to follow these to the letter; but they're a good starting point.

• Paragraphs and ordered/unordered/definition lists should have symmetrical top and bottom margins. This is because they're "symmetrical" elements: a paragraph typically doesn't care about the content before or after it, but is just part of the page flow. It also means that the paragraph--list gap is the same as the list--paragraph gap, which makes a kind of semantic sense. Depending on the "tightness" of the design whitespace, paragraphs will typically have 0.5-1.5 em vertical margins; lists could have as much as 2em.
• Headings need bigger margins above than below. This is because while a heading's text marks the beginning of one section, the whitespace above it implies the *end* of the previous section. Headings should therefore bind more tightly to what's below them.
• Blockquotes can be spaced vertically like lists. They also need horizontal spacing, which browsers typically apply with margins. You should be able to do this too, although padding will work just as well and will also provide you with a decent canvas for things like speech bubble backgrounds. 
• Structural elements like divs shouldn't need any margins but can inherit the ones from their children. If they're in the header and footer, use padding to make sure they sit correctly next to other elements on all pages.
• However, overall header, footer and section containers (whether this means the dedicated new HTML5 elements or just divs with particular IDs) should have some vertical margins on them, so that there is still nice amounts of space between them and any accidentally un-margined content (or if a paragraph next to the footer would otherwise end up too close.)
• Horizontal margins don't collapse. Because of the aforementioned bugs in IE6, I would typically use horizontal padding instead, unless you're sure that the element is never going to float. The end result is almost the same either way. Exceptions to this rule include when you have a limited choice of markup (you can't use nested divs and horizontal padding instead, for example.) You should still test them

You can start by blindly applying the points above, but please don't assume that they will invariably lead you to the specific design you have to implement. You'll always have to take that step back and consider: what margin will this element "like to have", when it appears on the page? What if this paragraph element (for example) is adjacent to another paragraph, or a heading, or a list? And what might the heading or list have to say about its own margins in that case?

When "it depends" is the best answer

Because margins have a cleverness to them, the temptation is often to out-smart them; to hem them in with extra CSS rules; in effect, to use tricks which make margins behave more like padding. I don't mind these so much, but I think they miss the point off margins, which is: like CSS itself, they do some of the typesetting work, so we don't have to figure it out every time.

This doesn't answer the burning question, though: margin-top or margin-bottom? Who's right? I think it's worth going through some of the discussion on that Stack Overflow question and examining it in the context of "intelligent margins", or maybe "margins giving us intelligent elements" to see whether there can ever really be a last word in the great debate between top and bottom.

I always use margin bottom, which means there is no unnecessary space before the first element.

If you're using margins at all, then you're saying that it's up to the elements to decide what is and isn't unnecessary. If a paragraph needs a bit of air to flow around it, then it will probably still need that if it's at the top of the content area; by using margin-bottom, you're denying the first paragraph its air. Of course, you can fix this by making sure that whatever elements paragraphs are in are always somehow padded away from the elements above them, but you lose the cleverness of margin-collapse during the fixing. Besides, for every design that calls space before the first element "unnecessary", there will be another design which makes that same claim about space after the last element.

Depends on context. But, generally margin-top is better because you can use :first-child to remove it.

Yeah I usually use margin-bottom as well and then assign a last class to the last one in the bunch.

These both seem to be falling into the same trap as the previous question, but coming to that trap from a different direction. Having to establish special rules for special elements, in order to make a container wrap tightly around its contents, seems an odd thing to do. If your container is tight, then you have to implement extra rules to make sure that container keeps its distance from other elements. Which you can force with other layout elsewhere, but it's what margins are meant to guarantee.

Incidentally, as an aside:

This really depends on what you're designing it for and why. Something you could do, which is helpful, is setup generic styles for default padding/margins you commonly will be using

I would assign spacing on elements in a semantic fashion, and use contextual selectors to define behavior for that collection of elements.

I agree with the second poster completely here. In fact, one of the reasons I didn't put a glib "it depends" answer on the SO question in the first place was that the first of these two posters started his response in the same way, but then the rest of his answer was wrong enough that I was wary of joining an "it depends" camp.

But as I thought more and more about the original question, and all its SO answers,, I realised there was another reason that I didn't want to answer it directly. There is simply no answer within the context defined by the question itself, and shaped by all the existing replies, that I would consider valid. No combination of margin-top, margin-bottom and rules about contexts can themselves help dictate good CSS practice. I did think initially that the question should be closed as subjective, but maybe instead it would be better to answer it: not, "it depends"; but, "it's a bigger problem than the question permits."

Recently a blogpost discussed Jen Lampton's superb conference session: "Wordpress is better than Drupal: developers take note." The author said that they really liked the session, but

• Wordpress isn't actually better than Drupal
• Because you can't compare Wordpress and Drupal
• So the usability issues arise from a false comparison
• And here's what's going to solve our problems instead

In the first paragraph or two it managed to simultaneously both praise Jen's talk and completely deny the core message of it. I think that highlights a number of trends in the way that the Drupal community as an aggregate (though by no means as a whole) tends to think about usability versus technology. Actually, I think the communities behind most large open-source projects behave this way, and it's ones like Wordpress or Ubuntu that are actually unusual. But I think it's worth talking about this phenomenon in the context of Drupal.

Apples and oranges

Anyone who argues a point of view can be sure they've ruffled some feathers, when someone else complains that they're "comparing apples and oranges." It's a definite sign that the complainer doesn't like the problem that's been raised, and instead wants to treat an informal analogy as if it were a keystone in a tense, logical structure; then attack the analogy instead. It's like hurling around cries of "ad hominem". It doesn't really prove or solve anything. Apart from anything else, what if my point is to compare apples with oranges?

Whatever you compare Drupal to, whatever your motives, whatever important (often fundamental) issues you want to highlight about the way Drupal does things... eventually you'll have to compare Drupal to something that isn't Drupal. You will have to compare the apple to some other fruit. That's the only comparison worth making. Are we just going to forever compare Drupal 5 to Drupal 4.7, Drupal 6 to Drupal 5, and gradually Drupal 7 to Drupal 6, purely as a teleological exercise in patting ourselves on the back? Of course not! And however close the something else might be to being Drupal, there'll be some slight difference, which will inevitably provide an opportunity for hairsplitting. Maybe we could call it fruitsplitting instead, because that difference in variety of fruit can be used as an excuse, if not a reason, to dismiss your broader motivations in making the comparison.

"X isn't a CMS." "Y isn't in PHP." "Z isn't aspect-oriented programming." "P is aspect-oriented programming, but it's intended to be purer than Drupal, with pointcuts." "Q doesn't have a genial tousle-headed giant as its benevolent dictator."

Apples aren't oranges, but then some apples aren't the same as other apples, either. Apples come in all sorts of varieties. So you can even compare apples with apples, if you like, and someone will come along and protest. Except they won't so often these days. Want to know why? Well, here's a story about apples, from the ever-readable George Monbiot.

Briefly: there used to be a huge market in different apple varieties. Hundreds and hundreds of varieties: Belle de Boskoop, Michaelmas Red, Brown Cockle. And then the supermarkets came along, and they decided that they could essentially compel their customers to standardize on a handful of apple types: Royal Gala, Jazz, Cox's. They did it, because the customer didn't really mind what type of fruit he was eating.

And that was essentially the end of the line for most types of apples. "Extinct, extinct, extinct." Most of them just gone. The free market effectively wiped out those varieties, ruthlessly and ignorantly. It reduced the number of breeds to a tiny fraction of what it was. People compared apples with other, different apples, and they just picked... apples. Nobody will fruitsplit between apple varieties now, because they're just all apples.

Drupal already has plenty of greengrocers, fruiterers of the programming world, people who rightfully and meticulously care about, and tend with love to, our apples and our oranges. But the prize, the broad user base, the real success story... that all lies in attracting non-greengrocers. And they'll just think: "Apples. Oranges. Other apples. Whatever." They probably won't care about different types of fruit; they've been told that their website has to have its vitamin C for the day, so they'll get the apple that's easier to get into, and to hell with your awkward-to-peel oranges. If your business model depends on selling individually wrapped fruit to other greengrocers, then good luck with that. I'm off to take some coals to Newcastle.

Who's going to tell the customers?

The blogpost suggests that:

Instead of comparing a toolset and a product, there are other, appropriate comparisons that businesses and developers should be making...

Well, it's wonderful that I know that now. But who's going to tell everyone else to change their ways? Is there going to be some sort of government-funded outreach programme? Will we all be making some sort of world tour? I try to picture a random drupal.org user appearing, like a superhero in a flash, in offices around the globe. "Hark! I hear someone in Mumbai making comparisons between Wordpress and Drupal that appear reasonably valid to them based on their expectations derived from: Drupal websites, Wordpress websites, drupal.org and wordpress.org. Yet I must intervene, swiftly! To the nearest train station!"

Anyone who decides that the solution is to tell businesses and developers what comparisons are appropriate will end up like Wowbagger the Infinitely Prolonged, travelling in time so that they can tackle simultaneous disparagements of Drupal. We can't rely on that: Drupal ultimately has to be able to say this for itself: it should be obvious to these businesses and developers what Drupal should be compared to. Otherwise these businesses and developers will continue to make comparisons based on the (admittedly incomplete and sometimes wrong) information they have available to them. 

Saying what comparisons end users ought to be making is a lot like that other canard, "educating the user." Unless you're talking about a site's administrative user base, people at a client who you could count on one hand, that's a pretty mammoth task. Who gets to ensure that such universal education about the vagaries of, say, module weights, or the vagaries of CCK field display, eradicates doubt in the same way that we once got rid of smallpox? Similarly, if Drupal's success against Wordpress depends on people only ever making the comparisons we want them to make, we're in trouble.

There's also tendency to call Drupal a CMS, right up to the point where someone complains it can't do what a CMS does out of the box. Then it's called something else. A toolset. A content management framework. A management framework toolkit. A content toolkit framework management system tool. It might deflect debate, but ultimately the jargon just puts people off. You might have won the battle with potential new users, but the war goes to whichever CMS with limitations that accepts from the outset that it's a CMS with limitations, and tackles those limitations---in Drupal's case, most notabbly user experience and getting started with it if you've never heard of Drupal before---head on.

The documentation on Drupal.org is pretty impenetrable to the average newbie, but if you can figure it out then you get the impression that Drupal is basically a CMS, a bit like Wordpress only with other (waves hands) stuff. So it must have a WYSIWYG editor, only somehow more so, right...? And the user experience of Drupal 7 is a great improvement, much like improvements that have already happened in Wordpress; but, despite the fantastic news that we're moving to beta releases, only greengrocers are using that right now. If we want non-Drupal users to make the right comparisons about Drupal, today, will we really fix it by arguing about distributions; products; toolsets; downloads; projects; modules; features...?

The technology will save us, of course

Here's a handy tip. Technology alone will probably never save you. You only have to have sat through Jen's talk, and to have read about Hagen's similar Wordpress-Drupal-Joomla walkthroughs in the unconference on DrupalCon Monday (I blogged about Hagen's marvellously excruciating walkthroughs on the g.d.o usability group) to know that the technology won't save us. Or rather, specific bits won't save us. Aegir won't save us. Products won't save us. Distributions won't save us. The drupal.org redesign probably won't save us either, because that's nearly finished and yet we're still denying the very usability and expectation problems that are still in plain sight.

Don't get me wrong. All of these things are great tech--really fantastic, mindblowing tech---and they solve specific problems that developers come across. I think drush make is one of the most exciting bits of Drupal I've ever used. But I'm a developer! Of course I will think that! Not only do I know how to set a Drupal site up in 15 minutes, but I also know from experience how to avoid the many, many ways in which it will take you two days. These tools  don't fix the fact that Wordpress is easy to use. Wordpress just works. Drupal needs tools to help you install it, and command-line fu before you can even make those damn upgrade errors go away, go away, please just go away.

You can't wait for technology to solve these things. Distributions won't change the fact that you can click around the drupal.org website for ten minutes and still not be completely sure what it is, or how to use it. The learning curve is still too large; and I'm just talking about how you use drupal.org, not how you use Drupal. Until everyone in the world is re-educated to know, and care, about what a distribution is, and how it's subtly different from just getting the blasted thing to work, then distributions won't save us.

What will save us is usability. User experience reviews. Jen Lampton's talk. Hagen Graf's talk. Watching users try to get to grips with this thing we love, when they just don't love it so much, won't excuse it as much. Feeling the cringe when a new user falls into the same trap over and over again, and knowing you won't be able to appear on their shoulder to help them. Then, though: this is key. You can't just say, "well, we'll let the themers fix that," or "maybe the forums can discuss it," or even: "when users ask for the wrong thing it is rarely, if ever, the right answer to humor them." Instead, you have to accept the application has a usability problem; and work out a plan fix it, right there and then. Developers, deciding to fixing usability problems above functionality problems. Again and again and again. Test, observe, cringe, fix, repeat.

It's a slog. But it could work where technology won't, because ultimately end-user functionality with serious usability problems will end up massively underused, and as far as the greater course of Drupal is concerned it might as well not be written.

Does this matter?

I feel like I've gone on a bit, and if you feel like that too then I apologise. After all, the usability community in Drupal is healthy and growing. People are starting to take usability seriously. But I feel like there's still no UX standards to point to, with the same weight and depth as the coding standards. Talk is silver; code is gold; UX is presumably 24-carat meh. There are still no easy ways of sharing usable interface patterns as easily as one might share patches. Usability is still a teenager, and it's easy to freeze it out of the conversation it in favour of adults talking about established technical preferences. Usability needs cultivating, and the user's behaviour needs to be king, whatever comparisons that user might make. We're right to worry about Wordpress, but that's a good sign! It means that Drupal is doing something right. It's worrying about the user.

Maybe, returning to the original blogpost, "the time is right for Drupal products." I'm happy to agree with that. Featurization and ease of deployment certainly suggest that productization will swiftly follow. But that has nothing whatsoever to do with the usability talks. It really won't solve the fundamental problems that Jen's talk tried to address.

One thing she said really stuck with me; as a developer, I took note. Well, I took lots of notes, but here's what stood out for me:

"Wordpress is behind us, but they can move fast, and they're looking at us."

With version 3.0, Wordpress quietly turned itself into a CMS. Maybe they saw fields were working well for Drupal, and thought: we'll have that. "It's simple but it'll do: let's ship!" Bang. Instant easy CMS. Usable too.

That's the point, in the end. Usability is not a nice-to-have. It's the canary in the cage, the indicator species: when usability suffers, it's telling you about lots of other attitudes that lead to the user being made unhappy. Whereas Wordpress emphasizes usability; it's friendly to the user out of the box; with things rich-text editing that the user wants to have without any issues; with straightforward media management; and with upgrade methods so simple they're frightening.

Drupal? Drupal's a brilliant, smart, well-oiled, massively functional framework (it's far more fun to develop with than Wordpress.) It's a CMS, except when it's not (but when it's not, it's still a rich seam for developers to mine.) It's still tricky for newbies to install (but developers learn the tricks.) Image handling is odd, and if you pick the wrong method early on you're in for a lot of pain later (but developers know which one to pick.) Upgrading modules is not a one-click experience (unless you're a developer and you've played with drush.)

Yet with all that in mind, here's a question. If you'd never heard of Drupal or Wordpress before, and you were 90% of the internet, rather than a developer; if you were the same sort of user as a client's marketing guy, who's never written a line of PHP in his life; based on the experience of trying to get each of them up and running yourself, which would you choose? Apple or orange?

I've all but finished my "live blogging," such as it was: DrupalCon Copenhagen actually ended a week ago, so "live" is stretching it a bit. But I had a fantastic time, and a large part of that was attending the self-organising and friendly "Birds of a Feather" sessions that are planned by attendees on parallel tracks to the more formal, session-based conference.

It's worth mentioning two of them here, because the attendees made them both such a tremendous success. The first was a "Drupal for NGOs" session that I put onto the schedule, to try to get people from NGOs, not-for profits and charities---the majority of our clients at Torchbox---to be able to share problems, solutions and stories from the trenches in a receptive environment.

I helped facilitate the discussion but really there were a lot of people there with brilliant ideas and lots of ideas to share, so it wasn't exactly hard. We made a few notes here if anyone's interested in finding out what happened, or getting in touch with any of the other attendees.

The other event was the Drupal CRM BoF. Plans are afoot to build a native CRM in Drupal, possibly as a mega-feature or a distribution, and Chris and Joachim helped put together a really dynamic and productive meeting on how we might move to a full CRM in Drupal, being very clear-eyed and critical on the way: even the question of "do we need a native CRM?" was considered. I think this really strengthened the final outcomes of the meeting, and the Drupal CRM project is now on a firm footing for future development.

Chris wrote up the meeting itself; I believe Joachim had further discussions during the Friday code sprint with other stakeholders, and has begun to document the architecture arising from that. Meanwhile Steve is keeping track of documentation generally so the CRM group can keep focussed.

All in all the BoFs, more than the sessions in a way, showed that the community is one of the real strengths of Drupal. When a loose collection of contributors are unleashed on a subject, there's no limit to what they can accomplish. When Joachim first told me that he had come to Copenhagen largely to network rather than attend sessions, I thought he was mad. In retrospect, I'm starting to see his point.

Recently my wife and I were trying to work out why she couldn't submit her address details to a website, even though I could. As we watched her behaviour in filling out the form, we encountered error after error: or rather, exceptional circumstance after exceptional circumstance. And it was clear that very few of the circumstances had been considered, that error handling was the absolute bare minimum, that the form was set up to be almost a trial to use. The postcode lookup part of the process was probably the source of the most unhandled exceptions: difficult if not impossible for the power user to flow through; unwieldy for the standard user; of almost no benefit at all to the web newbie.

People still think of their workflows on the web like they're workflows. Over here there's the start; over there is the goal; somewhere in between there might be some intermediate stages, but ultimately you go from over here to more or less over there eventually. It comes as something as a shock to most people that their beautiful webform does not encompass a workflow: the web has holes all over it; the user is a ball bearing and your application is a pinboard:

Above we see a slightly clumsy metaphor for your web application. The end point of your own particular "workflow" isn't even something visually obvious like the shark's head. It's, oh, let's say that small metallic gate in the bottom right with the red doors (luckily for you) open. The best you can hope for is that the user caroms through your website hitting as few pins as they have to and ends up in one of a trillion end points, that they don't close the browser, or reach a form error, or silently lose their submission, or navigate elsewhere in irritation.

In fact, it dawned on my wife first, and then gradually on me, that postcode lookups are not intended to directly benefit the user filling them in. Instead, they're meant to force the user---remember that phrase---to provide a canonical address, and not the address. That is, the user comes to your site with an opinion about where they live and limited good will about your "product", and the postcode lookup is a mechanism for forcing them to discard the former, while the application as a whole is trying hard to get them to keep hold of the former.

Good luck with that.

Richard Rutter figured out the dirty secret behind postcode lookups---that they're not for the user---long before my wife and I. In order to mitigate this natural tension between forcing the user and keeping them happy, he's done a sizeable chunk of work to condense the postcode lookup pattern here. Along with a quite lively and informed conversation in the comments, this post nails much of the core of the pattern that lookup needs. Much of what's frankly miserable about using a postcode lookup is indeed tackled there, but there's an important omissions that I think needs dealing with. Roughly speaking, that is: never force your users to pretend to be someone they're not.

As an example, consider Spotify. Since inheriting a slightly ropey eMac, I've been able to listen to Spotify, and I like it. I think Spotify is a gamechanger in the field of streaming music. I've heard albums on Spotify that I would never have bought. And yet: I would never consider purchasing Spotify Premium. The obvious barrier for me is that I use Linux, and there are no native Linux binaries for the Spotify desktop client.

People keep telling me that Spotify runs really well on the Windows emulator WINE. I'm sure it does. But that misses a more fundamental point: if something wants me to enter into a relationship with it, commercial or otherwise, I should not have to pretend to be a demographic I'm not in order that the relationship can be properly fulfilling. I'm not a Windows user, and it's an affront to a paying customer to expect them to make out that they're a type of user that they're not if they want to buy your stuff. More consisely: I don't take offence at the interface requirements; I take offence at what they imply about the respect for my needs as a user.

With that in mind, consider the first decision block in Richard's workflow:

does the user know their postcode?

As this is the first pin the user's pinball hits, then this is the one that alters their final resting place the most. This is the critical pin. And what does it tell me, a user who knows his postcode but also knows his address, and doesn't want to bother with lookup? It tells me that I have to pretend to not know my postcode if I want to be in a situation where I don't have to put it in. I have to play games with the application, and mask my true intentions. No, the postcode lookup system must allow for users who simply do not want to fill out their postcode. Postcode lookups should therefore begin with a simple choice of two buttons by a traditional form label. The buttons should not make any assumption about the user's reasons for choosing either route:

Address:  [LOOK UP POSTCODE]
               [JUST LET ME TYPE MY ADDRESS]

When you press the first button, both buttons should still remain on the page: the user might decide they wanted to press the second one after all. In fact, as we're probably using AJAX here, the minimum necessary modification to the form is just to add a postcode box (and to move and maybe change that button) like this:

Address:  [ postcode ]   [LOOK IT UP]
               [JUST LET ME TYPE MY ADDRESS]

You should still present the user with the ability to change their address. The "speed bump" of having to press the button is what works in your favour, is what gets you access to canonical data; anything more than a bump will run the risk of walloping the user right off your pinboard.

If at any stage the user clicks on the second button, the webform should then change to this view:

Address:  [ Address, either as a set of textfields or as a textarea ]
               [ postcode ]   [LOOK IT UP INSTEAD]

For simplicity, I'm almost tempted to drop lookup button altogether at this point: the user has made their choice, after all. But you should never make it difficult for users to go back in a workflow, especially when (almost certainly) the browser back button will have been disabled by these shenanigans.

In comment 10 on his blogpost, Richard agrees with the idea of one big textarea for the address: possibly even including the postcode in that textarea! Again, the simplicity is appealing. You could do all sorts with this to make the user's experience easier: regex matching behind the scenes would retrieve the postcode; the address could even be automatically split into lines rather than setting real estate aside for the user to split them up themselves. It sounds great, but it's not an established pattern, and I think a lot of users---especially power users---would mistrust it. Better to go with Address 1, Address 2 etc. even though from a data perspective they're a horror, slightly improved---but, again, made more complex for the user---by labelling the last address line as "town". But this last detail is up to you. Do some A/B testing. See how it goes.

Richard's workflow, with the addition of the basic prototypes above, permits us to move towards as usable a system as postcode lookup will ever be. Usability means the least number of pins on your pinboard, and exactly the right pins, the ones that nudge and tilt the user just enough. And so we end up with a system that still satisfies your original remit---to nudge the user towards using your shiny, expensive, time-consuming, postcode lookup service, with all its concomitant costs in development and maintenance---while catering for the users who simply do not want to, who will never want to, and who will actively object to your site giving them short shrift if they try not to use it.

I'll make a prediction here, that the users who try not to submit a postcode will tend to be the users you want: the digital natives, the users in flow, the people who will buy ten things from a polished user interface without even stopping to think about it. When they reach that very first pin on the board, they briefly want to be your application's friends on the web. Your application should consider itself honoured. The least it could do in return is be polite.

Now that the Eurostar tickets are booked, and the hotel more or less booked, I can state that I'm definitely going to DrupalCon Paris, starting on Tuesday 1 September. After DrupalCamp I just can't wait for a concentrated dose of Drupal, working and talking with like-minded designers and developers and having fun with these people that are otherwise just nicknames on Drupal.org or IRC.

I'll be arriving in Paris at 8pmish on Monday 31 August, and after stopping off at the hotel would love to meet up with other Drupalers. Currently The Financier Pub near Montparnasse Bienvenue has been mooted for a Wednesday meetup, and much as I'd like to go for local colour I'd be happy to meet there on Monday too if anyone's around.

(I'm definitely going to Paris. But if the hotel doesn't work out I'll see you in the Parc Montsouris.)

It's heartwarming, really encouraging to see that Drupal 7 is undergoing a usability review. Drupal's a massively functional CMS, but all the functionality in the world won't help you when the average (for which read: can't write HTML, let alone PHP) CMS user can't discover it. There's a common misconception that usability is the finishing touches you add to an application if you've got time, the icing on the cake; but if your application lays any claim to maturity then its usability is the cake, and all that functionality you were so proud of is, without usability, just eggs and flour.

One of the main usability improvements suggested by the usability team---and largely shouted down by the technical team---is the ability to edit inline on the page: that is, to log in as an admin, then have any bit of the page "active", so that if you click on it then it becomes an edit box with the text inside. Flickr does this especially well, letting you edit title and description on photo pages and lists of photos by just clicking on the apparently uneditable text. But Flickr has the advantage that there's very little form on top of its content: it's a delivery mechanism for the raw metadata about photos, and the photo itself.

The other end of the spectrum---which complex CMS sites have every right to sit on---is a rich and complicated mapping between the storage of a node's content in the database and the eventual display of it in the browser. take a page from a recent Torchbox project at random, how would you expect areas of this page from the Joseph Rowntree Foundation's website to behave when you clicked on them? If you have to hardcode print statements in your PHP templates, what do you print? How do you get editing inline to work? What happens when content is brought in from other, related nodes, and mixed in with the other content before display.

I can appreciate both sides to this story of user experience versus technical practicality, although it's not sufficient to expect the usability team to discard the idea merely because there's no correspondence between page content and database content: that's only an argument for why Drupal doesn't currently have edit-on-page. The usability project is moving forwards rapidly, and while there's clearly a tension between usability for the CMS user and feasible technical limitations---usability for the developer, if you like---it will need to be resolved soon for this marvellous work, and a great opportunity, not to end up wasted. And resolving that conflict will involve some sort of compromise, for both sides.

One possible compromise would be to offer edit links, when Drupal can spot a sort-of 1-to-1 correspondence between a fragment of page content and the node that supports it. Page templates and views---specifically hook_preprocess_node and hook_views_pre_render---know full well that what they're processing is a node. And they generally know what field the node title will be in. So let Drupal rewrite the title, to add an "edit inline" link. If anyone clicks on this link, then pop the node-edit form up in a lightbox for editing.

Here's some screenshots of what I've been working on, in an attempt to get people interested (click for bigger.) Firstly, here's what the anonymous site visitor sees:

Next, here's what happens when a user has just logged in. Note that the brilliant Admin menu module kicks in, giving the user a black navigation bar across the top. But, more pertinently, each node title also now has an "[edit inline]" link beside it:

If the logged-in user clicks on one of these new links, then our edit-inline module kicks in and, using the equally brilliant Drupal Thickbox wrapper module, provides a stripped-down version of the node-edit page in a Thickbox overlay, both speeding up node editing using AJAX calls and also letting the user cancel the node-edit procedure and return to the webpage they were on quickly:

To reiterate, you don't have to be on a node's page to edit it. All that matters is that the title of the node you want to edit passes through onee of the supported pre-render hooks. Currently, clicking on save/preview/cancel takes you elsewhere rather than being trapped within the Thickbox, and we're also wrestling with getting CSS and Javascript into the Thickbox overlay to support the nattier bits of node editing, but it's functional and, I hope, gives you some idea of how it would all work given a few more hours of bashing away at keyboards.

Anyway, there it is. A possible compromise. I've mentioned it in a comment on the d7ux blog but I fear I might have been eaten by a spamtrap. If anyone's interested in the project then email me, jp.stacey, either at gmail.com or torchbox.com, and say hello.

Via Sean McGrath comes a reasonably lucid and comprehensible redux of the argument about of whether or not the XML standard should (or should have) stipulated draconian error handling. I hope I'm not misrepresenting Avery when I boil a lot of it down to his three broad "real-world" examples to this:

1. Not well-formed XML, produced by a legacy application that takes ages to fix, is rejected by draconian parser
2. Not well-formed XML is accepted by a permissive parser
3. Well-formed XML is accepted by draconian parser

and I hope he's also happy for me to then state that his argument consists broadly of the suggestion that 1 and 2 are together more likely than 3, hence permissive parsers obtain for you the lion's share of the "real world" parsing instances; or, if you prefer, via a slightly more complicated profit-and-loss argment, that making your parser permissive, and sanctioning permissive parsers, contributes a lower overall cost through lumbering us with poor legacy applications, divided up among all the parsing events, than having to fix those legacy applications.

However, an application of Postel's Law to the process of implementation should not be confused with being able to apply it to the original specification. And besides, do those examples really portray the real world, nearly twelve years after the argument first took place? How much XML is out there, and how much of it is bad XML, and how much of it remains bad XML for long enough for it to cause a problem? I don't think it's clear that draconian error handling in the wild has held back RSS syndication, Google Maps, web services, or RDF so much as that, beyond a certain tipping-point (say, 2002?) they've ensured the rapid takeup thereof (with the possible exception of RDF until recently, for its own reasons).

XML is unbelievably popular today, so popular and routine in its use that you almost don't know it's there in most applications. and I think---purely from my own experience---it's plausible to suggest that that's at least partly because consumption of XML is easy; in turn, this is because basic production quality is enforced.

HTML (SGML) is a format (specification) that, because of its messiness (its complex rules), its parsing permissiveness (its potential for misunderstandings), and a whole host of cultural reasons (ditto), was terribly hard to write reliable consumption software for. Even now, there's around half a dozen good browsers, and in part that's surely because of the entry barrier to writing browsers: permissive parsing of real-world mistakes remains a complex task.

I also have dim and partial knowledge of SGML in the old-skool publishing industry, where a licence for fully-featured SGML software could set you back tens of thousands of pounds six or seven years ago, and that price didn't seem to be heading down under market pressure. In comparison, XML parsing is cheap, easy, and ubiquitous. There are free and open-source CMS and blogging packages that can do it; I have access to dozens of command-line tools that can do it; publication, syndication and webservice consumption are things that happen, almost as though nature intended it that way. A lot of that must surely be down to XML's combination of rule simplicity and parser rigour. As Dave Winer says on the subject of Postel's Law and XML:

I yearn for just one market with low barriers to entry, so that products are differentiated by features, performance and price; not compatibility. Compatibility should be expressed in terms of formats, not products.... Anyway, the other half of Postel's Law is just as interesting, but so far no one is commenting. Think about it, if everyone followed the second half, the first half would be a no-op. You could be fully liberal in an afternoon or less.

Mark Pilgrim's history of draconianism versus tolerance seems to consist of a lot of tolerantists pontificating about what they've decided the "draconian" argument is: I can't believe that Tim Bray, even if he really were a lone voice, would have been such a reluctant paper tiger. But like the 1997 tolerantists, I've thus far waded in with my own interpretation of events. And despite dealing with XML on a daily basis, I find that during so many of the tasks I have to accomplish the XML layer is able to fade almost completely into the background.

Of all the problems I encounter at work well-formedness of XML happens very rarely, compared to those concerning the quality and stability of my own algorithms, application control flow, scaling and coping with heavy load, and logging and bailing out. Whether XML's ease of use is in 2009 is a result of the small rule set in XML making well-formedness easy, or the initial decision in favour of draconian parsing, all decided back in 1997, we'll probably never be able to tell. All that's certain is that there'll always be opinions about it, and somewhere in the rambling above is mine.

The considerably more hirsute than previously Rob Purdie put together yet another great Drupal for NGOs meet-up yesterday in London. Bryan and I hared over from Oxfordshire, getting there only fifteen minutes late, but people were still making their way through the beer and nibbles very thoughtfully provided by our hosts.

Comic Relief's offices weren't quite what you'd expect---a smart floor in a posh block, right by a certain security service's s3krit headquarters---but definitely very Comic Relief, as you can see from the distinctly nose-coloured cast in the photos of the event. Rob managed to keep breaking the ice all evening, with such ruses as encouraging a group photo of everyone with angry faces.

The two main talks were as informative as ever, although there was definitely a different feel to them. Whereas previous "big-hitter" NGO projects showed Drupal in an "enterprise" environment (make of the words in quotes what you will), the slightly more close-ended projects, presented by the majority of the development team involved in them, warmed the group as a whole up more: there was more discussion in the round and sharing of---or at least hinting at---solutions to common problems. Oliver MacColl, Brett and Ben Dodd presented the inmyname.com / White Band Action, and Francesco Moretto discussed the implementation of CiviCRM and Drupal that lay behind the recent online relaunch of UNIMI's alumnus society, ALGIUSMI.

You can't get the likes of Amnesty International or Greenpeace to talk at every meeting, so it was nice to see the event's structure capable of embracing projects that were no less impressive by not having a big name behind them. It bodes well for the future, too, as smaller-scale Drupalers should feel emboldened to come forwards and share their experiences with everyone else.

If you weren't there, there's now an IRC channel devoted to the UK Drupal scene, where a fair few of the D4NGOs crowd hang out: do pop in and say hi.

Currently live blogging from the Google Developer Day, London 2008. Fittingly the live blog is a Google Doc.

Like a moron, I left my mobile phone at home, and then ended up separated from everyone I know; so have a look at what I'm liveblogging and find me, if you care.

Edit 2008-09-18: notes now below.

The End

Lightning talks 16.25-17.35, SF2

Google App Engine
  <head> web conference - headconference.com
  Old days;
    An app would be built, load-tested get discovered, and die. 
  Now:
    You test with ONE person, it gets discovered, and GREAT!

  Construction phase
    More complex
    Tools more limited
      Both of these have their reasons

  1,000 files
    Django source > 1000
    Solution: Guido van Rossum: http://icanhaz.com/zipimport ; rietveld on Google OS

  1MB limit on ALL data structures
    You will run up against this EVERYWHERE
    Can't combine files on server
    Solution: Amazon S3 - infinitebits.info gives FTP access

  No long--running processes
    Solution: hack it with HTTP refresh!
    Web-based cron! webbasedcron.com

  Short-term quotas
    24-hour quota
    Uncatchable
    Bad advert!

  Backup and restore
    GAE Backup And Restore (uh-huh)
    Open-sourcing it

  Django
    Google are not into developing application frameworks
    So basically use Django, dudes.

  http://opencountrycodes.appspot.com/
  http://isvat.appspot.com/

Android work, Kevin O' Sullivan, Sita

  Airports still run on 60s technology!
    Looking at mobile technologies
    Predictive analytics from ACARS data - archived and ignored

  Passenger mobility
    Smartphones, context-awareness

  Application
    GPS
    Mashup, overlay with airports

    Click on airport and get Arr/Dep info, querying a backend system

RDF, Tom Morris
  RDF as an open-knowledge enabler
  URIs in the data
    Links to other documents
    URIs that define something e.g. wikipedia:Cities:London

  Mashups
    PITA - be a developer
    Or have the data link itself together
      "Let's all use the same names"

    dbpedia, bbc.co.uk/programmes
    libris.kb.se - Swedish Nat lib
      every book has a URI

  SPARQL
    A bit like SQL

  sindice.com - search existing linked data (DERI - digital something research inst)

  Libraries + making easier for JS/AJax devs

Green Maps

  Green maps - Anna approached for Glasgow  Green Map
    Open project for local community?
    ... Get them to do the work
    Also existing reuse groups - the Electron Group

  Put out leaflets everywhere around Glasgow
    "Enthusiastic developers!" "Enthusiastic designers!"
    ... bugger all
    But presented at arts school and got lots of volunteers

  Dear Green Place
    website deargreenplace.org

Visualize your data: Google Visualization API, Nimrod Talmon, ->16.10, Atari

  Types
    Generic
    Specific
    "Hard"

  Examples - iGoogle gadgets
    Wrapped in Javascript, exposed to the iGoogle framework via an API

  Problem:
    Potentially many data sources
    Potentially many visualization sinks
    Many APIs - hard to find "the right one"

  Google Visualization
    Seems to be a generalization of Google Charts

  Google Finance - generic stock charts, embedded into GF

  70 lines of JS code for a simple-ish 10-20 point graph with widgets

  Why?
    Google does the visualization, so fast & scalable
    API built with devs in mind

  Premise of visualizing
    Abstract a visualization
       Data
       Appearance
    Model objects from Google's API
       google.visualization.TypeOfVisualization() ... chart.draw()

  (Nothing should ever make it easier to build pie charts. Especially three-dimensional pie charts, the anti-visualization for people who won't get numbers anyway. Tufte FTW!)

  (A bit hard work -  data.setCell(x, y, 'Label') is a bit like <cfchartdata>. JSON methods?)

  Q; data going to Google?
  A: Javascript call to get API, but here generation is in client. Others in Flash wrapped in JS.

  Q: other formats e.g. JPG?
  A: ?

  Events & actions
    Own event model
    Visualisations listening to events and communicating between each other via closures addListener(fred, 'select', function() { barney.method(); })

  Data views
    Dynamic re-slicing off the data you're using for one vis, potentially for reuse in another
    Not a new data set - change the data, change the view
    Like SQL views

  Q: aggregate functions?
  A: wait 10 mins

  Why develop for Google Visualization?
    Reach - de facto standard
    Viable business model? Panorama, Eureka

  (Note to self: ESC :w does not work in a Google doc)

  Extend API with new visualizations
    Declare draw() method on prototype

  ... slightly dry but interesting demos... they shouldn't have these things just after lunch....

  SQL-like syntax querying Google Spreadsheets... Pretty cool, but count the number of browsers that will deal with this scalably: I make it two.
  Ah, this might only be happening server-side. Phew. I wonder if I still have that Bobby Tables spreadsheet lying around anywhere.

  Visualizations laid out on the webpage, about as well as MS Word does it in a document, only you can dive in and work out why everything keeps turning bold, dammit.

  Q: Accessibility?
  A: Don't have generic solution for this - write your own vis and you can do it

  (Don't see how that's possible, as the data will still be in .setCell() calls... how about microformats on a plain-HTML table, with the table appearing for accessibility-impaired? A method to convert HTML or JSON to a data source would be tidier anyway.)

Lunch

A deeper look at Google App Engine, Mano Marks

  Overview of App Engine
  Quick walkthrough
  Best practices

  Standard problems of setting up a webapp
    Startup, scalability, upgrades, maintenance etc.

  GAE easy to start, easy to scale
  5M pageviews / month for typical app
    Payment for additional cap. BY END OF YEAR
  Python only
    More languages soon
    Mano can't tell us which, but he won't tell us why he can't tell us - we don't need to know
  Offline processing
    No cron, but... soon.

  SLA
    None
    Cloudstatus, partner org, monitoring tool
  Lock-in
    (You can't download your code, so get svn warmed up)

  cite: Hackathon slides and other useful info - http://code.google.com/p/google-app-engine-codelab/downloads/list

  Tutorial
    app.yaml
    WSGI application
      methods as per HTTP verbs
    Models on top of BigTable
      schemaless - "what happens if you add a column to a table in a relational database? EVERY ROW in that table gets that new column"

  Q: What about data security?
  A: Google do not trawl through your data. It's your data. We don't touch it.
  Q: There's an SLA?

  Q: Do we put ads on your applications?
  A: No. Your visitors will never know this is a GAE app

  Entities
    Most properties indexed and efficient to query (not including BLOBs and CLOBs/text)
    Keys - limitations (only one ID per entity, cannot change ID or key_name later) but Get() by Key is VERY fast
    No revision storage - you have to do this yourself

  Transactions
    ACID
    No queries in transactions - Get() and Put()
    So assemble your data first with .gql() to inform your transaction, then perform

  Counters
    BigTale doesn't count by design. So must Model.count() scan every entity row
    class Counter(db.Model)
    Sharded counter - in an entity GROUP (see docs)
      Counters count a few entities on reads, and whenever necessary you could the counters

  (I thought Mano was going to break into a rendition of "That's Amore" to the camera just then. I think you had to be there.)

  Cache reads and counters
    memcached
    cacheing for n seconds, where n is OK for your purposes.

  Q: 1MB limit - can we gzip and reassemble?
  A: We don't give you access to files and Python - I think - needs that. But you have a 1MB cap on out-of-the door. And we don't give you the underlying C libraries
  Q: So C won't be the next language on App Engine?
  A: I didn't say that (laughs)

  Q: SLA...
  A: UNOFFICIALLY, I'd like people to say "I want to spend this amount of money". Currently you have a quota but it's divided up so you don't use it all up in one spike.

  Q: URL fetch - buy more time? (limit 4s)
  A: at this point no way round that. Can't comment on future.

  Q: Django 0.96 - 1.0 roadmap?
  A: We haven't released one. You can upload 1.0 yourself. But things like GeoJSON rely on C libraries, so there are issues there.
     People are always going to ask "Are we going to support multiple versions?" (which wasn't really the question - 0.96 was pre-release, 1.0 wasn't. A good reason to just support one version, and that be 1.0. It's not as though there's an SLA in the way.)

  Q: memcache - shouldn't GAE handle that/
  A: we don't want to pre-empt the developer too much, taking control out of their hands. Maybe a 20% proj will handle that if it goes in as a feature request...!

State of AJAX, Dion Almaer

  Dion runs Ajaxian

  1. Desktop-y world
  2. Cloud services
  3. Browsers
  4. libraries and frameworks
  5. Gears and monkeys
 
  Take a step back
    What does AJAX mean now we're where we are

  Took a designer to see the potential
    "The latency will get you, the web's not good enough"
    Needed proving through e.g. auto-suggest

    Maps - eyecandy of draggable maps itself isn't really AJAX
      just different ways of thinking about the static HTML page

  Car ads
    Show the dashboard (UI)
    Not the engine schematics, although they're important to get right

  Jared Leto as a UI overhaul
  Vista as a UI and not much else

  cite: Jef Raskin, The Humane Interface. I want Raskin's head-mounted Borg interface.
    "... if the interaction between one human and one system is not polite and friendly it will poison the user experience..."

  Visual design and interaction design
    Two separate worlds
    But they're both right

  The whole web used to look like MySpace
    Now, Apple Store - no Flash, but it zooms and swoops
    Expectations change: Bridge On The River Kwai vs. Spiderman 3
    Script.aculo.us, Dojo, jQuery follow expectations. You just have to use them nowadays or the absence is noticeable.

  cite: Jakob Nielsen
    1-second reaction time of your app is about the limit for keeping the user's flow
    0.1-1, people notice, but they don't mind too much

  The library dartboard!
    Gradually collapsing down to jQ, Dojo, P+s.a.u, and... GWT

    1. lightweight - Prototype
    2. hate Javascript, love that hot lava Java? - GWT
    3. functional, DOM-like - jQuery
    4. rich soup-to-nuts - Dojo

    I don't like the sound of soup to nuts. I've been in that sort of restaurant.

    P, jQ and Dojo all have thin core + plugin community + visual effect plugins, so "pick one"

  Examples of other libraries
    Mobile Me (SproutCore)
    280 Slides (Objective-j)

  Dojo realtime charting - GFX package, Dojo grid, Processing.js (Canvas)

  The 0.1second limit
    Event queue, browser, processing - browser's switching system (JS? style?) a bottleneck
    Firefox logo used for the browser, I see

    No such thing as threads in JS.
      cite:Brendan Eich, "Threads suck."
      In comes Google Gears, neeow
      WorkerPool process outside the browser

  Jef Raskin again. "The typed 'Y' becomes a learned gesture" - warning dialogues just get clicked on, unheeded
    So undo instead
    But how do you do that on the web?

    Form history
      Slider bar changes between revisions - don't ever actually have to give someone the undo

  cite: Jonathan Schwartz. Every RIA has a RIBackend

  Talking to desktop
    Notification APIs

  1. Fluid - Mac only, but integrates tightly using Greasemonkey-like scripts
  2. Gears - more about giving the browser access to existing APIs
  3. Mozilla Prism - cross-platform
  4. Adobe AIR - using Flash / CSS skills to build desktop apps

  Back to the dartboard...
    Wii remote, directing a dart, in an Ajax application.
    You've won a rubber bully!

  Wii -> bluetooth -> WinXX -> wiiuse -> wiiusej -> Java plugin WiiTracker -> browser

  Java PLUGINS?
    In Chrome,
      Works out of process (doesn't kill browser, totally independent)
      Deployment with JNLP - download components only once
      Micro-kernel

  Modern Web Development
    cite: Alan Foreman, poisonedminds.com

  Mozilla's monkeys
    Getting other languages into the browser with VMs

  Plugins only get you so far
    HTML5
    Gears is trying to follow this (and presumably to some extent lead it)

   70% of sites have a div called "footer" - so why not <footer> ?

  Questions
    Q. Compatibility & SLAs - adopting other people's projects?
    A. No plans - still very immature environment.

Keynote

  Browser as client
    Ubiquitous, zero-install, standards
    but capabilities mediocre
    Google want to improve browser capabilities
  Cloud access
    Massive capability beyond most devs' reach
  Connectivity

  Current web apps are pushing the browser's capability
    Browsers haven't changed much, but the web has
    Invisible iframe!
  So Chrome

  *** CHROME COMMERCIAL BREAK *** - good but covered by Scott McCloud already

  APIs
    Programmatic accessibility of authentication and content
    *Significant* growth in traffic

  Google App Engine
    Other languages in pipeline

    Solves non-dev problems for apps;
      Deployment
      Pre-launch investment
      Hardware maintenance
      Scalability

    Apps
      Wordle
      Buddypoke (OpenSocial)
      iPhone app - code.google.com/p/metasyntactic
      Pixverse - Pix Wall and Pix Chat

  Android
    Open Handset Alliance (!)
    OS mobile platform + WebKit

    Mike Jennings
      *** Android demo ***
      Tape over branding
      Slashdot is so 2002, unless you're me
      Touch screen
      The blue dot app - accelerometer
      OpenGL, Java

  Google Web Toolkit
    Writing BIG AJAX apps
      Live demo - a bit .NET
      Hosting browser running Java bytecode, not Javascript representation.
      So can be debugged as Java code