Ada Lovelace Day 2026

Posted on by
1

Today is Ada Lovelace Day, an international day to celebrate inspirational women in technology. Part of the day’s aim is to encourage people to blog about the women who have inspired them. This is my contribution.


It’s actually a story in two parts. As a child, growing up learning to program on my ZX Spectrum, I used to watch Tomorrow’s World religiously on the BBC. Tomorrow’s World found the perfect balance between inspirational and practical technology, and was a must-watch for any kid growing up dreaming of a career in tech. A big part of its success came from its inspirational presenters – none more so than Maggie Philbin.

As a TV presenter, Maggie always managed to communicate her genuine interest in the technology around her, and showed a constant desire to communicate how incredible technology can be. She had that rare skill of making the complex appear both magical and understandable.

Fast-forward a couple of decades, and I found myself talking at a publishing conference in London. Maggie was chairing the event, and did a great job of keeping the audience engaged, asking difficult questions on their behalf.

During the lunch break, I plucked up the courage to speak to Maggie, and showed her an early build of the Lovelace & Babbage history of computing app we built for Ada Lovelace Day. She was interested and curious, and while playing with the app, she mentioned an event she was organising a few months later. That event was TeenTech Hull, and before I knew it, I’d agreed to come along to the event, and run an app design workshop for 300 kids. (I soon came to realise that one of Maggie’s many skills is persuading people to get involved in fun and challenging projects.)

Continue reading →

Microsoft Surface – a device with good form

Posted on by
Reply
Despite being an ardent iPad user, I’m excited by the announcement of Microsoft’s new Surface device. To explain why, I’d like to put aside questions of price, delivery date, OEM annoyance and app support, and instead focus on three key aspects of the device’s form.

It’s a tablet; it’s a laptop

The combination of Kickstand and Touch Cover means that the Surface can instantly take the form of either a tablet or a laptop. The Touch Cover is essentially the same form factor as an iPad Smart Cover, with the huge added benefit of a built-in keyboard. Thanks to the neat Kickstand integration, it can take the form of a laptop without requiring any additional hardware. Compare this to the iPad, which requires a 3rd-party stand and keyboard to achieve the same effect, and the Surface has a very neat advantage over Apple’s iconic tablet.

Hand-held portrait mode

The Surface’s Kickstand and keyboard case are intended for landscape use only. These are clearly aimed at the laptop use-case, or perhaps for watching a film. If you want to use the device in portrait, you’ll need to hold it in your hand. I don’t see this as a bad thing, however – the most common portrait use-case, reading a book or other long-form content, is more likely to be hand-held anyway. This feels a perfectly acceptable compromise to enable the landscape laptop use-case.

Apps that work

Posted on by
9

What do I mean by “apps that work”?  Well, the most successful apps – those that really work for users, those that are used time and time again – are apps that make the best of what a mobile device can do.

To make apps that really work, we need to answer three questions:

  • Do we need an app?
  • Will an app achieve what we want?
  • If so, how can we do it well?

Do we need an app?

Fourteen years ago, I ran the production team for a fledgling web agency. Back then, clients would approach us saying “We need a web site”. What they meant was, “everyone else is getting a web site, we want one too”.  Fast forward fourteen years, and the same thing is happening – but this time, it’s “We need an app”.   As with web sites, there’s a question to answer first:

Do we need an app?

Certain types of content and functionality lend themselves to apps, certain types don’t. For this reason, we have three criteria that we apply to any app idea, to help decide if an app is the appropriate way to go.

1) Dead Time

Dead time is the time you spend commuting on the train, or travelling on the tube, or waiting for a friend, or faffing around when there’s nothing on TV. These are all chunks of time where your options for keeping yourself entertained are restricted by circumstance.

Because your iPhone or iPad is the device you always have with you, it’s ideal for filling dead time. Good examples of dead time fillers include:

  • Angry Birds, with its short, self-contained, multi-try levels
  • Comics, which means there’s always a comic there when you have time to read it
  • The Guardian, with its offline news download feature
  • Instapaper, which saves interesting articles for when you have ten minutes to read them

We applied the Dead Time criteria when Faber & Faber approached us to create an iPhone and iPad app for QI. Faber and QI have published several traditional books, which are perfect content for dipping in and out of, and are great for filling dead time. However, they’re quite heavy. They’re also large.

