Archive: November, 2014

Jessica and I entered the basement of The Dukes at Komedia last weekend to listen to Sarah and her band Spacedog provide live musical accompaniment to short sci-fi films from the end of the nineteenth and start of the twentieth centuries.

It was part of the Cine City festival, which is still going on here in Brighton—Spacedog will also be accompanying a performance of John Wyndham’s The Midwich Cuckoos, and there’s going to be a screening of François Truffaut’s brilliant film version of Ray Bradbury’s Fahrenheit 451 in the atmospheric surroundings of Brighton’s former reference library. I might try to get along to that, although there’s a good chance that I might cry at my favourite scene. Gets me every time.

Those 100-year old sci-fi shorts featured familiar themes—time travel, monsters, expeditions to space. I was reminded of a recent gathering in San Francisco with some of my nerdiest of nerdy friends, where we discussed which decade might qualify as the golden age of science fiction cinema. The 1980s certainly punched above their weight—1982 and 1985 were particularly good years—but I also said that I think we’re having a bit of a sci-fi cinematic golden age right now. This year alone we’ve had Edge Of Tomorrow, Guardians Of The Galaxy, and Interstellar.

Ah, Interstellar!

If you haven’t seen it yet, now would be a good time to stop reading. Imagine that I’ve written the word “spoilers” in all-caps, followed by many many line breaks before continuing.

Ten days before we watched Spacedog accompanying silent black and white movies in a tiny basement theatre, Jessica and I watched Interstellar on the largest screen we could get to. We were in Seattle, which meant we had the pleasure of experiencing the film projected in 70mm IMAX at the Pacific Science Center, right by the space needle.

I really, really liked it. Or, at least, I’ve now decided that I really, really liked it. I wasn’t sure when I first left the cinema. There were many things that bothered me, and those things battled against the many, many things that I really enjoyed. But having thought about it more—and, boy, does this film encourage thought and discussion—I’ve been able to resolve quite a few of the issues I was having with the film.

I hate to admit that most of my initial questions were on the science side of things. I wish I could’ve switched off that part of my brain.

There’s an apocryphal story about an actor asking “Where’s the light coming from?”, and being told “Same place as the music.” I distinctly remember thinking that very same question during Interstellar. The first planetfall of the film lands the actors and the audience on a world in orbit around a black hole. So where’s the light coming from?

The answer turns out to be that the light is coming from the accretion disk of that black hole.

But wouldn’t the radiation from the black hole instantly fry any puny humans that approach it? Wouldn’t the planet be ripped apart by the gravitational tides?

Not if it’s a rapidly-spinning supermassive black hole with a “gentle” singularity.

These are nit-picky questions that I wish I wasn’t thinking of. But I like the fact that there are answers to those questions. It’s just that I need to seek out those answers outside the context of the movie—I should probably read Kip Thorne’s book. The movie gives hints at resolving those questions—there’s just one mention of the gentle singularity—but it’s got other priorities: narrative, plot, emotion.

Still, I wish that Interstellar had managed to answer my questions while the film was still happening. This is something that Inception managed brilliantly: for all its twistiness, you always know exactly what’s going on, which is no mean feat. I’m hoping and expecting that Interstellar will reward repeated viewings. I’m certainly really looking forward to seeing it again.

In the meantime, I’ll content myself with re-watching Inception, which makes a fascinating companion piece to Interstellar. Both films deal with time and gravity as malleable, almost malevolent forces. But whereas Cobb travels as far inward as it is possible for a human to go, Coop travels as far outward as it is possible for our species to go.

Interstellar is kind of a mess. There’s plenty of sub-par dialogue and strange narrative choices. But I can readily forgive all that because of the sheer ambition and imagination on display. I’m not just talking about the imagination and ambition of the film-makers—I’m talking about the ambition and imagination of the human race.

That’s at the heart of the film, and it’s a message I can readily get behind.

Before we even get into space, we’re shown a future that, by any reasonable definition, would be considered a dystopia. The human race has been reduced to a small fraction of its former population, technological knowledge has been lost, and the planet is dying. And yet, where this would normally be the perfect storm required to show roving bands of road warriors pillaging their way across the dusty landscape, here we get an agrarian society with no hint of violence. The nightmare scenario is not that the human race is wiped out through savagery, but that the human race dies out through a lack of ambition and imagination.

