Legends of the Sun Pig

Alex is 10 years old. He has had a Gmail account since September 2009 — almost two years. He uses email to keep in touch with his grandparents, who live in California and Scotland. He is signed up to get newsletters and updates from his favourite online hangouts, like Roblox and Hyves. He has just started using Google Chat to chat with me over IM, even though I’m usually just sitting at my desk on the other side of the room.

Yesterday, he noticed that Google+ was enabled for his account. Yay! So he made himself a Google Profile, and added me and Abi to his family circle. Even Alex had heard about Google+, and he was excited to be using it.

Today, he tried to use Gmail, but found that his account was locked. A big scary message says that his account has been shut down because Google has discovered a Terms Of Service age violation. Not only is the account inaccessible, they also say that they will delete it in 29 days, unless he provides them with evidence that he is over 13 years old. All because he entered his date of birth when he created his Google Profile.

Alex was in tears. He is enormously upset about this. Google is basically just going to delete his last two years of email messages (they don’t offer any way to log in and export his messages), and plans to cut him off from his family until he turns 13.

This is a kid who lives on the computer. He types 50 words a minute, builds immense structures in Minecraft, programs in python, and has better Powerpoint skills than his teachers at school.

He has learned to live with the disappointment of not being able to have his own YouTube account, because YouTube asks for your date of birth on the sign-up page. But the Gmail sign-up page doesn’t ask you for your age. It does, of course, ask if you accept the Terms of Service. Oh right. The Terms of Service. Which apply to all Google services:

2.3 You may not use the Services and may not accept the Terms if (a) you are not of legal age to form a binding contract with Google, or (b) you are a person barred from receiving the Services under the laws of the United States or other countries including the country in which you are resident or from which you use the Services.

Just because no-one reads the Terms of Service, doesn’t mean that they don’t apply. Ignorance of the law is not an excuse for breaking the law. But seriously, this USA-centric age 13 bullshit is a blight on the internet. Alex has been using the web since before he could fucking read. To him, Google practically is the web. But according to these Terms of Service, he’s not even allowed to use Google Search.

You made my son cry, Google. I’m not inclined to forgive that.

Update, 4 July 2011 20:50: Comments closed because of Olympic-level asshattery. Well played, internet. Well played.

Update, 4 July 2011 23:55 I’ve posted a short update over on Making Light. Don’t even think about trolling over there.

Update, 5 July 2011 17:00 I’ve removed the link to the update mentioned above, because all the trolls decided to poison the comments over on that site, too. [Restored now that the flames have died down a bit.] If you want to express support or sympathy, thank you. Go give someone you love a nice hug. If you want to express your disapproval of me, please do so on your own blog.

Update, 5 July 2011 20:50 Or alternatively contact me at m.feedback@sunpig.com. Don’t post responses in comment threads elsewhere on this blog; I’m just deleting them immediately.

Update, 6 July 2011 01:50 I have written a follow-up article which acts as my global response to the comments that the original article generated.

I’m running an experiment on myself:

1. Avoid artificial sweeteners
2. Avoid glucose-fructose syrup
3. Minimize refined sugar

I’m trying this because I love sweet foods and drinks too much. I’m not a coffee person, but I am a caffeine person, and for many years most of my caffeine consumption has been in the form of diet cola — usually between 1 and 2 litres per day, but often more. When I drink tea, I prefer it strong (“chewy”), milky, and very sweet. I love chocolate and sweets, and eat lots of them.

I’m not doing it because I think that artificial sweeteners are going to give me brain cancer, or that high-fructose corn syrup is going to give me heart disease. I don’t have enough medical and dietary knowledge to evaluate the evidence for myself, and the media sure as hell aren’t going to do it for me. Like climate change and nuclear power, this is a researchable matter, but there are too many entrenched interests willing to fund opposing studies, and lobby governments to torpedo any positive actions they might take.

But at some point I have to look at my own behaviour — regardless of what everyone else does and thinks — and ask myself if it makes sense to me. I hate saying “all this sweetness can’t possibly be good for me”, because it feels unscientific and irrational. But that’s kind of what it comes down to.