Continue reading →

Why ++[[]][+[]]+[+[]] evaluates to “10″ in JavaScript

Posted on by
3

This comes from a popular question on Stack Overflow. Given the popularity of the question, the fact that it is now closed and the fact that the highest-ranked answer there is a little imprecise, I’ve decided to write up an explanation here.

I should warn you now that I’m going to make reference to the ECMAScript specification to explain this. It shouldn’t get too painful though. I’m using version 3 rather than the more recent version 5 of the spec for two reasons: first, it’s still the baseline for what is supported in mainstream browsers, and second, there’s a handy HTML version on the web that lets me link to the relevant sections. So, with that out of the way, onto the code.

The expression ++[[]][+[]]+[+[]] may initially look rather imposing and obscure, but is actually relatively easy break down into separate expressions. Below I’ve simply added parentheses for clarity; I can assure you they change nothing, but if you want to verify that then feel free to read up about the grouping operator. So, the expression can be more clearly written as

(++[[]][+[]]) + ([+[]])

Breaking this down,we can simplify by observing that +[] evaluates to 0. To satisfy yourself why this is true, check out the unary + operator and follow the slightly tortuous trail which ends up with ToPrimitive converting the empty array into an empty string, which is then finally converted to 0 by ToNumber. We can now substitute 0 for each instance of +[]:

(++[[]][0]) + [0]

Empty XHTML tags and Internet Explorer DOM traversal

Posted on by
Reply

Here’s the problem: HTML and XHTML pages containing empty elements with no end tag such as <span /> break JavaScript DOM traversal methods in Internet Explorer 6, 7 and 8, resulting in nodes after such an element showing up in more than one node’s childNodes collection.

Consider the following XHTML document:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
  PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>Test</title>
    <script type="text/javascript">
        function show() {
            var span = document.getElementById("span");
            alert(span.innerHTML);
        }
    </script>
</head>
<body onload="show();">
<p id="p1">Paragraph containing some text followed by an empty span<span id="span"/></p>
<p id="p2">Second paragraph just containing text</p>
</body>
</html>

The idea is that when the page loads, the JavaScript will get a reference to the empty span and display its HTML contents. That will be an empty string, right? Not in IE it won’t. In IE, you get the following:

</P>
<P id=p2>Second paragraph just containing text</P>

Now, while <span /> may be valid in documents with an XHTML Strict doctype, this makes not a jot of difference to IE, which always parses XHTML as HTML, regardless of doctype. What seems to happen is that IE finds the offending span tag (henceforth known as ‘Bad Span’) and ignores the closing slash. Whether it does this because it knows that such a tag is invalid in HTML or because it always ignores closing slashes I’m not sure. Whatever, the result is that IE scans for a corresponding </span> and since none is forthcoming, skips over the </p> (which it presumably also considers invalid without a matching <p> inside the span) and carries on to the end of the document, adding subsequent nodes to the <span />‘s childNodes collection as it goes.

This is not good news. Consider the second <p> element. IE somewhat contrarily knows enough about the proper structure of the document to place it in the childNodes collection of the body element, but as shown above, it also shows up in the Bad Span’s childNodes, meaning a node can effectively have multiple parents. The DOM is no longer a hierarchy but a map. You may be curious to know which of its parents the second paragraph considers its real parent. The answer (from its parentNode property) is Bad Span.

Now, an unsuspecting piece of JavaScript could easily get into problems. Imagine you had a script that acted on every span in the page. Let’s say for the sake of an example you wanted to set every span’s contents to just be the text “[SPAN]“. You might do something like the following:

Continue reading →

Ignored keypresses when typing on iPad

Posted on by
Reply

The iPad has a reputation for being difficult to type on. It’s generally accepted that the iPad is okay for short emails and notes, but is not suited to longer documents. The anecdotal consensus seems to be that an on-screen keyboard, with no tactile feedback, leads to more errors than a physical keyboard with real keys. Based on my research today, this simply isn’t the case. Instead, it’s the iPad’s software that’s causing the majority of typing errors.

I’ve never learnt to type properly – I use at most three fingers – but I can get around a physical keyboard pretty quickly. As an interface designer, I’m intrigued to see whether an on-screen keyboard really can be a valid alternative for a physical one. As a result, I’ve studied the iPad’s keyboard in quite a bit of detail.