Religion isn’t mentioned once in this future, but Interstellar does feature a deus ex machina in the shape of a wormhole that saves the day for the human race. I really like the fact that this deus ex machina isn’t something that’s revealed at the end of the movie—it’s revealed very early on. The whole plot turns out to be a glorious mash-up of two paradoxes: the bootstrap paradox and the twin paradox.

The end result feels like a mixture of two different works by Arthur C. Clarke: The Songs Of Distant Earth and 2001: A Space Odyssey.

2001 is the more obvious work to compare it to, and the film readily invites that comparison. Many reviewers have been quite to point out that Interstellar doesn’t reach the same heights as Kubrick’s 2001. That’s a fair point. But then again, I’m not sure that any film can ever reach the bar set by 2001. I honestly think it’s as close to perfect as any film has ever come.

But I think it’s worth pointing out that when 2001 was released, it was not greeted with universal critical acclaim. Quite the opposite. Many reviewers found it tedious, cold, and baffling. It divided opinion greatly …much like Interstellar is doing now.

In some ways, Interstellar offers a direct challenge to 2001—what if mankind’s uplifting is not caused by benevolent alien beings, but by the distant descendants of the human race?

This is revealed as a plot twist, but it was pretty clearly signposted from early in the film. So, not much of a plot twist then, right?

Well, maybe not. What if Coop’s hypothesis—that the wormhole is the creation of future humans—isn’t entirely correct? He isn’t the only one who crosses the event horizon. He is accompanied by the robot TARS. In the end, the human race is saved by the combination of Coop the human’s connection to his daughter, and the analysis carried out by TARS. Perhaps what we’re witnessing there is a glimpse of the true future for our species; human-machine collaboration. After all, if humanity is going to transcend into a fifth-dimensional species at some future point, it’s unlikely to happen through biology alone. But if you combine the best of the biological—a parent’s love for their child—with the best of technology, then perhaps our post-human future becomes not only plausible, but inevitable.

Deus ex machina.

Thinking about the future of the species in this co-operative way helps alleviate the uncomfortable feeling I had that Interstellar was promoting a kind of Manifest Destiny for the human race …although I’m not sure that I’m any more comfortable with that being replaced by a benevolent technological determinism.

John Gruber quite rightly skewers a paywall-proteced “sky is falling” piece in the Wall Street Journal called The Web Is Dying; Apps Are Killing It, writing that native apps are part of the web:

They’re just superior clients to open Internet services.

This is something I wrote about earlier this year:

There’s a whole category of native apps that could just as easily be described as “artisanal web browsers” (and if someone wants to write a browser extension that replaces every mention of “native app” with “artisanal web browser” that would be just peachy).

Instagram’s native app is a web browser.

Facebook’s native app is a web browser.

Twitter’s native app is a web browser.

In that same piece, I try to define exactly what the web is:

Well, the unsexy definition I’ve used in the past is that the web consists of files (e.g. HTML, CSS, JavaScript), accessible at URLs, delivered over HTTP.

John also gives a defintion of what the web is:

There are two big four-letter “H” acronyms that powered the web from the beginning: HTML (client), and HTTP (networking protocol). Native apps are just an alternative to HTML running in a web browser (and many native apps still use HTML web views embedded within the apps themselves to render parts of their interface). Almost all native apps use HTTP/S for networking, though.

Notice the difference? Whereas John talks about two things that define the web (HTTP/S and HTML), I talk about three: HTTP(S), HTML, and URLs:

But to be honest, I don’t think that the Hypertext Transfer Protocol is the important part of the web; it’s the URLs that really matter. It’s the addressability of the files that’s the killer app of the web in my opinion.

URLs are what give the web is its reach, and that’s what’s still missing from native apps.

But John’s fundamental point that native apps and the web are not fundumentally opposed? I completely agree with that. They are complementary. Irakli Nadareishvili wrote about this false dichotomy recently in a post called Responsive Web Design or Native Mobile Apps?:

Native mobile applications are not going anywhere and the future of all websites is to be responsive. These two assertions are not mutually exclusive, they are complementary – don’t create apps when what you actually need is a website; but also don’t pretend webapps can completely replace native applications, because they can’t.

It’s also worth remembering that even if you’re using a native app—like, say, Facebook or Twitter—you’re still going to spend a lot of time following links and reading stuff that’s rendered in the app, but that lives out on the world wide web. And the reason why those apps can access those resources is because those resources have URLs.

URLs are not an implementation detail. The URI is the thing.

There’s nothing quite so tedious as blogging about blogging, but I came across a few heart-warming thoughts recently that it would be remiss of me to let go unremarked, so please indulge me for a moment as I wallow in some meta-blogging.

Marco Arment talks about the trend that many others have noticed, of personal publishing dying out in favour of tweeting:

Too much of my writing in the last few years has gone exclusively into Twitter. I need to find a better balance.

As he rightly points out:

Twitter is a complementary medium to blogging, but it’s not a replacement.

Andy noticed a similar trend in his own writing:

Twitter and Waxy Links cannibalized all the smaller posts, and as my reach grew, I started reserving blogging for more “serious” stuff — mostly longer-form research and investigative writing.

Well, fuck that.

Amber Hewitt also talks about reviving the personal blog:

Someone made an analogy that describes social networks very well. Facebook is your neighborhood, Twitter is your local bar, and your blog is your home. (I guess Instagram is the cafe? “Look what I’m eating!”)

This made me realized I’m neglecting my home. My posts and photos are spread out on different networks and there is no centralized hub.

That reminds me of what Frank said about his site:

In light of the noisy, fragmented internet, I want a unified place for myself—the internet version of a quiet, cluttered cottage in the country.

The wonderful Gina Trapani—who has has publishing on her own site for years now—follows Andy’s lead with some guidelines for short-form blogging:

• If it’s a paragraph, it’s a post.
• Negotiate a comfort zone.
• Traffic is irrelevant.
• Simplify, simplify.
• Ask for trusted collaborator feedback.
• Have fun.

Good advice.

The supersmart Scott Jenson just gave a talk at The Web Is in Cardiff, which was by all accounts, excellent. I wish I could have seen it, but I’m currently chilling out in Florida and I haven’t mastered the art of bilocation.

Last week, Scott wrote a blog post called My Issue with Progressive Enhancement (he wrote it on Google+, which is why you might not have seen it).

In it, he takes to task the idea that—through progressive enhancement—you should be able to offer all functionality to all browsers, thereby foregoing the use of newer technologies that aren’t universally supported.

If that were what progressive enhancement meant, I’d be with him all the way. But progressive enhancement is not about offering all functionality; progressive enhancement is about making sure that your core functionality is available to everyone. Everything after that is, well, an enhancement (the clue is in the name).

The trick to doing this well is figuring out what is core functionality, and what is an enhancement. There are no hard and fast rules.

Sometimes it’s really obvious. Web fonts? They’re an enhancement. Rounded corners? An enhancement. Gradients? An enhancement. Actually, come to think of it, all of your CSS is an enhancement. Your content, on the other hand, is not. That should be available to everyone. And in the case of task-based web thangs, that means the fundamental tasks should be available to everyone …but you can still layer more tasks on top.

If you’re building an e-commerce site, then being able to add items to a shopping cart and being able to check out are your core tasks. Once you’ve got that working with good ol’ HTML form elements, then you can go crazy with your enhancements: animating, transitioning, swiping, dragging, dropping …the sky’s the limit.

This is exactly what Orde Saunders describes:

I’m not suggesting that you try and replicate all your JavaScript functionality when it’s disabled, above all that’s just not practical. What you should be aiming for is being able to complete the basics - for example adding a product to a shopping cart and then checking out. This is necessarily going to be clunky as judged by current standards and I suggest you don’t spend much time on optimising this process.

Scott asked about building a camera app with progressive enhancement:

Snarky Question: How are you supposed to ‘progressively enhance’ an HTML camera app? Show puppies? Not everything devolves to simple markup