Since reading Michael Pollan’s book The Omnivore’s Dilemma last year I’ve been thinking more about the things I eat. I’ve got to the point now that my consumption of sweet things feels unbalanced. I worry about sweetness leading to more sweetness: the amount of diet cola I drink may not add anything to my calorie balance for the day (helping me keep my trim, youthful figure), but it may be habituating me to that amount of sweetness in my diet, and making it more likely that I will (for example) guzzle down an entire family pack of peanut M&Ms whenever I visit the cinema.

So: less sweetness. I’ve been doing it for a couple of weeks now. I find the lack of caffeine…disturbing, so I’ve taken to popping raw caffeine pills to supplement my increased intake of sparkling mineral water. I’m finding that I have fewer chocolate cravings, and that my overall appetite (“the prowling hunger”) seems to be less, but that might be down to the fact that it’s summertime and warm. I’m getting used to drinking plain tap water, and ignoring the habit to drink something flavourful to quench my thirst — this definitely feels like a good thing.

Longer term? We’ll see. It’s interesting, though.

If you deal with CSS at all, I urge you to watch the video of Nicole Sullivan’s presentation at Webstock this year (and follow along with the slides on Slideshare). It’s only half an hour long, and it is an eye-opening summary of the problem of massive, sprawling CSS.

One of the core principles of progressive enhancement as a technique for web development is the separation of content (HTML), presentation (CSS), and behaviour (JavaScript). The CSS Zen Garden is the canonical shining example of how CSS can be used to completely transform the appearance of an HTML document, without having to make any changes to the underlying HTML. The problem is, this is an unrealistic example.

In the real world, we have to deal with documents and designs that change from month to month. If you are laying down a one-off site, then your CSS can be as weird and sprawling as you like, but many of us don’t have that luxury. Our CSS has to be comprehensible to our colleagues, our successors, and ourselves in 12 months’ time. It has to be structured and meaningful, and you shouldn’t have to understand all of it, or use a debugger (web inspector/Firebug) just to make a simple change.

The principle of separation of content and presentation says nothing about how to keep your CSS organized in a highly fluid environment. Just because the ground rules of CSS are easy to understand, doesn’t mean that it is easy to work with in the large. When it comes to modularity and re-use, CSS as a language doesn’t even have variables, for goodness’ sake.

My own take on this, a few years ago, was to advocate a highly modular way of writing CSS, where each “content block” (a header, a sidebar list, a blog entry) uses a completely isolated set of CSS rules. By isolating each content block, you don’t have to go hunting all over the place to find the style rules that apply to the block you’re working with, and you know that any changes you make won’t impact the rest of the site.

But as Nicole points out in her presentation, this is exactly what leads to massive CSS code bloat, and sites that declare font-size:12px 700 times. In general, more code means more bugs. On the web, more CSS code means increased download times. And although JavaScript is more often the performance killer for a typical web page, complex CSS can have a significant impact on page render times, and poorly considered CSS changes triggered by JavaScript can trigger expensive reflows.

It has taken me a while to understand the lessons Nicole has been teaching, but I now generally prefer the object-oriented style of writing CSS, although I don’t always use the full OOCSS framework itself. (I’m also not mad about the “object-oriented” name, because I think it gives the wrong impression. It is defintely about objects, but “object-oriented” has too much other baggage. I often find it easier to explain the concept as “inside-out” thinking instead of “outside-in”.)

One of the hardest hurdles to leap in coming to like OOCSS was the somewhat heretical notion of adding “non-semantic” container elements and apparently “presentational” classnames to my HTML. What finally reversed my discomfort was the realization that “semantic HTML” is not just one thing. There are, in fact, many different layers of semantics that go into HTML, and in fact belong in there:

• Structural semantics are represented by the core HTML elements that define the document outline: headings, paragraphs, lists, tables. HTML5 adds articles, sections, figures, and other sexy stuff. To be honest, these new structural semantics have always been my favourite part of HTML5, because they make it more flexible to represent old-fashioned documents, and make it more likely that what we humans write now will be readable and comprehensible in the really long term.
• Ontological semantics are layers of domain-specific meaning that add information about what a piece of structural markup is in the world beyond the document outline. A <section> might represent someone’s contact information, an event, or a menu of options. Microformats and ARIA roles are just a couple of widely used examples that happen to be standardized. No doubt you have come across many other examples of site-specific semantic classes, like <section class="account"> or <ul class="orders">.
• Visual semantics represent the intent but not the implementation of the visual hierarchy of a document. This is the difference between <div class="rounded"> and <div style="border-radius:5px">. Or, to take a concrete example from the OOCSS framework, why it’s okay to do something like <h2 class="h3">. What you are saying with that piece of markup is that structurally, this header is at the second level of the document outline, but visually it should be less important — perhaps because the section in which it appears is located in a sidebar rather than in the main body.

Just because you use visual semantics does not mean you have to abandon ontological semantics. The two complement each other very nicely. But favouring visual semantics for styling (ideally derived from a style guide) means you can minimize your CSS by writing one-off rules like this:

h3, .h3 {
    font-size: 146.5%;
    font-weight: normal;
    font-style: normal;
    color: #DF2B72;
}

instead of repeating yourself in location-dependent styles like this

#order h3 {
    font-size: 146.5%;
    color: #DF2B72;
}
#sidebar .upsell h2 {
    font-size: 146.5%;
    color: #DF2B72;
}
...

The really hard part about doing it this way is finding the right balance, the right level of granularity in how your objects are made up of other, smaller objects. This is not an exact science, and there are no canonically right answers. What feels like the right level of granularity to me, might feel freakishly over-specific to you. What we can probably agree on, though, is that if you end up specifying a classname for every property + value combination on each element, you’ve gone too far:

<p class="color-red size-xl margin-20 padding-10
background-white weight-bold bg-img-monkey bg-pos-topleft">

Have a look at Nicole’s two articles about granularity and the media object for an illustrated example of how to think about HTML+CSS object composition.

Finally, I’ll bring out one of my favourite quotes: “There are only two hard things in Computer Science: cache invalidation and naming things.” Object composition is all about naming things; this makes it hard. But not impossible, and certainly very worthwhile once you get the hang of it.

jQuery Mobile has just hit its beta 1 milestone, and there is much rejoicing. But having worked with the framework for a little while now, I’m having serious doubts about its suitability for mobile web applications at all. This isn’t a “jQuery Mobile considered harmful” piece; I just want to explain my own concerns.

The way I see it, the jQuery Mobile framework consists of four sub-frameworks:

1. jQuery. jQuery Mobile is not a standalone library; it requires the jQuery core library.
2. A CSS framework for styling elements to look like iOS-ish native controls
3. A widget framework that automatically builds the (complex) HTML required by the CSS framework from (simple) declarative HTML.
4. A client-side page navigation framework

Combining the CSS and widget frameworks allows you to write simple declarative code like this:

<a href="somepage.html" data-role="button">Button</a>

which gets turned into this:

<a href="somepage.html" data-role="button" data-theme="c"
         class="ui-btn ui-btn-corner-all ui-shadow ui-btn-down-c ui-btn-up-c">
  <span class="ui-btn-inner ui-btn-corner-all">
    <span class="ui-btn-text">Button</span>
  </span>
</a>

and is rendered like this:

The widget framework also allows you to create page and dialog widgets, that act as isolated screens within your application: only one is visible at a time.

<div data-role="page" id="index"> 
  <div data-role="header">Home</div> 
  <div data-role="content">
    <a href="#monkey" data-role="button">Monkey</a>
  </div> 
</div>
<div data-role="dialog" id="monkey"> 
  <div data-role="header">Your monkey</div> 
  <div data-role="content">
    <img src="http://example.com/monkey.png" />
  </div> 
</div>