The more I’ve looked into it, the more I’ve suspected that my typing isn’t actually at fault for the mistakes in my iPad documents. To test this theory, I positioned my iPhone 4S (the best video camera I own) over an iPad 2 (supported by a folded Smart Screen), and filmed myself typing some sample text into a Pages document. I decided that Pages, as the de facto (and Apple-created) word processor for iPad, would be the best test of using the device for long-form writing.

Here’s the video of my typing, played back at 12.5% of the original speed so that you can see the individual keys being pressed. I’ve used the on-screen keyboard’s highlighting of pressed keys (fading to a darker grey and back again) to ascertain which keys I have successfully pressed, and in which order. I deliberately used a piece of text I don’t know well, to avoid familiarity; the pauses in the video come from me reading each block of text from the screen of my Mac. (The video is 12 minutes long, and is quite dull to watch in its entirety; it’s included here primarily to illustrate the examples below.)

Here’s what I’m trying to type:

Of the causes which have induced me to print this volume I have little to say; my own opinion is, that it will ultimately do some service to science, and without that belief I would not have undertaken so thankless a task. That it is too true not to make enemies, is an opinion in which I concur with several of my friends, although I should hope that which I have written will not give just reason for the permanence of such feelings.

…and here’s what I end up with on the iPad (with differences from the original text highlighted in red):

Of the causes which have induced me to print this volume image little to say; my own opinions, that t will ultimately do some service to science, and without that belef I would not ave undertaken so tankless a task. That it’s tod rue nt to Mae enemies, is anopinionin which I concur with several of y friends, although I should le that what iave written will nt give just reason fr the permanence of such feelings.

Clearly this is an unacceptable number of errors. The first error occurs just after typing this volume. On the iPad keyboard, I correctly type i [space] have. There’s very little time between pressing h and a, but long enough for the framerate of the iPhone video camera to detect them as being pressed in the correct order.

Continue reading →

My Commute

Posted on by
4

Yesterday I attended the NESTA / Rewired State Make It Local hack day. Myself and five other developers were challenged to create something useful with local data in six hours. My contribution was “My Commute”, a travel planning web site for your daily commute to work.

The idea for My Commute was inspired by Paul Hammond’s excellent Minimuni, which is a great way to find your next San Francisco Muni to work… if you happen to live in Paul Hammond’s house. I wanted to make something similar available to anyone in a given area, based initially on the transport data opened up by Transport f0r Greater Manchester.

This proved to be a bit too much to achieve in six hours, but I made a good start – specifically in showing how the journey options and walking routes could be visualised. Here are a couple of screenshots of the day’s work in action, as viewed on a laptop and on a mobile device. Click on the screenshots to see a full-size version.

(The prototype site is held together by a few too many pieces of string and Sellotape to make it publicly available to play with, but I’ll try and hack it more into shape if time permits.)

The idea is pretty simple: click to set your work location, click to set your home location, and the system will work out the best trains and metros for you to catch right now, based on walking times (from the Google Maps API) to nearby stations, and scheduled times of departure. It will also give you an idea of how soon you’ll need to leave to catch a given service. It updates in real time, to show the best options for right now.

One of the key principles is that it considers all transport options, and all nearby stops. Not every journey will be from a stop just down the road, but often a slightly longer walk can lead to a quicker overall journey, especially in larger cities.

There are plenty of things missing from this hack:

  • I didn’t have time to get Manchester’s bus stops into the list of departure points (there are a lot of them, and the data mangling was a step too far for a one-day hack). This would have improved the number of journey options considerably.
  • More importantly, the system isn’t yet using actual travel data. Manchester have made all of their bus timetables available in CIF format, but there wasn’t time to get this into a queryable format.
  • Even if I had, the data would have been scheduled data, not real-time data. Making real-time data feeds available (assuming the data exists) would make the system more useful. You can still deduce likely arrival time from the scheduled timetable (as in this live bus map from a previous Rewired State event), but it doesn’t take into account any late-running services.
  • The journey time from the recommended stop to your actual destination isn’t yet taken in to account when calculating the best option for you to take.
  • The walking time is based on Google’s best estimate, and doesn’t provide alternatives for cycling or taking the car at the start or end of your journey.

Read the report.