— Scott Jenson (@scottjenson) October 25, 2014

Here again, the real question to ask is “what is the core functionality?” Building a camera app is a means to an end, not the end itself. You need to ask what the end goal is. Perhaps it’s “enable people to share photos with their friends.” Going back to good ol’ HTML, you can accomplish that task with:

<input type="file" accept="image/*">

Now that you’ve got that out of the way, you can spend the majority of your time making the best damn camera app you can, using all the latest browser technologies. (Perhaps WebRTC? Maybe use a canvas element to display the captured image data and apply CSS filters on top?)

Scott says:

My point is that not everything devolves to content. Sometimes the functionality is the point.

I agree wholeheartedly. In fact, I would say that even in the case of “content” sites, functionality is still the point—the functionality would be reading/hearing/accessing content. But I think that Scott is misunderstanding progressive enhancement if he think it means providing all the functionality that one can possibly provide.

Mat recently pointed out that there are plenty of enhancements on the Boston Globe site that require JavaScript, but the core functionality is available to everyone:

@jgarber @mjacksonw Right. Lots of cool features on the Boston Globe don’t work when JS breaks; “reading the news” is not one of them.

— mat marqNOVEMBER (@wilto) September 25, 2014

Scott again:

What I’m chaffing at is the belief that when a page is offering specific functionality, Let’s say a camera app or a chat app, what does it mean to progressively enhance it?

Again, a realtime chat app is a means to an end. What is it enabling? The ability for people to talk to each other over the web? Okay, we can do that using good ol’ HTML—text and form elements—with full page refreshes. That won’t be realtime. That’s okay. The realtime part is an enhancement. Use Web Sockets and WebRTC (in the browsers that support them) to provide the realtime experience. But everyone gets the core functionality.

Like I said, the trick is figuring out what’s core functionality and what’s an enhancement.

Ethan provides another example. Let’s say you’re building a browser-based rich text editor, that uses JavaScript to do all sorts of formatting on the fly. The core functionality is not the formatting on the fly; the core functionality is being able to edit text:

@scottjenson That was how we approached @geteditorially’s rich editor, anyway: start with a textarea, layer on functionality from there.

— Ethan Marcotte (@beep) October 25, 2014

If progressive enhancement truly meant making all functionality available to everyone, then it would be unworkable. I think that’s a common misconception around progressive enhancement; there’s this idea that using progressive enhancement means that you’re going to spend all your time making stuff work in older browsers. In fact, it’s the exact opposite. As long as you spend a little bit of time at the start making sure that the core functionality works with good ol’ fashioned HTML, then you can spend most of your time trying out the latest and greatest browser technologies.

As Orde put it:

What you are going to be spending the majority of your time and effort on is the enhanced JavaScript version as that is how the majority of your customers will be experiencing your site.

The other Scott—Scott Jehl—wrote a while back:

For us, building with Progressive Enhancement moves almost all of our development time and costs to newer browsers, not older ones.

Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.

Approaching browser support this way requires a different way of thinking. For everything you’re building, you need to ask “is this core functionality, or is it an enhancment?” and build accordingly. It takes a bit of getting used to, but it gets easier the more you do it (until, after a while, it becomes second nature).

But if you’re thinking about progressive enhancement as “devolving” down—as Scott Jenson describes in his post—then I think you’re on the wrong track. Instead it’s about taking care of the core functionality quickly and then spending your time “enhancing” up.

Scott asks:

Shouldn’t we be allowed to experiment? Isn’t it reasonable to build things that push the envelope?

Absolutely! And the best and safest way to do that is to make sure that you’re providing your core functionality for everyone. Once you do that, you can go nuts with the latest and greatest experimental envelope-pushing technologies, secure in the knowledge that you don’t even need to worry about the fact that they don’t work in older browsers. Geolocation! Offline storage! Device APIs! Anything you can think of, you can use as a powerful enhancement on top of your core tasks.

Once you realise this, it’s immensely liberating to use progressive enhancement. You can have the best of both worlds: universal access to core functionality, combined with all the latest cuting-edge technology too.