Legends of the Sun Pig

The article I wrote on Sunday about Alex being cut off from Google generated quite a bit of attention and feedback. Most of it was positive, much of it was well-meaning, and some of it was dark and ugly. Unfortunately, those proportions were not reflected in the comments left here on this blog.

I shut down comments yesterday afternoon because they were turning toxic, and I don’t want to deal with that kind of negativity. I only deleted a few comments, because I didn’t want to distort the picture that appeared, or make it seem like everyone was on my side.

To everyone who expressed their sympathy, support, and understanding, thank you. We’ve had some wonderfully kind and generous messages over the last couple of days.

To everyone who thinks I’m a bad parent, a hypocrite, or just a whiner: whatever. You probably complain about parents bringing their kids on airplanes, too. I don’t have anything to say to you.

But the numerous responses from well-meaning people offering suggestions made me think a lot. I wrote the article just an hour or so after the incident, and I was feeling angry and upset. Why was I feeling that way?

First of all, it’s not not about data loss. That may seem the most obvious thing to be upset about, but we’ve got that covered. We have Alex’s email set up so that both Abi and I receive copies of everything sent to him. We can restore much of his correspondence from there. Additionally, as many people pointed out, we can just lie about his age and get his account unlocked within minutes.

I think this is why many of the responses were along the lines of, “What’s your problem? Just lie like everyone else, and use this as a lesson to teach him not to trust Google/corporations/the cloud/anyone.”

As a practical matter, I fully expect to do exactly that at some point in the next day or two. Alex will have his email back, and everything will go back to normal. But as a matter of principle, I get sick of lying every time I have to tick that “I have read and understood…” checkbox, when the language in most ToS documents — and the fact that they are generally hidden on a secondary page — is clearly designed to make sure that you don’t read or understand them. Given that this episode came about because of a ToS violation, I just reached a breaking point here. If Google is going to deny services to children under 13, they need to put a date of birth field on the sign-up forms for all of their services, even Gmail. Simple as that. (Update: nothing is ever “simple as that”. See comment.)

Secondly, it’s not about not about being cut off from email. There are plenty of other email providers out there who will allow us to provide parental consent for a child account. Finding a provider outside the US probably isn’t that hard, either. I know how to set up my own email server, but I prefer to let other people handle that for me.

We deliberately chose Gmail as Alex’s email client because it has a simple interface, and its spam filtering is the best in the business. I love Gmail, but it would be a matter of minutes to get him up and running with an alternative mail solution. So again, “What’s your problem? Just switch and move on.”

Here is the heart of the matter for me: it’s the moment of horror when you realize that something you love is gone. The sickening crash when your grandmother’s precious ornament slips out of your hands and hits the floor. The hollow dread in your stomach right after you accidentally delete the production database. The moment you come home after a long road trip, and discover that you left your favourite cuddly toy behind at a rest stop 400 miles away.

That’s how Alex felt when he realized he was locked out of his email.

No matter how quickly we reassured him that we’d find a way to get it back, that moment of shock and pain and despair still creased his face. No matter how much we hugged him and wiped away his tears, he still hurt, in that special way when you blame yourself for what happened. Alex followed the instructions in the invitation to sign up for Google+. He entered his real date of birth. And because of that, he wasn’t just denied access to the new service, he lost access to everything he had with them before.

Yes, I was at fault for confirming that I had read and understood the Terms of Service when I created Alex’s Gmail account on his behalf.

Yes, I was at fault for not supervising every moment of Alex’s online life. He surprised Abi and me both when he said he had added Abi to a Circle in Google+. We don’t use net nanny software; the computer he uses is in plain view in the living room. We may receive copies of his emails, but we don’t obsessively scrutinise every one. We talk with him a lot about online behaviour, and we try to steer him away from problem areas. We also feel that he has shown enough responsibility to deserve the independence we grant him. If that changes, we will re-evaluate. We like raising Free Range Kids; that’s one of the reasons we live in the Netherlands rather than Britain or the USA.

Yes, Google acted perfectly legally, and in accordance with their Terms of Service. As soon as they acquired Alex’s date of birth, and tied it to his overall Google identity, they were obliged to act on that knowledge. Not doing so would mean breaking the law; I understand that.

What I blame Google for, though, and what is entirely under their own control, is poor implementation and lack of empathy. Rolling out Google+ is a massive undertaking, on a scale I have never dealt with. I don’t think that “weeding out underage Gmail users” was an item on the project plan; I’m sure it’s an unintended consequence. But the failure mode is harsh, and offers no recourse for parents who would grant legal consent (within the USA-specific scope of COPPA) for their child to use the service, to actually do so. Legal and nice are perpendicular scales. You can obey the law and still be a dick. (Wil Wheaton says: Don’t be a dick.)

Alex is not going to be scarred for life, and I’m sure he’s going to learn useful lessons here. But he trusted Google, and they failed him hard. In his words, “I might even start using Yahoo for search.”

Alex is not amused

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