These page widgets can be declared inline in your code (as shown above), built dynamically with JavaScript, or loaded from a remote server or from the local file system with Ajax. The page navigation framework takes care of hooking up the pages and dialogs, so that when you click on the “Monkey” button, the home page is hidden, and the monkey dialog is displayed. Very importantly, the framework takes care of browser history while navigating from page to page, so that the native back button works correctly. (Still buggy in beta 1, but I’m sure they’ll fix it.) It can also provide pretty animations for transitioning between pages.

Problem 1: “native” UI

If you’re happy sticking with the visual style of the framework, that’s fine. The jQM team has put a lot of work into making the UI components look very slick (and iOS-ish), and compatible across a wide range of browsers. But should a web application’s greatest aspiration be to look as much like a native app as possible? No. Remember building web apps to look like native Windows XP applications? Those were the bad old days.

The basic theme includes five colour swatches that you can apply and extend. But adapting the existing controls beyond just their colours and icons is more difficult precisely because they are generated from declarative markup, and the widgets only grant you limited options for tweaking their output. Of course, you are always free to bypass the widget system altogether and write your own markup using and CSS, and mix in classes from the CSS framework when appropriate.

Problem 2: Ajax navigation

Despite how easy Mark Pilgim makes it look, implementing a framework that gives you all the benefits of Ajax partial page loading, while at the same time maintaining fully linkable URLs is non-trivial. jQuery Mobile hasn’t tackled this yet. As you navigate between pages, you end up with hash-based, JavaScript-dependent navigation, which is bad.

So why do this in the first place? Why not just put each page on a separate URL, in the traditional web style, and ditch the client-side navigation altogether? Would jQM not work just as well as a CSS + widgets framework?

I don’t think so, because of speed — or rather, the lack of it.

Problem 3: size and speed

jQuery Mobile is not a stand-alone library; it is built on top of jQuery. Even though jQuery’s headline size may appear small (31.2KB minified and gzipped), and jQM doesn’t appear to add much on top of that (20.3KB minified and gzipped), this is not an insignificant amount of code for a mobile browser. Even if a browser already has these JS files available in its local cache, it still has to parse them on each new page load. And the painful reality is that mobile browsers are still really slow compared to their desktop cousins.

I’ve made a very simple test page to show how long it takes to just load (from cache) and parse jQuery (v1.6.1). Here are the very unscientific results from the devices I have to hand:

Device + browser	Time to load (from cache) & parse
iPhone 3G + Mobile safari (iOS 4.2.1)	0.95s
Samsung Galaxy Ace (Android 2.2.1) + Android Browser	0.75s
iPad + Mobile safari (iOS 4.3.3)	0.29s
Samsung Galaxy Ace (Android 2.2.1) + Opera Mobile 11	0.29s
LG Optimus 7 (WP7, 7.0.7392) + IE	0.27s (very pleasant surprise!)

On other devices, performance can be even worse. 8 seconds on an older Blackberry? Try the page on your own phone and let me know how it shapes up. By comparison, on my laptop it takes about 0.02s to load & parse in Chrome 12, and about 0.05s in Firefox 5. So at a glance, it looks to me like mobile browsers are at least 5 times slower than desktop browsers.

When you’re talking about a consciously perceptible amount of time spent parsing a library, you’ve got a problem. Remember that this is just jQuery on its own, before adding in the jQuery Mobile framework and your own code, and before the browser has to do any actual rendering work to display your content.

Conclusions

The fact that jQuery Mobile sits on top of jQuery makes it a comfortable and attractive solution. If you already know jQuery, you’ll pick it up easily, and you’ll have all the power of jQuery available to you right off the bat. It’s well tested, and highly compatible. It’s under constant development, bugs get fixed all the time, and it has good community support. It’s better code than most of us are likely to write ourselves.

But the challenges of the mobile web are not the same as those of the desktop web. I have massive respect for everyone who works on them, but jQuery and jQuery Mobile do not address these problems adequately — yet. Performance is much more important, and much harder to come by because of slow devices and high network latency. Size matters a lot. When even big desktop web sites typically only exercise a small part of the code in jQuery core, you have to wonder if a mobile site is going to need all of it.

In summary:

• jQuery, and by extension also jQuery Mobile, is too big a library for a mobile site that uses standard URL-based navigation.
• Until the jQuery Mobile client-side navigation framework supports the HTML5 history API (pushState/popState), it will deliver problematic URLs. It’s up to you to decide whether this is a deal-breaker for your project.
• If you’re building a PhoneGap application, jQuery Mobile is perfect. As you load the app, you load the framework once, and then navigate between a set of predefined pages using Ajax navigation and smooth transitions. You don’t have to worry about hash-based URLs, because they are not exposed to the user, and you’re not expected to link to them. The native look of the controls matches the user’s expectations for a native app. Awesome.
• If you’re building a one-off mobile web application that you don’t expect to be around forever. jQuery Mobile might not not be the perfect solution for mobile web sites, but depending on the timescales and requirements of your project, it may very well be good enough.
• If you’re building a full-scale mobile web site or application that is going to be core to your business, you can use jQuery Mobile to get you to v1.0 quickly, but consider it a set of training wheels that you should shed after this point. Its limitations will constrain the changes and optimizations you can make in the future. The UI is not designed with your site in mind, and the underlying framework is bigger than you will need. (A big framework may lead you to be less critical of the size of your own code.)

After a string of pretty hard-core tech blogging, I feel the need to cleanse my palate with something a bit more lightweight. I don’t want to you get the impression that I’m some kind of geek or something. So in the long lead-up to the traditionally long-delayed Radio Sunpig (2010), here are three albums that I found quite remarkable last year, in the sense that I’m still listening to them over and over again.

Dananananaykroyd – Hey Everyone

Right from the opening licks to the closing stretched out wails of feedback, this whole album is filled with raucous energy. It’s not big on catchy radio-friendly melodies, but the frenetic pounding drums (two drummers!), shifting rhythms, screamed lyrics and gnashing guitars drive it forward with breathless speed. And yet at the same time the songs are not one-trick ponies; they are remarkably complex pieces of work that invite. I’d call it punk, but without the anger; it’s so hard to listen to them without a bobbing head and a manic grin.

And they’re Scottish, adding weight to my thesis that the best music comes from Scotland and Canada.

• Some Dresses
• Black Wax

Hue And Cry – Open Soul

I’m a bit disappointed that Last.fm doesn’t understand Hue and Cry. On listening to Open Soul, Last.fm reckons that I ought to load some Curiosity Killed The Cat, and maybe a bit of Living in a Box into the mix. Weeellll, kinda no, guys. Hue and Cry actually made it out of the 1980s.

With Open Soul, they’re firmly in Michael Bublé and Jamie Cullum territory. Relaxed, jazzy, blue-eyed soul with gorgeous arrangements and a tight, tight horns section. Pat Kane’s voice has never sounded better, and their cover of Beyoncé’s “Crazy In Love” — recalling the pseudo-rapped vocals on “Labour of Love” — is nothing but peppy fun. They’re absolutely at the top of their game here.

I also love the fact that Pat Kane is now also well known as a writer, speaker, and consultant on play, and is a smart and outspoken voice for Scottish independence. You should follow him on Twitter as @theplayethic.

Rack up another point for Scotland in the worldwide music battle.

• The Last Stop
• Headin’ for a Fall
• Fireball

Mos Def – The Ecstatic

One of the first games I downloaded when I got my iPad last year was Tap Tap Radiation, which is where I first encountered the song “Quiet Dog” which is a pure hip-hop masterpiece: sparse beats and precision rapping give it bounce and self-confident swagger. The rest of the album is wonderfully fresh and varied, mixing middle-eastern sounds with more traditional soul and funk, and lyrically jumping between brash (“Supermagic”) and achingly tender (“Roses”) with ease.

Mos Def is, of course, Scottish. (Brooklyn, West Lothian.)

• Casa Bey
• History ft. Talib Kweli

The ultimate reason behind my last two articles (“URL shortening is bonkers” and “On URLs, keywords, and memorability”) is a very simple use case: Alex (age 10) was playing Roblox on the kids’ computer, a game where you can build virtual environments and items to populate them with. He had made an item (I think it was a T-shirt), and he wanted to show it to me on my computer. What was the easiest way for him to do that?

Because Alex has an email account, but doesn’t use IM yet, the two options were:

• I log in to Roblox, navigate to Alex’s profile, and look up the item.
• Alex copies the URL for the item from his browser, and pastes it into an email to me. I open up the email, and click on the link.

Neither of these options is unreasonable, but they both feel unnecessarily cumbersome. Using the site navigation involves me clicking through several screens, and unless Alex is standing next to me looking at my screen, I’m not sure if I’ve got exactly the right item. But using email to pass the link around doesn’t take advantage of the fact that Alex is sitting five meters away from me, and we can just talk. For a younger child without an email account, even the second option would be out of the picture.

What I really wanted was for Alex to just say, “go to roblox.com, and type this simple code.” (With a code that doesn’t look like a cat has just walked over the keyboard.)

Donkeybridges.com is a demonstration of this idea. The site uses Yahoo!’s GeoPlanet API to show information about places (towns, states, countries) worldwide. Each place has its own page, which is identified by a non-obvious ID value in the URL, for example http://donkeybridges.com/place.php?id=2161838 (Guangzhou in China).

Each place also has a “link phrase” associated with it. (I originally called them “resource mnemonics”, but that’s not very catchy.) The link phrase is a combination of two adjective + noun pairs, like “a sticky pen and a funny feather.”

To view a place page, you can go directly to the URL (hard to remember), or you can go to the home page (easy to remember) and enter the link phrase (easy to remember). The idea is that two easy steps are better than one hard one. Not that pasting a URL into your address bar is hard, but ask yourself what you are more likely to remember in ten minutes: “2161838” or “a sticky pen and a funny feather”?

The link phrases are generated from one list with 100 adjectives and one with 100 nouns: A1 + N1 + A2 + N2. This gives a possible 100 x 100 x 100 x 100 = 100 million possible combinations. I picked the adjectives and nouns for the lists because they are simple and vivid, and produce clear mental pictures, which makes the combinations easier to remember.

100 million combinations isn’t enough for a generic URL shortener that may be dealing with billions of links, but it is enough to fit all the WOEIDs (“Where On Earth IDs“) that Yahoo! currently has assigned to places around the world. There is a simple algorithm to turn each WOEID into its matching phrase, and vice versa.

Because places that are adjacent in the real world often have WOEIDs that are very close together, I injected a little trickiness into the algorithm to make sure that consecutive WOEIDs produce very dissimilar phrases. WOEIDs 33556 (Rosevanion in Cornwall) and 33557 (Rosevean, also in Cornwall) map to “a jumping heart and a brown king” and “a fast dress and a wide knife”, respectively. If you’re interested, the source code is on Github.

What are the civilian applications?

You will have observed that the link phrases used on donkeybridges.com have nothing to do with the actual resources (places) they map to. This is a weakness when the resource is strongly physical, like a place, or a book, or an MP3. It can be fun to discover that a place is associated with a funny phrase, but there is no inherent reason why “a broken lion and a laughing cloud” should be more associated with Thurso in Scotland than with Beloha in Madagascar. The phrase is less memorable than it would be if there were a connection.

However, when it comes to identifying abstract resources, such as hotel bookings, appointments on a calendar, or items of virtual clothing, using one nonsensical but otherwise vivid and memorable phrase is as good as any other.

Sending someone a URL via email or IM will remain the quickest and easiest way to point someone at a digital resource most of the time. But link phrases give you a simple (and potentially amusing) analogue alternative when digital communication just doesn’t work out.

Please play around with donkeybridges.com, and let me know what you think.