Tags: panel



Sunday, September 30th, 2018

Control Panel

Analogue switches, dials, and buttons, buttons, buttons (just like that Flickr group I linked to).

Monday, May 1st, 2017

Control Panel | Flickr

Photos of analogue interfaces: switches, knobs, levers, dials, buttons, so many buttons.

Wednesday, March 8th, 2017

AMP and the Web - TimKadlec.com

Tim watched the panel discussion at AMP Conf. He has opinions.

Optimistically, AMP may be a stepping stone to a better performant web. But I still can’t shake the feeling that, in its current form, it’s more of a detour.

AMP Conf: Day 1 Live Stream - YouTube

Here’s the panel I was on at the AMP conference. It was an honour and a pleasure to share the stage with Nicole, Sarah, Gina, and Mike.

Fireside chat: AMP and the web (AMP Conf '17)

Saturday, June 25th, 2016

The Progressive Web App Dev Summit

I was in Amsterdam again at the start of last week for the Progressive Web App Dev Summit, organised by Google. Most of the talks were given by Google employees, but not all—this wasn’t just a European version of Google I/O. Representatives from Opera, Mozilla, Samsung, and Microsoft were also there, and there were quite a few case studies from independent companies. That was very gratifying to see.

Almost all the talks were related to progressive web apps. I say, “almost all” because there were occasional outliers. There was a talk on web components, which don’t have anything directly to do with progressive web apps (and I hope there won’t be any attempts to suggest otherwise), and another on rendering performance that had good advice for anyone building any kind of website. Most of the talks were about the building blocks of progressive web apps: HTTPS, Service Workers, push notifications, and all that jazz.

I was very pleased to see that there was a move away from the suggesting that single-page apps with the app-shell architecture model were the only way of building progressive web apps.

There were lots of great examples of progressively enhancing existing sites into progressive web apps. Jeff Posnick’s talk was a step-by-step walkthrough of doing exactly that. Reading through the agenda, I was really happy to see this message repeated again and again:

In this session we’ll take an online-only site and turn it into a fully network-resilient, offline-first installable progressive web app. We’ll also break out of the app shell and look at approaches that better-suit traditional server-driven sites.

Progressive Web Apps should work everywhere for every user. But what happens when the technology and API’s are not available for in your users browser? In this talk we will show you how you can think about and build sites that work everywhere.

Progressive Web Apps should load fast, work great offline, and progressively enhance to a better experience in modern browsers.

How do you put the “progressive” into your current web app?

You can (and should!) build for the latest and greatest browsers, but through a collection of fallbacks and progressive enhancements you can bring a lot tomorrow’s web to yesterday’s browsers.

I think this is a really smart move. It’s a lot easier to sell people on incremental changes than it is to convince them to rip everything out and start from scratch (another reason why I’m dubious about any association between web components and progressive web apps—but I’ll save that for another post).

The other angle that I really liked was the emphasis on emerging markets, not just wealthy westerners. Tal Oppenheimer’s talk Building for Billions was superb, and Alex kicked the whole thing off with some great facts and figures on mobile usage.

In my mind, these two threads are very much related. Progressive enhancement allows us to have our progressive web app cake and eat it too: we can make websites that can be accessed on devices with limited storage and slow networks, while at the same time ensuring those same sites take advantage of all the newest features in the latest and greatest browsers. I talked to a lot of Google devs about ways to measure the quality of a progressive web app, and I’m coming to the conclusion that a truly high-quality site is one that can still be accessed by a proxy browser like Opera Mini, while providing a turbo-charged experience in the latest version of Chrome. If you think that sounds naive or unrealistic, then I think you might want to dive deeper into all the technologies that make progressive web apps so powerful—responsive design, Service Workers, a manifest file, HTTPS, push notifications; all of those features can and should be used in a layered fashion.

Speaking of Opera, Andreas kind of stole the show, demoing the latest interface experiments in Opera Mobile.

That ambient badging that Alex was talking about? Opera is doing it. The importance of being able to access URLs that I’ve been ranting about? Opera is doing it.

Then we had the idea to somehow connect it to the “pull-to-refresh” spinner, as a secondary gesture to the left or right.

Nice! I’m looking forward to seeing what other browsers come up with it. It’s genuinely exciting to see all these different browser makers in complete agreement on which standards they want to support, while at the same time differentiating their products by competing on user experience. Microsoft recently announced that progressive web apps will be indexed in their app store just like native apps—a really interesting move.

The Progressive Web App Dev Summit wrapped up with a closing panel, that I had the honour of hosting. I thought it was very brave of Paul to ask me to host this, considering my strident criticism of Google’s missteps.

Initially there were going to be six people on the panel. Then it became eight. Then I blinked and it suddenly became twelve. Less of a panel, more of a jury. Half the panelists were from Google and the other half were from Opera, Microsoft, Mozilla, and Samsung. Some of those representatives were a bit too media-trained for my liking: Ali from Microsoft tried to just give a spiel, and Alex Komoroske from Google wouldn’t give me a straight answer about whether he wants Android Instant apps to succeed—Jake was a bit more honest. I should have channelled my inner Paxman a bit more.

Needless to say, nobody from Apple was at the event. No surprise there. They’ve already promised to come to the next event. There won’t be an Apple representative on stage, obviously—that would be asking too much, wouldn’t it? But at least it looks like they’re finally making an effort to engage with the wider developer community.

All in all, the Progressive Web App Dev Summit was good fun. I found the event quite inspiring, although the sausage festiness of the attendees was depressing. It would be good if the marketing for these events reached a wider audience—I met a lot of developers who only found out about it a week or two before the event.

I really hope that people will come away with the message that they can get started with progressive web apps right now without having to re-architect their whole site. Right now the barrier to entry is having your site running on HTTPS. Once you’ve got that up and running, it’s pretty much a no-brainer to add a manifest file and a basic Service Worker—to boost performance if nothing else. From there, you’re in a great position to incrementally add more and more features—an offline-first approach with your Service Worker, perhaps? Or maybe start dabbling in push notifications. The great thing about all of these technologies (with the glaring exception of web components in their current state) is that you don’t need to bet the farm on any of them. Try them out. Use them as enhancements. You’ve literally got nothing to lose …and your users have everything to gain.

Wednesday, June 22nd, 2016

PWAs: The Panel (Progressive Web App Summit 2016) - YouTube

Here’s the video of the panel I moderated yesterday at the Progressive Web App Dev Summit. I had to get a bit Paxman at times with some of the more media-trained panelists.

PWAs: The Panel (Progressive Web App Summit 2016)

Tuesday, June 14th, 2016

Amsterdam Brighton Amsterdam

I’m about to have a crazy few days that will see me bouncing between Brighton and Amsterdam.

It starts tomorrow. I’m flying to Amsterdam in the morning and speaking at this Icons event in the afternoon about digital preservation and long-term thinking.

Then, the next morning, I’ll be opening up the inaugural HTML Special which is a new addition the CSS Day conference. Each talk on Thursday will cover one HTML element. I am honoured to speaking about the A element. Here’s the talk description:

The world exploded into a whirling network of kinships, where everything pointed to everything else, everything explained everything else…

Enquire within upon everything.

I’ve been working all out to get this talk done and I finally wrapped it up today. Right now, I feel pretty happy with it, but I bet I’ll change that opinion in the next 48 hours. I’m pretty sure that this will be one of those talks that people will either love or hate, kind of like my 2008 dConstruct talk, The System Of The World.

After CSS Day, I’ll be heading back to Brighton on Saturday, June 18th to play a Salter Cane gig in The Greys pub. If you’re around, you should definitely come along—not only is it free, but there will be some excellent support courtesy of Jon London, and Lucas and King.

Then, the next morning, I’ll be speaking at DrupalCamp Brighton, opening up day two of the event. I won’t be able to stick around long afterwards though, because I need to skidaddle to the airport to go back to Amsterdam!

Google are having their Progressive Web App Dev Summit there on Monday on Tuesday. I’ll be moderating a panel on the second day, so I’ll need to pay close attention to all the talks. I’ll be grilling representatives from Google, Samsung, Opera, Microsoft, and Mozilla. Considering my recent rants about some very bad decisions on the part of Google’s Chrome team, it’s very brave of them to ask me to be there, much less moderate a panel in public.

You can still register for the event, by the way. Like the Salter Cane gig, it’s free. But if you can’t make it along, I’d still like to know what you think I should be asking the panelists about.

Got a burning question for browser/device makers? Write it down, post it somewhere on the web with a link back to this post, and then send me a web mention (there’s a form for you to paste in the URL at the bottom of this post).

Wednesday, August 26th, 2015

180: Panel on “Inline Styles” - ShopTalk on Huffduffer

Shop Talk Show is trying a new panel format. They got me on to join in the discussion about adding inline styles with JavaScript instead of using Cascading Style Sheets.

Monday, July 13th, 2015

Edge Conference 2015 - 5 Progressive Enhancement - YouTube

Here’s the video of the panel I participated in at Edge conference, expertly moderated by Lyza.

Thanks to the video editing, you can’t see the face I’m making when the guy from Facebook talks about user-agent sniffing as a totally cool and reliable way of working.

Edge Conference 2015 - 5 Progressive Enhancement

Tuesday, June 30th, 2015

Edge words

I really enjoyed last year’s Edge conference so I made sure not to miss this year’s event, which took place last weekend.

The format was a little different this time ‘round. Last year the whole day was taken up with panels. Now, panels are often rambling, cringeworthy affairs, but Edge Conf is one of the few events that does panels well: they’re run on a tight schedule and put together with lots of work in advance. At this year’s Edge, the morning was taken up with these tightly-run panels as usual, but the afternoon consisted of more Barcamp-like breakout sessions.

I’ve got to be honest: I don’t think the new format worked that well. The breakout sessions didn’t have the true flexibility that you get with an unconference schedule, so there was no opportunity to merge similarly-themed sessions. There was, for example, a session on components at the same time as a session on accessibility in web components.

That highlights the other issue: FOMO. I’m really not a fan of multi-track events; there were so many sessions that sounded really interesting, but I couldn’t clone myself and go to all of them at once.

But, like I said, the first half of the day was taken up with four sequential (rather than parallel) panels and they were all excellent. All of the moderators did a fantastic job, and I was fortunate enough to sit in on the progressive enhancement panel expertly moderated by Lyza.

The event is called Edge for a reason. There is a rarefied atmosphere—and not just because of the broken-down air conditioning. This is a room full of developers on the cutting edge of web development technologies. Being at Edge Conf means being in a bubble. And being in a bubble is absolutely fine as long as you’re aware you’re in a bubble. It would be problematic if anyone were to mistake the audience and the discussions at Edge as being in any way representative of typical working web devs.

One of the most insightful comments of the day came from Christian who said, “Yes, but this is Edge Conf.” You’re going to need some context for that quote, so here it is…

On the web components panel that Christian was moderating, Alex was making a point about the ubiquity of tools—”Tooling was save you”, he said—and he asked for a show of hands from the audience on who was not using some particular tooling technology; transpilers, package managers, build tools, I can’t remember the specific question. Nobody put their hand up. “See?” asked Alex. “Yes”, said Christian, “but this is Edge Conf.”

Now, while I wasn’t keen on the format of the afternoon with its multiple simultaneous breakout sessions, that doesn’t mean I didn’t enjoy the ones I plumped for. Quite the opposite. The last breakout session of the day, again expertly moderated by Lyza, was particularly great.

The discussion was all about progressive enhancement. There seemed to be a general consensus that we’re all 100% committed to the results of progressive enhancement—greater availability, wider reach, and better performance—but that the term itself is widely misunderstood as “making all of your functionality work even with JavaScript switched off”. This misunderstanding couldn’t be further from the truth:

  1. It’s not about making all of your functionality available; it’s making your core functionality available: everything else can be considered an enhancement and it’s perfectly fine if not everyone gets that enhancement.
  2. This isn’t about switching JavaScript off; it’s about any particular technology not being available for reasons we can’t foresee (network issues, browser issues, whatever it may be).

And yet the misunderstanding persists. For that reason, most of the people in the discussion at Edge Conf were in favour of simply dropping the term progressive enhancement and instead focusing on terms like availability and access. Tim writes:

I’m not sure what we call it now. Maybe we do need another term to get people to move away from the “progressive enhancement = working without JS” baggage that distracts from the real goal.

And Stuart writes:

So I’m not going to be talking about progressive enhancement any more. I’m going to be talking about availability. About reach. About my web apps being for everyone even when the universe tries to get in the way.

But Jason writes:

I completely disagree that we should change nomenclature because there exists some small segment of Web designers unwilling to expand their development toolbox. I think progressive enhancement—the term—remains useful, descriptive, and appropriate.

I’m torn. On the one hand, I agree with Jason. The term “progressive enhancement” is a great descriptor. But on the other hand, I don’t want to end up like that guy who’s made it his life’s work to change every instance of the phrase “comprises of” to “comprises” (or “consists of”) on Wikipedia. Technically, he’s correct. But it doesn’t sound like a fun way to spend your days.

I guess my worry is, if I write an article or give a presentation, and I title it something to do with progressive enhancement, am I going to alienate and put off the very audience I’m trying to reach? But if I title it something else, am I tricking people?

Words are hard.

Sunday, June 30th, 2013

Hot Topics Panel with Jeremy Keith - Mobilism 2013, Day 2, Afternoon, Final session on Vimeo

The closing hot topics panel I moderated at this year’s Mobilism conference in Amsterdam, featuring Remy, Wilto, Jake, and Dan.

Hot Topics Panel with Jeremy Keith - Mobilism 2013, Day 2, Afternoon, Final session

Thursday, May 9th, 2013

Mobilism hot topics panel

The programme for this year’s Mobilism conference in Amsterdam looks hot, hot, hot! It will wrap up with that hottest of hot things: a hot topics panel. Hot!

By the way, there are still tickets available. I suggest you grab one if you haven’t already. It’s a great gathering but for some reason it’s not selling as well this year, which means this could be your last chance to attend.

I’ve really, really enjoyed the previous two Mobilisms, and I always get a kick out of moderating panels so I’m pretty chuffed about getting the chance to host a panel for the third year running.

The first year, the panel was made up of Mobile browser vendors (excluding Apple, of course). Last year, it was more of a mixed bag of vendors and developers. This year …well, we’ll see. I’ll assemble the panel over the course of the conference’s two days. I plan to choose the sassiest and most outspoken of speakers—the last thing you want on a panel is a collection of meek, media-trained company shills.

Mind you, Dan has managed to buy his way onto the panel through some kind of sponsorship deal, but I’m hoping he’ll be able to contribute something useful about Firefox OS.

Apart from that one preordained panelist, everything else is up in the air. To help me decide who to invite onto the panel, it would be really nice to have an idea of what kind of topics people want to have us discuss. Basically, what’s hot and what’s not.

So …got a burning question about mobile, the web, or the “mobile web” (whatever that means)? I want to hear it.

If you could leave a comment with your question, ‘twould be much appreciated.

Friday, May 11th, 2012

API Panel

The video of the panel I moderated on device and network APIs on the second day of Mobilism in Amsterdam. It’s not quite as snappy as the browser panel (which, given the subject matter, is unsurprising) but it was still good fun.

Mobile Browser Panel 2012, Mobile Browser Panel at Mobilism 2012 Moderated by Jeremy Keith, this panel features Andrea Trasatti (Nokia), Andreas Bovens (O…

Here’s the video of the mobile browser panel I moderated at Mobilism in Amsterdam. These guys were really good sports to put up with my wisecracking shots for cheap laughs at their expense.

Wednesday, May 2nd, 2012

Questions for Mobilism

I’m going to Amsterdam next week for the Mobilism conference. Bizarrely, there are still tickets available. I say “bizarrely” because it’s such an excellent event—it’s like the European equivalent of the Breaking Development conference.

Don’t worry; I won’t be giving a presentation. I’ll leave that to experts like Remy, Lyza, Brad, and Jake. But I will be getting up on the stage. I’m going to moderating not one, but two, panels. I think it’s going to be fun.

We’ll be reprising the Mobile Browser panel from last year. Once again, there will be representatives from Opera, RIM, and Nokia. This year Google is also joining the line-up. As usual, Apple will not be present.

The new addition to the schedule is a panel on device and network APIs. I will be playing the part of a curious but clueless web developer interested in such things …because, well, that’s what I am.

I plan to open up both panels to questions from the audience. While I don’t quite fall into Cennydd’s camp, it would be great if more people would read this article on how to ask a question:

You have not been invited to give a speech. Before you stand up, boil your thoughts down to a single point. Then ask yourself if this point is something you want to assert or something you want to find out. There are exceptions, but if your point falls into the category of assertion, you should probably remain seated.

But I’m not planning to leave the questions entirely to the people in the room. Just as I did last year, I’d like to ask you to tell me what topics are burning in your mind when it comes to mobile browsers or device APIs.

Comments are open for one week. Let fly with your questions.

Thursday, March 22nd, 2012

Get Excited and Make Things with Science

This is the transcript of a panel held at South by Southwest 2012 in Austin, Texas. The panelists are Ariel Waldman, Matt Bellis, and Jeremy Keith.

Ariel: Welcome to Get Excited and Make Things with Science. I hope you all are excited, as it seems like you are.

Was that a cat meow? Jesus!

So yes, welcome to Get Excited and Make Things with Science. We have some lovely slides up here.

This is a launch of some teddy bears into space and so I thought that represented getting excited and making things with science. So this isn’t Photoshop; this is actually a real picture.

And if you want to get really excited, you can hashtag us at #sxgetexcited, but we’ll just start with some brief intros to kick things off.

Jeremy, how did you get here?

Jeremy: Okay, can everybody hear me? This lapel mic thing or should I use this one. Okay, I’ll use this one. That makes it easier.

I got here because of South by South West, actually, which was two years ago? Two years ago when I was here there was an awesome science panel, which was moderated by Tantek who’s sitting there. Ariel was on the panel and a bunch of other citizen scientists. And it was really, really inspiring. It was one of the best panels I’ve seen at South by South West.

A f***ing space elevator

Open Science: Create, Collaborate, Communicate on Huffduffer

But one of the points that was coming across was there was all these APIs out there that people weren’t using. People were having hack days and doing mash-ups, and they were doing stuff with Google Maps or something. We’ve mapped the moon! We’ve mapped Mars! Nobody’s doing hacks and mash-ups with that kind of data.

I distinctly remember sitting in the audience of the panel and turning to my friend and saying, “we should have a Science Hack Day.” And then rather than it just remaining an idea, I did it.

So we had the world’s first Science Hack Day in London later that summer. And it was incredible. We managed to get a venue which was at the Guardian offices in London. We got a bunch of developers into the room and some scientists as well, and it was a lot of fun.

I’ve been to hack days before which is, you know, developers getting together for forty eight hours, essentially hacking straight through for twenty four hours and making something cool. Usually mash-ups and stuff. So it was basically a hack day like that, but with the emphasis on science. In other words, the APIs and the data that you’d be mashing with would be science data, and that was awesome; that showed that it could work and that’s what got me here.

Ariel: Matt?

Matt So, my name’s Matt. I’m a particle physicist by training and I was doing research at Stanford University on BaBar experiments—I’ll mention a little bit more on that later—and the experiment was based at SLAC, which is an international lab on Stanford Campus.

I’d been trying to work with some people in communications there to do some outreach projects, and through that I met Dave Harris, who is a friend of Ariel’s. We tried getting some stuff, but there was just limited resources. He’s like, “well look my friend Ariel’s putting together this Science Hack Day, and some of these outreach ideas, some of the ideas of taking a particle physics data and making it more accessible, you might be able to get other people involved in working on the project.” Then I participated in that first Science Hack Day down in Palo Alto.

Particle Wind Chime demo

It was a great success. I’ve done another one in San Francisco since then. I’ll talk more about those in detail, but that was the path that led me to hack day in general, and Ariel and here.

Ariel: Great. So I’m Ariel and I am on a really awesome panel, because Jeremy is an awesome web developer, Matt’s a great particle physicist.

I myself, however, am neither a programmer or a scientist. I have no background in science and my degree is actually originally in print graphic design. That didn’t really end up going anywhere.

So a few years ago I randomly got a job at NASA. It was amazing. I never expected to work there. It completely changed my life.

Since working at NASA I am now on this mission to really change how we view space exploration. I always like showing this slide because space exploration often changes how we view ourselves and our place in the universe. But I really think we should change how we start viewing space exploration and science, and it being something that you don’t have to have a formal science background to do and to participate.

In a Science Hack Day you don’t need to be a developer or a scientist. Sometimes it helps, but I have proven that you don’t have to be one. So then also I went on to create Science Hack Day San Francisco, after Jeremy created his in London.


So without further ado, Jeremy, do you want to discuss some of your favourite science hacks?

Jeremy: Oh yes!

Ariel: Why they’re awesome.

Jeremy: I’m just going to geek out for a while, and tell you about things I think are awesome; specifically, science hacks.

I remember being at the hack day—not a Science Hack Day, this was one of the official sort of Yahoo! BBC hack days in London at Alexandra Palace—and it was an amazing experience. It was just a fantastic time, and there’s all sorts of hacks and mash-ups and stuff being done, incredibly inspiring stuff.

But one of the ones that I really liked was just really simple, a really simple example of a mash-up. It was this, which is a Twitter account. It’s a Twitter account that’s a bot, and it mashes up just two simple bits of data. One is: when is the ISS flying over, or when there’ll be iridium flares from satellites. The other is: what’s the weather forecast for London right now, because it can get pretty cloudy in London.

So it’s a very simple little Twitterbot that just says, “Hey, the ISS will be flying over and it’s going to be clear outside.” Simple, right? I know everybody makes lots of Twitterbots these days, it’s kind of the “hello world” of mashing up, but this was a few years ago, this was, a pretty cool idea.

I really love the simplicity of that, just taking these two sources of data, putting them together and making something really cool and really useful, that you go outside and see the ISS fly over, which is awesome.

Another example of one of these Twitterbots is Low Flying Rocks, which is really nice. That’s just again taking a feed of information that we have, which is when near earth objects are passing by the earth and just Tweeting when it happens, and interjecting maybe, if it’s a close one, it says, ‘Phew, that was close!’

I love these little Twitterbots like that.

So at the Science Hack Day in Palo Alto, Nathan Bergey—who’s a rocket scientist, amateur rocket scientist in Portland—he was at the Hack Day, and he took this Twitterbot, and he decided he wanted to make a sort of physical representation of it. So he was going to make the Near Earth Object Lamp. Instead of Tweeting when an asteroid was about to pass close to the earth, you’d get a glow; you’d get this ambient signifier.

Near Earth Object Lamp

It was truly a hack. He’s got cups that happen to be lying around the room, an arduino that’s connecting it up to a laptop, LEDs to glow.

Cup hack

You’d just have this thing sitting there, and it glows when there’s rocks flying past. And he actually—here’s a video over here doing it, it was awesome, it was really cool.

That all happened in the course of the Science Hack Day at Palo Alto. Brilliant little idea. There we go: glow away.

He took this one stage further after the Hack Day he thought, “Okay, here’s another idea. What if we went back to that Twitterbot of when the ISS is flying over.” Now, instead of getting a Tweet when the ISS flies over, you’re going to have a lamp that lights up. He put this idea out there and he put it on Kickstarter, and it got funded. So you can now order your ISS lamp that will glow when the ISS is flying over, so you can nip outside, look up in the sky, and see the International Space Station flying over.

I love that hack. I think it’s great. I particularly like it when there’s some sort of physical dimension to the hacks, and especially when it’s taking something from the network and making it physical. I think that’s really nice.

At Science Hack Day in London there were some people making a paper mâché globe of the Earth that had LEDs inside it, again connected with an arduino. But the datastream that they were connecting it to was the aurora borealis, when they were lighting up. So as the auroras were lighting up in real life, you got this beautiful ambient lamp lighting up. Really nice.

Science Hack Day

One of the things about the hack days is it’s always …there’s generally no shortage of developers showing up at hack days which is great, and I really like it when hardware hackers show up too, but it can be tough to get designers showing up at Science Hack Days. Or at hack days in general I would say, it can be tricky to convince the designers to come.

I was really trying to do that in the run-up to the Science Hack Day in London. I was really trying to convince designers to come along. There were a few designers there but it would’ve been nice to have some more.

So at the Science Hack Day in Palo Alto, I wanted to show how design can really help in the story of science and help in telling the story of science and data visualisation. I put together this little hack over the course of the Science Hack Day in Palo Alto. It’s just a simple little web page called Space Lift.

Spacelift, printed

What it does is it just compares the cost of getting a cargo into geosynchronous orbit using various rockets, right? Now the cargo I chose happened to be various fictional spacecraft, like the Millennium Falcon or an X-Wing or Battlestar Galactica. It then compares how many of those rockets it would take and how much it would cost to lift this cargo into orbit. But always ending with how much it would cost with a space elevator.

It’s always cheaper with a space elevator!

I’m trying to tell a fairly obvious story here, which is that we need to build a space elevator, and here’s why. I’m making the financial case and I’m trying to use visualisation to do it. I mean, you can sort of see it when it’s just an X-Wing that you’re trying to lift into geosynchronous orbit, but if it’s a Rebel Blockade Runner, you can clearly see the astronomical—literally—costs it takes …or one space elevator, right?

Papernet spacelift

You can actually then click through any of these and you can see that represented. The cost can be represented as a pile of pennies, and you can see the relationship with that pile of pennies to a space elevator: whether it would be a pile of pennies greater than a space elevator.

Those are all the things that happened at hack days, but there’s a whole bunch of wonderful websites that are kind of in the spirit of Science Hack Day, the spirit of science hacking.

One of those—this is one of my favourite sites on the Web—is Spacelog.org.

Spacelog: space exploration stories from the original transcripts

Has anyone seen Spacelog.org? Okay, yeah …one of the creators is sitting right back there: Norm. Hello Norm.

It’s wonderful. It does exactly what I was saying about using design—using a visualisation—to help tell a story.

What Spacelog is, is the transcripts of various NASA missions: Gemini, Mercury, Apollo missions. Those transcripts have been online for a long time. You can go to the NASA site and get them, but they’re just plainly presented. It’s just text, they’re not designed.

With Spacelog, these guys went off to a fort for a week and hacked on making a beautiful website to present this data, this information, and also to create like a linkable resource for every utterance that happened during an Apollo mission or a Gemini mission or a Mercury mission.

It’s absolutely fantastic. It’s ridiculously addictive. When I first saw this, I was like, “Oh I’ll just click through for five minutes”, and half an hour later, I was still just clicking through.

I thought it really showed how design can be so powerful. There wasn’t anything new on Spacelog. All the data existed already, but by putting it into this beautifully designed website, it came alive: it really came alive.

The ability to then link to any utterance from an astronaut was kind of cool. Nice, tweetable soundbites which led me to discover that Michael Collins is by far the coolest of all the Apollo astronauts. He’s my hero now.

So I like Spacelog. Spacelog is awesome.

Something else that isn’t directly related to Science Hack Day is—after Science Hack Day worked, it showed that it did work and if I could organise it, anybody could organise, because it’s really not my bag to be organising events—but Matt Patterson put together a History Hack Day in the same venue. He went to the Guardian, said “we want to do a History Hack Day”, taking lots of data to do with history and mashing it up and all that kind of stuff.

Frances and Tom

There was some wonderful stuff came out of that. Again with visualisations, this was taking Wikipedia edits of historical events. They’ve got timestamps and they’ve also got lat:long co-ordinates, and just visualising that over time. It’s a history of the world in a hundred edits, or it is basically just a hundred seconds of world history condensed down.

It’s again, beautiful, using design to tell that story.

I think there’s quite a large opportunity to mash up science and history. Some of my other favourite hacks I would say exist in that space of where science and history mash up together.

A site that would be right up there with Spacelog as one of my favourite sites on the internet would be Old Weather. Has anybody seen Old Weather? Okay.

Old Weather has this wonderful meeting of science and history. It’s made by the same guys who gave us Galaxy Zoo and Moon Zoo and all this stuff: the Zooniverse people. They’ve made these wonderful websites that allow people to participate in science. You can literally be a citizen scientist.

With Galaxy Zoo, you’re classifying galaxies. This is stuff that’s not that hard for human beings, because we look at a picture of a galaxy, we can see, oh it’s got spiral arms, or oh, it’s globular. That’s actually very hard for a computer, that kind of OCR is really hard.

So it’s allowing people to contribute to this classification, and not in some kind of mechanical turk, farmed out way. If you discover something on Galaxy Zoo and somebody writes a paper about it, you are one of the co-authors of that paper. It is true citizen science.

Anyway: Galaxy Zoo, awesome, fantastic All the sort of stuff they were doing, fantastic. But Old Weather, probably my favourite of all, because what Old Weather was doing was taking log books from the start of the twentieth century—from ships at the start of the twentieth century—and these log books are filled with observation. Dates, times, latitudes, longitudes; observations on the weather, barometric pressure. All written by human beings in longhand in these log books. Very, very hard for a computer to parse, but we can read it and we can hopefully make out what’s being said. So they built the site to allow people to come to the site and essentially transcribe these log books.

There’s a slight bit of gamification because you move up in rank on the ship the more you log. I’m just a cadet on this ship now, but I could become the lieutenant and then I could become the captain of the ship. But that’s not really the reason for doing it.

The reason for doing it is you’re helping science. You’re putting all this data—getting all this data out of these old log books—and making it machine readable, which is absolutely wonderful.

So Old Weather is right up there for me.

And it turns out the reason for doing this isn’t just, “Oh we need to digitise this stuff and it would be nice to have it on the Web.” This is climate data. But now it’s climate data that stretches back to the start of the twentieth century. So scientists doing climate modelling can now have much better models because they have data that stretches further back than their instruments, which is absolutely wonderful.

So that is definitely right up there as one of my favourite hacks.

I’ll stop geeking out about hacks now!

Ariel: I don’t think that’s the end of us geeking out about it.

Matt, what are your geeky, awesome hacks?

Matt: So, geeking out phase 2.

As I mentioned, I’m a particle physicist and in 2008 I started working on the BaBar experiment. This was an experiment that ran at SLAC International Lab on Stanford Campus. Over about ten years from ‘99 to about 2008 they collided matter and anti-matter, electrons and positrons, and collected a few petabytes of data to analyse.

The end goal was to actually try to understand the difference between matter and anti-matter and why the universe that we mostly see is made up of matter and not anti-matter. This table is matter. The stars, as far as we can tell, are matter and not anti-matter.

You may or may not have heard of some of the experiments going on at CERN at the LHC. This is a screenshot of the CMS experiment. I like this phrase from Ariel, these are space time smashers. These are colliding protons and overlapping their wave functions in space-time. You’re looking for the Higgs Boson and signs of super-symmetry. These are all very complicated analyses.

The analyses that I did at BaBar, even though it’s a smaller detector, it’s no less challenging. There’s numbers that you’re parsing through just streams of recorded information about these particles; the momentum, the energies, where they went. At the end of the day, you’re going to try to make a statement about how nature works.

Now the first level that you start to interact with the data are what I would call an event display. So what you’re seeing here is this 2D representation of this 3D mini-fireball, if you want, in the detector and where these particles went. All these layers of the detector are optimised to measure different things.

We don’t actually look at pictures like this until we’re doing some sort of diagnostic. Usually you look at a billion different collisions and you make some histogram, some plots and you try to summarise. Then you usually only use this for diagnostics. But looking at these helps you build up some intuition about what you’re trying to understand, not about just the physics but about the performance of the detector.

So when I was at Post Doc at Carnegie Mellon I started mucking around trying to sonify some of my data, trying to take my data, this multi-dimensional data-set and turn it into sound. I got some things that kind of half worked, but it was rattling around in my head.

Then when David Harris come to me and said, “Oh, there’s this Science Hack Day that’s going to be going on down the street, there might be some people that might want to work with you on this.” Because I was stuck. I do a lot of coding in C++ and Python and stuff, but I don’t know what’s the right language to do sonification or even visualisation a lot of this stuff. So he’s like, “Oh, I think there’s going to be some people that would like to help you on this, maybe learn about this and maybe you can get a group together.”

So we did.

I brought some BaBar data which was text files that I had to explain to them. I said, “Okay, this is where it’s going in the detector in this direction, and this is the energy, this is the velocity if you want that.” And over the course of the twenty four hours, we hacked together this very, very barely held together with duct tape and code that was able to produce sounds, based on the data.

We got it working at midnight. People had been hearing us in this room sequestered, like “You guys are serious!”


Everybody else is doing robots and these cool lights and we were all trying to understand this stuff. All of a sudden we started getting sounds. And there was people that came in, they were like, “Oh what is that?” I’m like, “Well, that’s the decay of a B-meson, and it’s decaying to these things.” And they’re like, “decay of a what?” I’m like, “Oh well, let me tell you about a B-meson now; now that I’ve hooked you with these cool sounds and stuff.”

There was a moment in the night actually where these people that were working with us that were from Yahoo! and physicists that weren’t particle physicists and designers that were… I’d explain stuff to them, and at some point in the middle of the night they started talking like particle physicists. They were like, “Well, what shall we do with particle ID?” which is this very, very jargony term in our field, you know. “What should a muon sound like?” “What should a pion sound like?” “Well this is cos data, so if we turn it into X and Y, how do we…”

Particle Windchime team

And it was amazing, because these people were not particle physicists, but if I had any of my collaboration walk in, they would’ve thought that they were trying to do a real analysis. And it was just fantastic.

So again, we had this website that was just held together by bleeding edge code. We wanted something live that people could map energy onto volume, and momentum onto timbre, and energy on some duration of the notes; make this mapping from these parameters that we were measuring and doing physics analysis to some sort of aural sonic quality.

We had something that just barely worked, but it wasn’t completely live. But we were able to demonstrate these sounds.

The fascinating thing was I started as me, because I was trained, I could start to hear differences in these particle decays. So this B-meson actually sounds very different than a …what’s called a light quark jet, and it doesn’t matter what that is, but know that I can hear these things. I started to realise, “God, you could start to use this to really develop an intuition for your data that maybe you didn’t have before!”

So because we’ve got it here, I’m going to play a little twenty second snippet of what a B decay sounds like, at least according to the mapping that I chose.

Did anybody hear that? Is that going through out there? No. Microphone check. You want to do that there?

So again the idea was that these things are playing the detector.

As they pass through the detector, it’s like the wind through a wind chime; they’re playing parts of the detector and you get to choose what they sound like.

Some particles move faster than others. Some of them are really slow. If you stretch out the time into nanoseconds or picoseconds, you get to hear them.

What was nice for me is that I could use this now. I could sit down and talk with people about the tools that we were using, kind of bootstrap this idea. Now I could start to develop a little visual aid.

So in my spare time I came out with this app. You can download it from my website. There’s a little control panel that allows you to choose what mappings you have. It’s written in mostly Processing. Whether or not it works today as opposed to six months ago I can’t guarantee.

This was one of my favourite hacks because it was very personable and again it was very inspiring to work with people that were interested in science. I feel like I kind of infected them with a little bit of knowledge.

Now I participated in the next Science Hack Day which was just last October, I believe, and I brought… November, and I brought some data from the LHC and we did a hack and some visualisations. And it was really cool. People liked working with fresh hot-off-the-presses data from the LHC.

But for me what was very interesting as a scientist—and trying to get some feedback also out of this—was this person did what they called the Beard Recognition Hack.

They took this little USB microscope and as you run it over your face, you get this image of whether or not you have little stubble (and I should just make mention that this girl that’s using it, that’s not a screenshot of what she has. These are mixed up. It’s not …I don’t know who she is, but I just want to let you know, hers was actually registering that it’s not beardy.)

What was neat was I could look at this code that was posted on GitHub, and I was like, “Oh there’s actually some really simple Python pattern recognition that just looks at contrast, and so it can identify lines.”

Now why that’s interesting to me is that when we’re teaching students, we use these cloud chambers that use isopropyl alcohol and form a very low, thin layer where it condenses. If you have radioactive particles that go through—like in the upper right there—you get these tracks where the isopropyl alcohol condenses along the track.

But it’s just something you watch, and if you let it sit there and you don’t put a radioactive element in it, every minute or two you actually get these muons that are produced by cosmic rays high up in the atmosphere. But it only happens every minute or so, and there’s no real way for data logging for this type of little mini-experiment.

So just by seeing this, I’m like, “God, could we use a webcam and then use this very simple software to do contrast recognition for whether these tracks are and actually use this to record and maybe do a project where students could build something like this from scratch, and then measure cosmic ray flux from the upper atmosphere.”

I’m a research scientist right now at Northern Illinois University and in the fall I’m going to be starting a gig as a Professor at Sienna College in upstate New York. I’ve applied for funding to try to get something like this together: put together a website that shows people how to build their own and everything.

But the point is that I would not have really thought about this idea unless I’d been going to these Hack Days. I think it’s real interesting the amount of information we have online and in blogs and posts, but face-to-face interaction is just a whole other level.

Again, as a scientist, I’m taking time out of my research to do this and I think outreach is incredibly important. It’s one of the most important things we can do. It was really this prime example of where there was this feedback from these Hack Day communities.

I think that’s where I’m going to end for now and let Ariel, and just emphasise, for scientists, I think these Hack Days that these guys are putting together can be a real game-changer in exploring these other communities that as scientists we don’t always have access to.

Ariel: I just think it’s really bragworthy to say that a Beard Detecting Hack inspired cosmic ray detection. It’s unexpected, which is awesome.

Atually I guess a lot of these things are related to my favourite science hacks. My favourite kind of science hacks really tap into invisibility. This is really because of the idea that ninety five per cent of everything is invisible. And when I say ninety five per cent of everything is invisible, it’s because when you look at all of the matter and all of the energy in the entire universe, seventy four percent is dark energy, twenty two per cent is dark matter, less than five per cent is all visible matter.

If you take out intergalactic gas, which—how often do we look at that? Not that often, it’s up in the pretty NASA pictures—the rest, all the stars in the universe, all the planets, everything in this room, everything on this planet makes up less than half of a per cent in the universe.

We are very much the etcetera in the universe. There’s all this invisible stuff around us all the time.

Dark Matter is really some of the coolest invisible stuff, I think. Dark Matter is really, essentially when you look at galaxies and how they’re held together, there’s not enough matter that accounts for the amount of gravity that’s needed to really hold us all together. The placeholder name for that is dark matter. All these weakly interacting particles that we can’t easily detect that are holding us all together, and it’s kind of in this globular form that you can see here.

It’s really great because we have this invisible thing that’s holding us together. It’s not actually the power of love that’s holding us together, but it’s the power of Dark Matter.

And so in a lot of ways this is a very friendly universe, we have this lovely adorable friend called Dark Matter that’s keeping us all together and that’s awesome.

But there’s also the opposite fact. We have a very evil sort of thing in the universe called Dark Energy. Dark Energy is actually trying to push us all apart. Not necessarily on the atomic level but we see it more with galaxies that are distant; they’re being pushed further and further apart, and so when we look in the universe and we see that we’re expanding, we’re actually expanding way faster than scientists think we should be expanding. We call that Dark Energy.

So absolutely ninety five per cent of everything is invisible. And hacks that tap into invisibility, to me, are really exciting and really weird, like this one.

This is a hack called Animal Superpowers. It wasn’t created at a Science Hack Day but it’s really cool.

Essentially the idea is that you wear a helmet and a couple of gloves and you navigate the Earth beneath you. You can see the Earth as seen from the perspective of an ant. You get animal superpowers by acting like you’re an ant for a day and actually getting this really magnified view of the Earth, which is kind of cool.

But the sort of invisibility superpowers can sometimes make you look dorky, like that previous hack, and this one. This is a belt that vibrates every time you face north. If you were at Amber Case’s keynote the other day, she mentioned it. The idea with this is that you began to understand how to navigate a city more intuitively if you wear this for a few weeks, as opposed to visually.

The idea of tapping into invisibility as a superpower is really tapping into the idea of sense affordances. I think this touches on a little bit of the particle wind-chime as well. Different senses have different affordances and so sometimes our ears can hear something better than our eyes can see them.

Different senses can make things visible that were otherwise invisible to us. Some people actually experience this naturally through synaesthesia. Synaesthesia is essentially where you have different senses that are crossing their wires. Some people with synaesthesia report actually associating letters with different colours. Some people have reported that when they hear a really loud sound, they see a ripple across their vision, and other cool things like that.

Tapping into synaesthesia—this superpower that some of us have but not all of us have—a group of hackers at Science Hack Day created a really creepy hack called Syneseizure. I’ll just let you all react to that for a moment.

Science Hack Day SF

Syneseizure is a hack that came out of Science Hack Day in November. The idea was that they wanted to simulate what it was like to be synaesthetic. So they created this mask which I’ll walk though. It’s this really, really creepy mask, but it’s really awesome.

Science Hack Day / Photo courtesy of Brightworks School

Essentially what they did is they took a bunch of vibrating speakers and they attached it to someone’s head, I think twelve different vibrating speakers. Because it was a Hack Day, they only had twenty four hours to make a mask, so the only mask pattern that they could find in twenty four hours was an open mask pattern for a gimp mask. So they created this gimp mask. They sewed it themselves. They came here with practically nothing, and they sewed this gimp mask up with all the vibrating speakers.

Science Hack Day SF

They wired it all up to an arduino where the mouth should be—as you can see—and a webcam, with the idea being that any information that comes through the webcam, different parts of your face start vibrating. You can actually start feeling sight and feeling where parts of the room are darker and where parts of the room are lighter. And so you get to wear this really creepy mask and navigate around and try and feel where different parts of the room are.

It was just a lot of fun and it’s really cool to be able to tap into your different senses that way.

Similarly, there’s also a few hacks that tap into different things, maybe a little less creepy.

Someone wanted to create a font that was based on wind drag. They created a makeshift wind tunnel, and they recorded the wind drag of each of these letters. They wanted to make a font that was …all the letters had equal wind drag in them.

I don’t know why this would be useful necessarily, but if you want a typeface that has equal wind drag, this is what it looks like. They actually went through and recorded all these. This is what a typeface with equal wind drag looks like. Something you don’t normally see visible to you but now it is, so make use of it somehow.

There’s also this hack which was more … bio based.

What you’re actually seeing here is the extraction of strawberry DNA. But they’re extracting the strawberry DNA using all edible materials. They wanted to create a DNAquiri, so to speak, using all drinkable, edible materials, so that you could actually have a cocktail where you were drinking extracted DNA.

DNA / Photo courtesy of Matt Biddulph

Just for note, it was absolutely disgusting! It was really, really gross, and lots and lots of alcohol as you can expect.

What you’re actually seeing in this picture is these polymers are really long, so when you extract DNA, even though it’s really tiny, the strings essentially are so long that they all start globbing up together so you can visibly see it.

There’s been another panel that’s at South By—unfortunately I think it was right before ours—but it was talking about weather balloon payloads. Of course weather balloon payloads are becoming a lot more ubiquitous. They’re just really exciting because you get to see Earth from a site that you normally don’t see. Either you get to see the curvature of the Earth if you’re going thirty kilometres up.

grassroots mapping

In this project they were actually mapping the ground of the Earth, so they tried to do a grass roots aerial mapping project using these weather balloons and just a simple camera.


So if you’re kind of thinking about all these things and thinking “Wow, how could I make a synaesthesia mask where I can walk around in Austin all the time and freak people out?” or if you would just rather hack on your own science ideas, that might be less creepy, where can you start?

Jeremy, do you have any recommendations on what people can do today that could help them get started in science hacking?

Jeremy: Yeah. I’ll come at it from the Web side of things rather than the physical hardware side. And if you do any mash-ups and web development you’re probably familiar with all these already. But I think scientists certainly can benefit from knowing about these tools that are out there, available and free.

I was talking about data visualisation earlier and how important and how useful a tool that can be. There’s the Google Chart API. It started off fairly rudimentary, and now there’s quite a lot you can do with it. It’s nice.

Some articles have been written about. There’s documentation on the Google site, but there’s articles been written about how to use it from people like Brian Suda who wrote a whole book about designing with data.

I find it can be quite useful, especially if you’ve got twenty four hours to hack something together and you need to have graphs and charts and things. It’s pretty nice.

Another useful took for developers is something from Yahoo! called YQL. Now it is from Yahoo! so it could be switched off tomorrow for all we know.

It’s like a meta API. This is like an API for APIs. There’s lots of websites out there have APIs, but then you’ve got to learn the API of each website. You’ve got to learn the Flickr API and you’ve got to learn the Amazon API, now you’ve got to learn the Guardian API or whatever. This tries to even the playing field by allowing you to use one syntax to mash up data from all these different APIs.

The syntax it uses is essentially SQL. So if you’re familiar with querying databases, it’s like that, except that now instead of querying databases, you’re querying the Web. You select from Flickr where tag = trending topic on Twitter. Mashing stuff up together.

It’s just quite useful. At Science Hack Day London we had some lightning talks at the start, partly from scientists and partly from Web people. Christian Heilmann, who was working at Yahoo! at the time, gave a talk about YQL; just demo’d it, showed what you could do with it. There was a whole bunch of different scientists in the room who were like, “Wow, we had no idea this existed. And all these plans for projects that we thought would take months, we could maybe do really quickly using these tools.”

So I find that quite useful.

And then finally just one that I think in general is so useful to any kind of mash up and development is the fact that we have GitHub now.

It can seem overwhelming: sometimes you have an idea but you can’t finish it or you can’t bring it to fruition. Throw it up there on GitHub and allow other people to take it and fork it and run with it and feed stuff back to you.

GitHub’s been great for collaboration in general, and can also be really good for finishing those hacks you started the Hack Day but never quite get around to finishing.

So those are just a few that I find pretty useful.

Ariel: And Matt, what are your recommendations for what people should be doing today from your perspective?

Matt: What people could be doing?

Ariel: Could be doing.

Matt: Could be doing.

I think that there is a tremendous benefit from coming to places like South By South West, the Science Hack Days, seeing what people are doing, getting really inspired, going and reading, following the science podcasts and stuff. But from interacting with everybody, I think there’s another level that can be gone, and I think that there’s nothing wrong with getting your hands dusty (I’m going to use—again Ariel came up with this line and I think it’s right).

I think we all have the capability of learning a lot more than we think we can, or maybe a lot more than we know now. I think that we can all have that capability: actually get some of the old text books if we want or old physics books, statistics especially, and go through them and try to really learn what these things are.

I think the people that I worked with at the Science Hack Days, like at this most recent one in San Francisco with the LHC data, we started actually going through the equations that Newton told us relates energy, momentum and mass. Then we went to the equations that Einstein taught us relate energy, momentum and mass. People are perfectly capable of learning these things. I think when you really learn it and when you grok it and when you sit down for an hour a week even, it changes how you view the world. It’s changed how I see even just casual talks.

I think that there’s so much available on the Web with Khan Academy, MIT is putting lectures online from its introductory physics and statistics course. Stanford has got a YouTube channel with lectures from its physics and statistics course. It changes how you view the world when you really sit down and go through it. It sounds kind of stodgy and boring, but it’s not when you go out into the world or you go to a conference like this and you look at things differently.

Early this morning, they had an asteroid panel, and Phil Plait or Platt?

Ariel Plait.

Matt: Plait, Bad Astronomer, is talking about if he had all the planets aligned, it would be only one fiftieth the gravitational pull of the moon. I’m thinking, “Wait, is that right?” And I’m thinking, this is a perfect problem I could give my students. It’s very simple. It’s only got a couple of equations, you can look up the information on Wikipedia.

When you do something like that, you have this tremendous self of satisfaction. I’m starting to really understand the universe. I think that these events are great inspiration, but I think there is something we can go and take it to the next level and again, not just physics, but statistics. I think when you understand statistics—which is so important in my analysis—it kind of changes how you view the culture and the way the media relates stuff to you.

So again it sounds kind of boring, but with the amount of stuff online that you can learn from, I think we’re at a different level. It’s much easier and much maybe less boring to learn this stuff.

Ariel: Thanks. So my recommendations for people are really to go to Hack Days or organise Hack Days, because they are pure joy. Like this guy with the Nabaztag, which is awesome. Poor Nabaztags don’t work any more that much, but I love them.

Hack Days are really awesome. For me it’s really about being a spark for future collaborations or future ideas or future things to come out of. They’re really, really just meant to have fun and have really unexpected things come out of them, …like having cosmic ray detection come out of a Beard Detector Hack is the weirdest thing I’ve heard, possibly weirder than the Syneseizure mask.

But it’s all about this unexpected sort of stuff. Nowadays I hear a lot of people talking about Hackathons and Codathons as these things where you’re going to create this well-polished solution for your city or other things like that. And while that’s great, to me, Hack Days aren’t really about creating products. It’s not about that.

If you want to make a hack that detects when you need to shave, go for it. It shouldn’t have to end up being a product. It should just be something awesome that you’re really excited about and you don’t know where it’s going and that doesn’t matter. That’s what Hack Days are really for.

So if you haven’t been to a Hack Day, I really encourage you to do so. Specifically with Science Hack Day, it’s now become a global thing, thankfully, thanks to some help from the Sloan Foundation. Science Hack Day is actually happening all over the world.

The next one I think is in Nairobi in April. Then in May there’s one in Chicago. There’s going to be one in Iceland in June, I think. They’re happening all over.

But if they’re not happening in your town, we’ve actually open-sourced instructions for how to create a Science Hack Day in your city. So if you go to ScienceHackDay.com, you can actually figure out how to make one happen in your city, which I definitely encourage.

Mostly it’s just about getting excited. Even if you don’t go to a Science Hack Day, do this on your own weekend; just get excited and make stuff with friends. It’s just really awesome. You don’t need to be a developer and you don’t need to be a scientist. You can be anyone and just make stuff. All you have to have really is just this amazing passion for, “Oh my God, that’s so creepy and awesome” like I have with so many things.

So that’s really about it. So actually, let’s see. We have maybe about fifteen minutes or so for questions, so if you guys want to start thinking about questions and coming up to the mic, feel free to start doing so now.

We’re happy to take questions. Do keep them short and sweet. We don’t necessarily need to know your life story because we will be here afterwards and we’re happy to talk to you about that. So if you have any problems or emotional uncertainties, we can talk to you about that after the panel. We’ll be here all day, folks.

But in the meantime, if you have short and sweet questions, please feel free to come up to the mic and we’re happy to help.

Audience: That was awesome, thank you guys.

I’m just curious to hear just from the experiences you’ve had if any of you have maybe some quick stories or examples of where you’ve seen youth getting involved, youth being impacted. Just thinking about my own kids and middle school age kids and even younger, but just getting kids involved with seeing science in a new way. Just curious from your experiences if you have some insight on that to share some ideas for things to consider with getting younger kids kind of excited about some of this stuff you’re talking about?

Jeremy: Well I do have something.

This is not so much a bottom-up hack, more of a top-down project, but one of the other lightning talks at the start of the Science Hack Day in London was from some people that are working with the Wellcome Trust.

The Wellcome Trust is like, I guess, a UK equivalent of the Sloan Foundation: non-profit, dedicated to furthering science and understanding. They’re working on this project that’s in parallel with the Olympics, to get young kids to kind of understand the science of exercise and sport and all that stuff.

So again, talking about data and physical objects, this is going the other way. This is about taking data from sensors and getting it onto the Web. I’m not sure at what stage this project is right now, but the idea was they would have sensors for kids.

Now it used to be that getting sensors on a human body to measure things like heart rate and metabolism and all this stuff, it was expensive and it was bulky, but thanks to Moore’s Law and all sorts of things, they’re getting really, really small and really, really cheap.

So they were demoing this thing that was like a bouncing rubber ball. It was really durable and you could bounce it round. The kids could run around with that, and then hopefully see what to do with that data. They were looking for ideas: what shall we do with this data? If we’re going to collect all this wonderful data with these sensors, what can we do with it?

And there were some issues around privacy, obviously, because we’re dealing with children here, but it was a really interesting project. I’ll see if I can find a URL to it and point it your way. That’s the one I can think of off the top of my head about involving kids with science.

Ariel: Yeah, at Science Hack Day, San Francisco, we had a bunch of kids show up and so far, kids are welcome to come, but mostly it’s adults who come, just because a lot of my work focus is on getting people who are otherwise forgotten about, or forgotten to the science industry, which happens to be adults who chose different careers.

But a bunch of kids ended up coming and they created a video game. Over the course of the weekend, someone was actually working on some video game code. He worked with them over the weekend, and by the end of the weekend, they had coded this Pikachu video game, which was really awesome.

With them, the experience seemed to be less about “Look at this weird, crazy stuff” and “Wow, look what I was able to create: I was able to create this Pikachu video game over the weekend and learned code” which was really valuable for them.

Matt: One other thing I’ll mention. I’m not sure if you’ve heard about it, is the Google Science Fair Project.

So if you go to Google and Google Science Fair, last year they did this and they had kids from all over the country compete. You’ve got these web forms that they fill out where they have to have a hypothesis and their procedure in the end, and then winners got brought out to the Google campus and they picked the winners there.

It was really neat because it helps the kids codify their questions and their problems in a real scientific method kind of way. So I think that’s a real positive thing they’re doing and can spread all over the country.

Jeremy: Just one last thing I want to say on the subject of kids and hacking around with science.

I find it really interesting, a lot of time, a lot of stuff that we see is being really cool, this website, this thing on a screen taking this data… Kids are like, “Oh, whatever. Screens.”

Physical things …they’re blown away by it. This printed out piece of paper that has got data from the web is awesome.

So I find paper, hardware, physical things; they seem to respond to really more than we do.

Audience: Actually, mine’s a follow-up on that.

My name is Steve Amos. I’m doing a lot of work right now with kids in that regard. And you’re right: how do we connect that aspect of kids as citizen scientists, so to speak, and hack and I’m wondering, even in this room, there’s some incredible talent, incredible knowledge. Is there within the site that you mention, a way that people can share so that we may reach out say, “Hey, we’re trying to do some work.” It could be in Detroit or it could be in London or it could be in Nairobi, wherever it is, and be able to connect, so that maybe there’s some talent that says “Hey, here’s some ideas that we’ve had that we’d like to help connect with those teachers who have kids in those local areas.”

If just anybody, besides the panel, that would have a thought on that, just please let me know. My hashtag is #grsteam.

Ariel: Awesome.

So actually, if you go to ScienceHackDay.com there is actually a link to a Wiki and on that Wiki are all the cities that are planning on doing Science Hack Days that haven’t yet. They list their contact information, and they are all looking for help I would say, from everyone.

It really is like a team effort because it’s not enough to just get one community involved in this. When we’re planning, we’re often trying to get all different types of people from all different types of backgrounds to come. So all these cities; each city is responsible for organising their own.

So if you go on there, there’s I think, oh gosh, maybe twenty five different cities listed right now who are all planning on the Wiki. So reaching out to them would be great.

Matt: Another project that I learned about—actually through another event that Ariel had planned—is Friends of the Future.

If you go to Scientific American, they were organising this thousand scientists in a thousand days, and I think …if you just poke around Google probably you’ll find it.

They were trying to pair up scientists with schools and school districts where you would either have a scientist come and talk about their work or connect through a Skype or Google Hangout connection.

I get the impression that they almost have too many more scientists, because I signed up for it about a year ago and I never got called to interact with anyone. So they might be looking for school …but I think that that’s a real positive programme, not just, even if you can’t physically get someone there, the students can interact and ask questions.

So yeah, a thousand scientists in a thousand days I believe is what it’s called.

Jeremy: I just want to say …the internet’s great and it’s able to connect people geographical distances, which is wonderful. But there’s really nothing quite like people getting together in the same room, in the same place.

One of the nice things about Science Hack Days—or any of these kind of events that get people together in the same room—is they realise, “Oh, I’m not alone.”

The kind of inspiration you get from going to a conference or some other kind of event where you realise, “Ah, my people, I’m not toiling alone.”

And this isn’t just Hack Days, it could be anything. If you’re a web developer working on something, you feel like you’re isolated, but getting together with other web developers in your town is wonderful.

Some friends of mine put together a site called Django People. You could sign up and say, “I do Django programming. I live here. These are some sites I built.” And as a result of that, there ended up being a Django meetup in San Diego, because all these people who didn’t realise they lived so close together, who were all doing Django, were able to get together in real life.

So there really is something for getting people in the same room. One of the nice things about Science Hacks is if you can get this mixture of web developers, teachers, scientists—the more the merrier—in the same physical space. A lot more seems to get done than you get with emails, wikis and stuff like that.

Audience: Okay, there seems to be a clear affinity between the kind of stuff you’re talking about with the Science Hack Days and the whole DIY maker movement.

They’ve had a lot of success in reaching out to children and doing the sort of grass-roots kind of thing in the community. I know that there was Maker Faire in Brighton last year. I went to the World Maker Faire in New York, there’s a lot of energy around that.

Has there been any thought of maybe trying to piggy-back on that? Running your event, running a Science Hack Day event in close conjunction with something like a Makers Event so that you could get a mash-up of those two movements to see if maybe it gets even more energy behind what you’re doing?

Jeremy: They show up anyway, believe me, which is great.

There was a certain amount of hardware hacking at the London one. There was a lot more I think in the Palo Alto Hack Day and I think maybe more again at the second one.

Ariel: Yeah. I mean I’ll just say, running Science Hack Day adjacent to events, yeah it can be great, and I think some cities are considering that. I know that it’s not Maker Faire, but in Iceland, there’s PopTag is going to happen there and they’re going to see if they can run Science Hack Day adjacent to that.

It is something where there’s a lot of affinity. There is a slight difference though, in that Maker Faire is often about showing stuff that you’ve already created, and Science Hack Day is all about what can you make in twenty four hours.

Audience: And I think that may be the kind of differentiation you need between Science Hack Day and Maker. Say, “Here’s the cool stuff that’ll inspire you. Now here’s a chance for you to make something yourself.”

Ariel: Right, or even vice-versa: have a Science Hack Day and have the best hacks present at a Maker Faire.

Those things are being considered. But yeah, I think it’s all fair game. I think as long as you’re not asking people to focus on too many different types of things, as far as a BarCamp and a Hack Day. Many people try and mash those up and that ends up not being super well because you’re asking people too many things.

But yeah, having things adjacent to events definitely helps as far as just getting different communities to attend an event.

Jeremy: And actually I’m thinking about in September in Brighton, there’s a whole bunch of web-related and art-related events going on, so we’ve turned September into this Brighton Digital Festival. I’m definitely looking at like trying to find a weekend there where I could fit in a Science Hack Day; do a Science Hack Day Brighton. And there will be a Maker Faire towards the start of the month, so absolutely sort of glomming these events together can be good. A rising tide raises all boats.

Audience: Hi. I’ve gone to some of these Hackathon events, more in a coding space, and I found that it’s really hard to make something that actually works in that constrained amount of time.

I’m wondering if there’s any kind of concerted effort to pick up someone else’s project and carry it forward and try to finish it. Has that happened in these events?

Jeremy: Somebody did actually just launch a site recently to have an event, I forget …it was something like, “Finish It!” Literally a weekend of hackers where you’re not allowed to start any new hacks. You just have to finish the hacks you started at other ones.

But it’s an absolutely fair point, because people can be very ambitious in what they’re trying to do. And you don’t pull it off in twenty four hours, and that’s something you learn as you go along, as “Oh, if I’d just kept it focused, I probably could’ve finished it.”

But again, I would say things like GitHub can be great if it’s software, where you can just throw it up there and say, “Please, somebody take this, finish it.”

Matt: I can give you some of my own experience.

The wind chime, like I said, we just barely had sound going and I’m like, “God, I’d really like to see visual cues with the sound.”

And so it was about, you know, six, nine months of me just working in my spare time, because I’ve got all this other work that I’ve got to get done. And so this was really hard. I got something together that you can download.

Then at this last Hack Day, I was like, “Oh we’ve got something done, I’m going to be really ambitious. We’re going to take LHC data and I’m going to teach everybody how to analyse it in the space of a few hours and then they’re going to hack something together and I’m going to post this stuff on GitHub beforehand.”

And at ten o’clock at night—I mean Ariel knows—I came and I was talking like, “I’m so depressed that we didn’t do anything. I failed. I failed everybody.”

Then I got this inspiration. I had this three-hour burst of creativity and we got something going. We got something hacked together and you can actually see these things in accumulating data.

But for me, it was actually really important to realise we got something together. I actually shouldn’t take this any further. It was the act of building something, seeing how far we could get, and then that was really as much as we could do, was as important as the previous Hack Day where I got something that I was able to carry forward.

I think sometimes it’s actually good to learn what to let go, that it was a learning experience, that it was on its own. Because I do think—I mean, we talked about this a lot—in twenty four hours there’s a limited amount you can do.

So those are my two experiences at both of those; something that was worth carrying forward and then something that was like, “Okay, we got something; going to put it aside for now and let it be.”

Ariel: So we’ve got just about four minutes left, so we’re going to try and take these last two questions really quickly.

Audience: Hi. Thank you. Beautiful panel.

I love the idea that there are no special people. You can be whatever you want if you like what you must do. As Ariel doesn’t have a background in science but is working at NASA. That’s fantastic!

My question is, how to begin in science? What’s the initial point for people with no science background to create something scientific? Advices? Hack Days?

Ariel: Well we’ve discussed some of the things that we would recommend. Like, if you are on the coding side, GitHub is great and just reading up on science in general.

With me, my relation is really just watching science documentaries on the weekend because I don’t really have a life and that’s what I do. And so, surprisingly, I learn quite a bit from those and it’s great.

But as far as like going to Hack Days and organising one, really, all you have to do is be an organised person. If you’ve got that, then you’ve got everything going for you.

I think it’s really just saying, “hey”,raising your hand and saying, “I’m really excited about this stuff, is anyone else?” And seeing what goes from there.

It’s a long trip to actually doing different things but surprisingly just meeting people actually goes a long way.

Matt: And I think your SpaceHack.org is a nice portal, actually, into ways that citizen scientists …if you want to say…

Ariel: Yeah, SpaceHack.org is just a directory of ways to participate in space exploration. So it’s space specific, but it catalogues all these different ways in which anyone with or without a science background can participate.

Jeremy: Just to say that it sounds like a flippant answer to say that watching science documentaries is how you get into science, but actually, I think it’s really important to value the storytellers who can get people excited about science. Historically people like Carl Sagan or Richard Feynman, James Burke. Now we’ve got Brian Cox. These people who do make it accessible and make it exciting. More of those kind of people; it’s wonderful.

Audience: Hi. So, as a designer who’s into scientist things …but has always been intimidated about going to any sort of Hackathon or anything like that, Ariel, have you found any way of convincing other designers to go with you? Or Jeremy mentioned there’s always trouble getting designers there?

Ariel: Yeah, it can be intimidating, and I’m really—at least with Science Hack Day—I’m really, really trying to fight that.

With San Francisco we had, I think, thirty three per cent developers, twenty per cent scientists, twenty per cent designers and the rest were a mixed bag of anything form a lawyer to a roboticist. But it is intimidating. And I really hate that. And I really hate the people who make it seem like if you’re not a developer, if you don’t know how to code, then you’re behind; too bad, you need to go back to school.

I think the best thing you can do is talk to …I guess, go to a Hackathon, maybe go with some friends and prove people wrong.

Maybe a lot of times actually it’s the fact that Hackathons would like to have designers show up, but they’re not doing a great job of reaching out to them. So also just talking to organisers and asking if there’s any place for designers. They might actually say, “Yeah, we’re actually looking for them; we don’t know any.”

There’s a really big problem with outreach in that regard. But yeah, I really hate anyone who makes it feel intimidating to join science, to join being a coder. It’s crap, because you can absolutely create anything you want and you don’t need to have specific skills to do so.

So on that note, I will thank you all for coming and getting excited with us.

Get Excited and Make Things with Science on Huffduffer

Saturday, July 30th, 2011

Hot topics, transcribed

As ever, I had a lot of fun moderating the hot topics panel at this year’s Web Directions @media in London. Thanks to all of you who left questions on my blog post.

I had a great line-up of panelists:

We discussed publishing, mobile, browsers, clients and much much more. The audio is available for your huffduffing pleasure and I’ve had it transcribed. I’ve published the transcription over in the articles section of this site, so if you prefer reading to listening, I direct your attention to:

Web Directions @media 2011 Hot Topics Panel

Web Directions @media 2011: Jeremy Keith — Panel: Hot Topics on Huffduffer

Wednesday, July 27th, 2011

Web Directions @media 2011 Hot Topics Panel

A panel I moderated at Web Directions @media in London in May 2011.

Jeremy: Okay, welcome back everyone. Thank you all for joining me for the final talk of the day. This is the Hot Topics Panel.

Hands up how many of you have been to an @media before? Okay, so most of you know the drill, that I assemble a team of people here and we talk bollocks for an hour, and it’s good fun.

I have solicited questions ahead of time on my blog; I actually opened up comments. I know! …and I got some questions from that, so I’ve collated a few of those. If you have been asking on Twitter, that’s good. If you’ve handed me scraps of paper, that’s even better; thank you very much.

At this point, it’s too late to start tweeting questions to me because I’m not going to sit here and check Twitter while I’m conducting a conversation. However, I will be opening this up to you guys, because it is all about you. We need to know what are the hot topics on your mind; what do you want to know about, and I think we’ve assembled a pretty good team here to be able to answer those questions.

I have two people from the design track and two people from the development track, so it’s an equal opportunities panel.

Furthest over there, we have Brian Suda who’s living in Reykjavik, Iceland, who is an informatician and speaking today on data visualisation. He’s also been signing his book out front which I highly recommend that you buy. I was honoured to be asked to write the foreword for the book, so that’s the best bit.

Brian: The easy bit.

Jeremy: The easy bit. It’s a great book. I highly recommend you check it out and very happy to have Brian here.

And I have Mr Bruce Lawson. The legendary, the infamous Mr Bruce Lawson, who works at Opera Software but mostly I would say he works for the web. He’s all about the open web and standards, man. I’m delighted to have him join me here.

And then here we have Relly Annett-Baker, who’s just finished speaking on content and history and everything; that was mind-blowing, it was wonderful. Relly and I used to be kind of neighbours when she was living down in Brighton, but alas, she’s moved a little further afield now, so it’s good to see her again. It’s great to have her here on the panel.

And finally, I have the one, the only Douglas fucking Crockford on this panel.

I’m sure you’ve all seen Chuck Norris facts, right? Have you seen Crockford facts? It exists. I’m not kidding. He has his own facts site all about him.

It is an honour to have him. The inventor of JSON—the discoverer of JSON, I would say—and all ‘round smart guy and author of JavaScript: The Good Parts.

Alright, so I have assembled some questions, like I say. I thought I’d kick off with some easy ones. What’s your favourite colour …in a hexadecimal value please? No, not quite that easy.

I’ve got some nice questions through my comments on my blog, from Nicole actually, Nicole Sullivan, who you will be seeing speaking tomorrow. She wanted to know—this is a nice easy one—“What’s the coolest thing you’ve seen done with CSS3?” But actually I’m going to broaden that and just say, what’s the coolest website you’ve seen recently? What’s the website you’ve seen recently that made you go “…ooohh, that’s cool!”

Who wants to be first? If you can’t think of one, I’ll dive in and lead the way.

Okay. Has anyone seen Space Log? It’s awesome. It’s basically taking the transcripts of the Apollo landings, putting them online in a beautifully designed way. The interaction is lovely. It was all built in a week in a dev fort. It’s wonderful. Hannah Donovan who’s speaking tomorrow is one of the people behind that. Absolutely great stuff. Totally addictive! I was just going to spend five minutes looking at it and half an hour later, I’m scrolling through again. Made me remember how great the web can be. And it was all about telling stories through data, through design.

Okay. That kind of thing. What have you seen lately?

Brian: I was going to say, one of the most interesting ones with CSS technology was the Nike website. As you scrolled down, the different pieces would spin at different parallax speeds.

Jeremy: I know the one you mean. I believe it’s not CSS only. I think there’s still JavaScript required to make that happen. And there was another one recently from the Stamen guys, that was using a similar technique, sort of vertical parallax stuff. Pretty neat.

Bruce, you got anything?

Bruce: Coolest CSS one I’ve seen is Lea Verou’s site—who spoke here earlier—because she’s got some kick-arse demonstrations on that.

Jeremy: Right, so she’s got the demos of the different sort of textures made with CSS3.

Brian: I’ve seen them

Jeremy: Yeah, it’s awesome, so do check out Lea’s site; it is awesome.

Bruce: Probably leaverou.me?

Brian: There’s some very nice tartan plaid in there.

Bruce: And the other cool site I’ve seen is one I used in my talk, which is JackDrawsAnything.com. There’s a six year old lad whose younger brother’s been in and out of hospital, so to raise money to the hospital to say thanks, he offered to draw anything you asked him to draw, for a donation. I had him draw a slide of DRM for my talk because I didn’t have an interstitial. He was aiming to raise £100, and he’s raised 20 grand, so that’s pretty cool. JackDrawsAnything.com, and his dad’s a developer.

Jeremy: It’s a bit like child labour, but still.

Bruce: It’s a lot like child labour, but it’s for a good cause, so we’ll not report it to the authorities or Esther Rantzen.

Relly: The thing that I love about that story is that he opened it up for donations, I saw an interview about it, he’s just having a book published; he’s got a book deal around it as well to raise more funds basically and put all the pictures, collate all of the pictures. He opened it up saying, ‘hey, send me requests’. Within two weeks they had to close it because he had over a thousand requests. The kid only …he’s like at school, he’s got holidays, so at the moment he’s done around 620 of them. They estimate he’ll finish by the end of the summer holidays. He’s doing about five a day at this point, bless him.

Jeremy: Like a very specialised Mechanical Turk.

Relly: Very much so. And the pictures are brilliant, really good.

On that note, one of the things that I’ve really liked recently is irkafirka, which is …you can re-tweet something to the irkafirka account, and they pick a tweet each day to draw a picture of it and give imaginary context. A similar thing was Exploding Dog, where you used to be able to send in text messages and things. But irkafirka do one every day, and they’re really, really funny. Anything like that really tickles me where they take something and re-mould that content and turn it into something new.

Jeremy: There’s a bunch of guys doing that but they’re creating a cappella harmony versions of tweets. They pick random tweets and then perform a cappella harmonies of that tweet.

Relly: See? The web is fucking amazing!

Jeremy: What have you got, Doug? Beat that.

Douglas: I saw a website that has pictures of cats and they’re doing funny things and then there’s a caption and it’s mis-spelled and it’s really funny ‘cos cats can’t spell.

Jeremy: You are so ahead of the curve!

Bruce: I haven’t seen that. Is there a URL?

Relly: Have you got a link?

Jeremy: Okay, now you’ve got some sites to visit.

Douglas: It’s all about content.

Jeremy: Douglas. You kind of dodged the question I had for you earlier after the talk…

Well my question was kind of two part and half of it was about how do we kill IE6, but the other half was cultural resistance to new ways of programming, and I actually had a question, this is from Nadine—she left a comment on the blog. Now she was talking specifically about something like Ruby on Rails—a new framework comes along—but this applies equally to Node JS. It’s something else for developers to figure out. All of a sudden we spent years mastering SQL and now this comes along and the question is, when do frameworks enable and when do they disable the developer? In other words, all this knowledge that we’ve built up over the years, now we have to ditch and learn a whole new way of doing things.

Douglas: That’s always been the way, so since the beginning of programming there’s been resistance to advances in software development. The biggest obstacle in progressing software is the programmers, and that’s why it took a generation to move from Assembly language to Fortran. It took another generation to move away from the GOTO statement, and another generation to go Object Oriented, because there are these guys who have learned to do things and figure they’ve learned enough.

Jeremy: They get comfortable.

Douglas: And we have to wait for them to retire before we get critical mass on the next innovation. So hardware—Moore’s Law—happens in two year cycles; software happens in twenty year cycles, and it’s because of this. It’s not because we can’t come up with the ideas; it’s because there’s so much resistance among our own practitioners to moving forward.

Jeremy: We’ve actually been here before with JavaScript on the client side. Because ten years ago you asked anybody what JavaScript was and it was this horrible language, it was buggy, it was inaccessible.

Douglas: Which was all true. But it turned out that there was a good language hidden inside of it. So the thing that’s easier than trying to get everybody to go Fortran is that we don’t have to get everybody to go forward. It’s one site at a time, perhaps even one project at a time. And so we can do this incrementally. We don’t have to push everybody at once.

Jeremy: I guess it’s kind of Darwinian as well because the people who can change will adapt and will survive, and the people who don’t…

Douglas: Yes, so we’ll grow with the smart, young people and you know, the stupid old people are useless, so we won’t worry about them.

Jeremy: I guess that question speaks to a larger topic, and another comment from Brad Koehler.

Bruce, I wonder how you handle this? Brad says that the industry seems to be moving so fast at the minute, we seem to be sprinting just to keep up. HTML5, CSS3, responsive design, boilerplates popping up left, right and centre; tons of mobile devices to look at and try and test on. How do you keep up to date without going insane?

Bruce: That’s a great question. I’m paid to do it full time. Sometimes I go away for a fortnight’s holiday and I come back and I think “Shit, the world’s just moved around a little bit.”

I’ve no idea. What I do is follow blogs from people whose opinion I trust.

Jeremy: I speak to people these days who say they don’t even have time for that; that 140 characters is about as much as they can handle.

Bruce: Yeah, but you can’t get any real information in 140 characters.

I must admit I don’t use my RSS feed any more. I wait for people I know to tweet something that’s a link to a blog or something, another resource on the web, and that’s what I do, so I’ve got stuff filtered by my peers or people I trust.

Jeremy: So Twitter acts like a filter for you?

Bruce: Yes, but you can’t say anything really worth saying in 140 characters. It’s only ephemera.

Jeremy: But if somebody links to something, or if four or five people link to something, you know it’s something you should probably be checking out?

Bruce: Yes, but generally I pick up my mobile phone and look under R and I call Remy Sharp and he knows the answer.

Jeremy: Always good. Remy’s always good for explaining stuff.

Bruce: I’ll tweet his phone number later and you can all do it.

Jeremy: It’s awesome. Remy is the king of the lazy web. If there’s something I’d love to see built or some demo or something, I just make sure I’m in the pub with Remy, and casually let it slip while he’s in earshot and then say something like “But nobody’d be able to build that.” And then he’ll build it.

Bruce: Actually, you say that; I spent a morning trying with my embarrassingly rudimentary JavaScript on how to do something, tweeted, “I’ve got no idea how to do this,” and Remy tweeted the fucking script to me. With room at the end to say “(in 140 characters).”

So it’s not true that there’s nothing worth that you can do in 140 characters, but it is true that if you want to give Remy a kicking for being a smartarse, no jury will convict.

Jeremy: What about you, Brian? How do you keep up? Because it seems like you’ve been specialising lately, what with the book and everything—with data visualisation—but I know that you’re interests are a lot broader.

Brian: I do a lot of reading, I mean I’ve got several hundred things in the RSS reader. Partly because I love RSS feeds because I don’t have to try and remember the two or three hundred websites. When they publish, they publish.

But also—getting back to your question—you don’t necessarily need to be on top of everything. I mean it’s great to be, for you personally for your advancement in the industry, but at the end of the day, your HTML 4 site isn’t going to stop working. It’s great to know these things, but it’s not as mission critical as people might think. I seriously doubt huge domains are going to …they need to move much slower; they have a much wider browser base. They’re not going to be jumping on these very cutting edge things very quickly.

Jeremy: I guess it’s the side of standards, web standards, that people forget; it’s not necessarily about the new shiny stuff and making that work in the latest browsers. It’s ensuring the site you built ten years ago is still going to work in a browser release ten years from now.

You say you read a lot. Do you mean physical books too?

Brian: I do. I have…

Jeremy: How’s that working out for you?

Brian: Quite difficult. I mean I’m quite …Amazon does a really good job. They finally do free shipping to Iceland so I’ve been buying quite a lot.

Jeremy: You no longer have to get everything delivered to…

Brian: Exactly. Sent to somebody else’s house and mule it all the way up to London.

Jeremy: Actually, on the subject of the physical artefacts, the digital artefacts; you have a book, a great book with an awesome foreword. People buy the physical book and maybe a couple of months later, a digital version might be released, whatever format; ePub, PDF, I don’t know. Do people feel entitled to the digital version because they have a copy of the physical version?

Brian: People I think do. I mean me as a consumer, I understand if I bought this physical CD, I can rip it into iTunes and get it in digital form. In the US that was completely legal; in the UK it just became legal recently. I think a lot of people kind of have the same thing. I bought the physical book, I paid for it, but I want to also have it on my Kindle. But at the moment, those are two …sometimes it’s more expensive to have it on the Kindle, there’s two different prices.

Jeremy: Don’t get started with the pricing model!

Brian: So as an author, that’s great for me; I get sale revenue on both. From a consumer, I can completely see where people are coming from, but also as someone who creates as well, I know it takes a lot of energy. It’s not like ripping to an mp3. There’s a lot of work involved in laying it out, getting it set up for…

Relly: It’s a whole different process.

Brian: Yes, but I don’t think that’s necessarily clearly articulated to the consumers.

Jeremy: I saw you nodding your head there, Bruce. Do you have first-hand knowledge of people expecting to have the electronic version?

Bruce: Well I know that there’s been 14,000 illegal downloads of our book from tosspot.ru or something. But Remy and I have already bought one yacht each on the proceeds, so we don’t need another.

No, we wrote the book because we wanted to write a book. We wanted to get invited to speak at things like this on the back of it. It was good for us.

Jeremy: I mean, if somebody downloads an electronic copy from a warez site, that’s probably not a lost sale.

Bruce: I’d rather that person coded the shit right because they’d read an illegal version of our book than coded shit wrong because they hadn’t been able to read the book, personally.

Jeremy: Fair enough.

You’ve kind of got all this ahead of you, Relly.

Relly: Yes. Apparently I’m doing a book! Well, I am doing a book. It’s meant to be out now, and it’s not. There’s a reason for that. Books take a long time to write. Who knew?

So I’m currently writing a book with the good people at Five Simple Steps that Brian has been publishing with, and yes, I’m going through the process at the moment going backwards and forwards with an editor. I can say hands down, Five Simple Steps are amazing publishers if you ever get the chance to do a book with them, seize it completely.

But I think the kind of educational stuff we do rather than, you know, I’m not writing a fiction book, if anyone’s wondering; I’m writing a book about my job, so other people can do my job. I think for us, what you said, we’re writing it as an education, we’re not going to make a massive profit out of it. I’m hoping for a weekend away in a caravan out of the proceeds, frankly, and any more than that is great.

Jeremy: A small caravan?

Relly: A small caravan, yes. Well, I don’t want to take the kids with me. If it’s a four berth caravan, I have to take them as well.

So there is that thing that you write a book …I could write a book and give it away for free. I like books and I quite like to have a physical book.

Jeremy: You mean a physical book?

Relly: Yes. I love my Kindle; I love reading my Kindle. I said in my talk actually that the way forward for text books generally is probably going to be things like e-readers and stuff because of the print run.

So I bought a text book for my talk called The Printing Press As An Agent Of Change and the edition that I wanted was £89 hardback, and it’s like that just makes me cry, but it’s because it’s such a small print run, and so I think with the sort of things we’re doing, moving it into digital format is going to be the way to go. Maybe with the paperback accompaniment, maybe a special edition, that kind of stuff, but more and more things are going to go in that direction because it’s the only way they’re going to be profitable really.

Jeremy: And stay up to date?

Relly: And stay up to date.

Jeremy: Douglas; your book is a technology related book, but you’ve kind of had almost like a long zoom view in that it wasn’t about to go out of date any time soon.

Douglas: It’s an evergreen.

Jeremy: An evergreen. Indeed. It’s a classic. It’ll never go out of style. But that’s kind of unusual for a technology book, right?

Douglas: It is. I mean, most technical books have a version number in the title and they go obsolete in a few months.

Jeremy: Certainly when it’s physical books. So I guess this is another area where the digital could help us, where you have a constantly updated book?

Brian: This is the tricky thing as well. People are used to paying for a .1 update of a physical book, a second edition or third edition of a book, but if you paid for a PDF, do people feel entitled to get that…

Jeremy: Lifetime updates?

Brian: Yes. And I think a lot of publishers are struggling with how to take that.

Relly: One fiction author that I’ve seen deal with that quite nicely is a guy called Jasper Fforde. He writes quite comic novels. With all of his novels, he’s had a fairly rudimentary website that he’s done himself in agreement with his publisher, where he has a making of bookumentary, where he discusses the writing the book and different locations he uses as inspiration. And where he’s made mistakes and things, he has an updated version of the book, and he actually has versions that you can cut out and print the same size as your print edition, and stick it on top, which I think is a really cute idea. But it goes to show there is a need for this kind of stuff and that may be a way of handling it.

Jeremy: On the one hand, there’s all sorts of opportunities being afforded by digitising things, for example, books. But on the other hand you have these lumbering, slow-moving industries that have been built upon physical artefacts, like the publishing industry—not Five Simple Steps but standard publishing houses. They’re ignoring the lessons of the music industry and ignoring the lessons of the film industry and making the same mistakes over and over.

That’s something somebody brought up—I got handed a question from John—which is to do with what Tom Coates was talking about today. He was talking about what BERG had called Mujicomp. It’s going to be this wonderful networked environment full of things that are useful and beautiful, all connected to a network, which is a great vision, a great dream. But looking at the way that some industries have been dragged kicking and screaming into the digital age, I wonder if it might go more dystopian rather than utopian. John writes that he fears that it might be more like Ryanaircomp rather than Mujicomp, which is a frightening thought.

Brian, would you take a dystopian or utopian view of this brave digital networked future that lies ahead of us?

Brian: I think there was somebody who talked about, worried about killer robots, and he said before we get a killer robot, we’ve got a not so nice robot, and before the not so nice robot we’ve just got an angry robot.

Jeremy: Surly robot uprising.

Brian: Yes, so I think there’s a sliding scale of things we would probably stop before we had the killer robot. I would hope to think that before we ended up living in a house of Ryanaircomp, somebody would put their foot down on the Easyjetcomp, maybe the step right before.

Jeremy: Like purgatory but not hell.

Brian: So I don’t foresee it ever happening. Maybe it’ll become more popular. We see Facebook, bit of a kind of lowest common denominator that every flocks to, but I don’t, and I think there are still people with aspirational good taste that would never get down to a Ryanair.

Jeremy: But you think that would win out? You think that will in the long term…

Brian: It may tip with it. It may tip more than 50%; it would never be the way of living.

Jeremy: I guess as always with these things with technology, science fiction is a great place to look for what could happen to dystopians and the utopians. The film that I think that is of most interest to something like Mujicomp, or for designers in general, is Terry Gilliam’s Brazil because it does show a nightmare scenario where bad design is everywhere, and everything is the opposite of user-centred. Every designer …who’s seen the film Brazil? Everyone needs to see the film, because it is Ryanaircomp in film form.

Maybe it’s just me, but I find science fiction to be enormously beneficial in our industry.

Douglas: The most dystopian thing I’ve seen in digital media right now is Digital Rights Management. My reservation about buying a Kindle is that Amazon has reserved the right to delete anything they want from my device at any time for any reason, including incompetence, as they’ve already demonstrated. In order to have that right they necessarily need to know everything that I have. I don’t believe that they should have either of those rights. I’d like the device to be solely mine and I’d like to be solely responsible for what’s on it. The content industry is worried about losing control and they should, because they will. But while we still have a little bit of control, they’re trying to latch onto it as best they can with DRM, and eventually it will fail. If it doesn’t then things get really bad.

Jeremy: That would be a real dystopia. I agree; I think DRM is the epitome of the worst case scenario because what you’ll have is licensing and formats mashed together as restrictive licensing and a specific format mashed together and the result is worse, it’s like the multiplication of how bad those two things are. But I also think you’re right that it can’t in the long term succeed. As Bruce Schneier puts it; trying to make digital bits that aren’t copyable is like trying to make water that isn’t wet.

Douglas: Yes, they’re trying to repeal the laws of mathematics, and it cannot be done.

Jeremy: And we have been here already with the music industry, with the film industry. It’s sad when you see industries going down the same route. But then we have these interesting experiments; things like Five Simple Steps and other people trying interesting stuff. James Bridle—who was mentioned earlier on—he’s been doing all sorts of awesome publishing stuff. It’s an opportunity as well as a potential dystopia.


Relly: Hi

Jeremy: Someone had a question for you actually. Well I think it’s something that would relate to what you do. James Childers …I basically asked on my blog, “Tell me what grinds your gears”…

Relly: Relly. Relly grinds my gears.

Jeremy: No. A lot of people were talking about clients and how they find it frustrating. What James specifically said was “Teaching clients how to use a CMS seems impossible. They never fully grasp a concept.” Now is that a problem with the clients, or is that a problem with the CMS?

Relly: It’s a problem with the CMS. And also it’s more than that.

Jeff Eaton and Karen McGrane do a great talk together. Jeff Eaton’s really into Drupal stuff, and Karen McGrane is a UX and content strategist advocate, and they talk about how the forgotten interface of trying to use a CMS, the person who has to put this content in. Someone buys the CMS because they’ve had decisions made, they’ve had vendor meetings, a decision’s made and someone’s given them a holiday in the Bahamas or however these decisions are made. Then a completely different set of people, who aren’t necessarily from a technical background at all, are given a user interface that is wholly developer focused. Especially things like Drupal which is built by the developer community so it obviously has that kind of focus. And they’re kind of left going, “Well, I can’t make this work.” Then they start inventing their own workarounds. And that’s when the designer or developer comes back and sees what the client’s doing and goes “Yah …not like that!” Because the workflow becomes really difficult.

What we need to do is start looking back at the tools that we’re giving people and saying, “Well actually is this tool fit for purpose?” because in some cases I really don’t think it is.

Jeremy: To be fair, this isn’t just a web thing; I’ve heard this about architecture. Architects will design a building for someone who isn’t an architect. They’re designing for a completely different person and basically the architect should be made to live in that building for a year. In the same way I think the person who designs the content management system maybe should be the one using it.

Relly: A great example of that is when I lived in Brighton. I have a little boy Casper. He’s just coming up for two. When he was quite young, he was poorly quite often and he had to go to the Children’s Hospital. And the Children’s Hospital had been purpose-built for children. Apart from the beds. For some reason, they just put in these things that were meant to be like cots, but essentially they would just stop the child rolling off …the important thing was that the child was high off the ground so the nurse could get to them and could do stuff, which was fine, but I spent the entire time trying to make sure that my child who could climb out of a cot, but was not big enough for a bed, was not able to …I spent an entire night just pinning him down basically, because no one had tested this. But they thought: baby; baby in a cot; child: child in a bed and no one had thought about this…

Jeremy: Baby unit, cot unit.

Relly: Yes. No one had thought about how this was going to work. It left me with a sick child who really didn’t want to be in that bed trying to climb out of it for twelve hours, is quite tiring, and I really cursed the person that invented that bed for that reason.

Jeremy: So as I say, I’ve got quite a few comments from people talking, basically dissing clients. I think I might be the only one who’s in an agency. No, you’re in an agency as well…

Brian: I was going to say, how many people have their own …how many do they work for a product versus dealing with clients? Who does client is the question.

Jeremy: Okay, a fair few. And they’re probably all grumbling about their clients, like this comment I got…

Relly: Clients aren’t rubbish, let’s be clear on that.

Jeremy: Well this is from Chris. He says “Dumb clients always grind my gears. I end up having to spend hours, if not days, talking through how the web works in a nutshell.”

I don’t know; that’s the classic “blame the user.”

Relly: Is that not your job?

Jeremy: Explaining to Clients? I think—Bruce, tell me what you think—I think a lot of developers use clients as a crutch.

[Phone rings]

Oh, do you want to take that?

Brian: It’d better be that kidney you’re waiting for.

Bruce: I had a phone call half an hour ago telling me I’m moving house next week. That’s my reason for having the phone on.

Relly: It’s probably the Opera lawyers, isn’t it? The Opera lawyers saying, “Don’t let him speak!”

Bruce: I’m very sorry. Very rude.

Can I come back to something that Relly said about the CMSs? Because one of the reasons I left the job I used to have before joining Opera was CMSs. A horrible, horrible thing. The more expensive they are, the worse they are, I think, invariably.

There’s a million, billion different CMSs out there, all purporting effectively to do the same thing. And I’m coming around to the conclusion now there is no magic bullet. The reason there’s a million different CMSs out there is there’s a million different kinds of content out there. That’s the big trouble actually, is that they all claim they do everything. They all start life doing one thing really well. I see WordPress going this way. But it’s the best that I’ve found, in that you can’t have one CMS that does everything and is comprehensible to the human mind, let alone those stupid numpty clients…

Jeremy: Not to rag on Drupal again, but I had this very argument. I went to Drupalcon earlier this year, and it seemed to me their main problem is they’re trying to please everyone. When you try to please everyone, you end up pleasing no one. Your CMS will turn into this Frankenstein type creation. Which is why it was interesting when Mark Boulton and Leisa Reichelt were taken on board to help re-design the admin interface, one of the first things they did was design principles, they boiled it down to four design principles. The thing about design principles that I really like is a lot of time it’s figuring out who’s going to get pissed off, who you’re not going to please. They were saying things like, “Go for the 80%, forget about the 20% exceptions.” “Privilege the content creator” was one of their design principles, which means you’re going to piss off other people; developers.

You’re right; it seems that software inevitably tries to scale to please everyone. What’s that phrase? All software evolves until it can send and receive e-mail…

Bruce: check e-mail.

Jeremy: Seems pretty much everything on the web has gone that way.

Brian: A quick aside back to dealing with clients.

I was recently reading a book, Predictably Irrational.

Jeremy: Dan Ariely?

Brian: Yes. It’s a really good book. It doesn’t deal with the web directly; it’s just talking about psychology and how we deal with other people.

In that, he had a guy who worked for a large accounting agency or bank, and he spent weeks and weeks building this beautiful PowerPoint presentation for his boss. He stayed in late, did everything he should, got paid for it, gave it to his boss on a Friday. Monday morning comes in, says “how did the meeting go over the weekend?” The boss said, “We dropped the project, it doesn’t matter, didn’t need your PowerPoint, but good job.” The guy was utterly crushed. He spent all that time and effort. He still got paid for it.

So then Dan Ariely did a quick experiment. He would ask for volunteers. He gave them a sheet of paper and said “I want you to circle every letter S on the piece of paper, and when you’re done, just bring it up.” For a third of the group, he would say “Thank you very much,” give them £5, look it over and count the number of Ss.

The second group, he would take the piece of paper, give them £5 and simply just put it on a stack.

Then for the third group, they would come up, he would give them £5 and immediately just put it into a shredder

Then they asked like how much self worth or how did you feel afterwards? The group where they actually checked it and the group where they just said “thank you” and put it off to the side felt fine about their work. But the group that had it shredded felt absolutely horrible.

Now all three of the groups got paid the same amount of money. At the end of the day, if that’s all you’re concerned with, why would you be unhappy?

In previous jobs, I used to do a lot of client work, and I would pitch all these great ideas, and the clients were like, “This is brilliant! …don’t have the money” or “This is brilliant, let’s get started,” and then they’d drop it. It’s the same sort of thing. I think just after a few months or six months of that, you just get really crushed.

Jeremy: If you do want to hear more about the psychology of websites, Stephen Anderson will be talking tomorrow about how we can all become mentalists and manipulate people. It’ll be awesome.

You make a good point about what motivates people and what motivates programmers.

Douglas, I don’t know if you’ve found this, but I think financial motivation—bonuses based on amount of code shipped—is probably the worst way to motivate human beings.

Douglas: Yes, it’s especially a very difficult way to motivate programmers. You can’t bribe programmers.

Jeremy: They want to solve the problem.

Douglas: Yes, they have their own motivation for why they do things and you hope that you can align their natural motivations to your objectives.

Jeremy: Do you deal with having to motivate people?

Douglas: No, I don’t actually do anything useful.

Jeremy: Okay, you just get Yahoo to underwrite your travels while you go off and talk about Node JS and stuff? Cool.

Relly: That’s another fact right there.

Jeremy: That sounds like a dream job to me.

So this being a hot topics panel, it is a very hot time on the web I would say. To me it feels like a really exciting time. There’s so much going on. It’s hard to keep up. HTML5, CSS3, web fonts, this, that, the other. But it’s exciting.

The one big hot topic surely has to be mobile and the way that mobile has kind of changed everything, I hope. I hope it’s making people re-assess everything they’ve assumed up ‘till now. That’s certainly the way I’m looking back on my work up to now; “Wow, we’ve been doing it wrong the whole time.”

Relly, when it comes to reading on the web, do you see mobile as a game changer?

Relly: I see the ability to free content from a desktop computer and move it onto other devices that then get designed with that in mind, yes completely. Not necessarily …I mean I read fine on my iPhone and I’m quite happy to do it but it’s not my first choice of place to go and do that. I would still buy a book over do that if I had the choice.

But then there’s the Kindle. I can only see things like that beginning to free up. I have this idea that …Tom Coates mentioned that he has a screen in every room of his small flat, and I think I’m probably …I think Paul and I are probably quite similar and we’ve got something quite close to that. But I kind of think about …so I have two small children, and when they’re …ten, fifteen years from now, what are they going to be doing their homework on? I’m going to be beaming it from the kitchen, checking it on my internet fridge. The ability to move all that stuff around, that’s what really excites me. More than mobile is a device, mobile is a concept; being able to take the data you want and take it with you where you want and be able to curate that. That’s what really excites me.

Jeremy: I think you’re right. You pointed to the Orbital Content article on A List Apart. I think what that shows is that if we’re not willing to provide this portability, people will find a way to do it anyway. People will interpret the lack of portability as damage and route around it, which they’re doing with services like Readability, Instapaper, Safari’s Reader; all these things which are about getting down to the atomic unit. It’s kind of interesting that maybe our job as designers is how can we design something that’s so nice to read on so many devices that people won’t have to reach for those tools?

Relly: Yes, I mean, Readability shouldn’t really have to exist. Readability is …it’s two things. Like Instapaper it allows you to read stuff in a much nicer environment than the average website. But it also pays a small amount to the person. You basically pay a donation subscription. It gets divided up between the content that you choose to read over that time, and to small artists and bloggers and article writers. That’s going to start stacking up too. Just like Etsy is providing a market-place for small craft people that wasn’t there a few years ago, I think articles and poetry and expressions like that, as well as factual stuff, that’s going to start becoming a way of cultivating this indie movement in content. I think that’s massively exciting. You’ve got things like Bandcamp as well and all that kind of stuff.

Jeremy: Again, not great for the traditional publishers, but it’s a huge opportunity for them. All of these disruptive technologies like Bandcamp, like Kickstarter, like Readability. Yes, they could destroy entire industries but they could also save industries if those industries just could see it.

Douglas. Mobile, from your perspective, you’re talking down at the infrastructure level on this with Node JS now.

Douglas: Mobile is really hard because of the huge variability in standards compliance. There are more manufacturers and more models within each manufacturer and variations within those models. It’s exponentially insane.

This industry, this community has savaged Microsoft for many years because of its variations in IE, but that is nothing compared to what goes on in mobile. But somehow those guys are getting a pass, and we should be on them because they’re much worse to us than Microsoft has ever been.

Jeremy: So we should be a lot angrier about the disparity.

Douglas: We absolutely should, yes.

Jeremy: Now, you work for a browser manufacturer that makes two mobile browsers. Do you find that the desktop world just seems easy-peasy compared to mobile?

Bruce: It’s bewildering to me, the amount of excitement there is about mobile at the moment because, frankly, the web was founded in 1834 or whenever it was, to be accessible on any device to anybody with a disability in any country in any language. So I’m really glad that people give a toss now.

It always gives me a wry smile when third-party people like Brian Rieger, for example, tell people how big Opera’s market share is and they go “No way, I thought it was only iOS.” It’s vindication for me as someone who’s been harping on about accessibility for a decade, and for the organisation I work for that’s been doing this.

But it is really, really hard. There’s light at the end of the tunnel I think, but at some point we’re going to be saying, “I’m really sorry that your mobile device is just not adept at this, here is raw content.”

I don’t know if anybody here still has workarounds to serve raw content for IE5 Mac or Netscape 4.7. I suspect, sadly, that we’re going to end up doing that with IE6. You have to draw a line at some point, which is terrible. I don’t know if you’ve got any questions about IE6…

Jeremy: I think Douglas would be able to take any questions you might have on IE6 and the fate you wish for it. What’s your plan for IE6, you want us all to…

Douglas: We all know that IE6 must die. Beyond that, I’m kinda fuzzy.

Jeremy: Okay, one day we’ll kill it.

Douglas: I thought that we would pick some day, we would all agree the major websites would refuse to serve IE6 past that date. But getting that agreement appears to be impossible.

Jeremy: Like you say, that’s one browser in the desktop world. In mobile that problem’s multiplied. Old Blackberry browsers, pre-WebKit, it’s just kind of nuts. I think you have to draw a line at some point and say, you’ll get the raw content.

Bruce: Well the way for IE6 to die is embarrassingly simple. Microsoft need to port IE9 to Windows XP which is used by 50% of the world.

Brian: I think it’s a little trickier, because I think a lot of institutions have OEM versions of IE6.

Relly: That’s true of the NHS. One of the projects that Paul and I have been working on recently, AlphaGov, which has been in prototype for the new UK Government, one of the things we had as a design principle was “Fuck IE6.” It caused such a big stink, because so many places within Government use an OEM version of IE6,. But it was just kind of like, “You could install Firefox or Opera, or Chrome, or…”

Jeremy: It has to be said here we’re talking about it as though it’s a binary choice, either a browser’s supported or it’s not. Whether we’re talking about IE6 or whether we’re talking about a multitude of different mobile browsers. But surely thanks to progressive enhancement, we can have our cake and eat it too? I think we can make sure everyone gets access to the content. They can find out about their government data, but the better browsers get the better experience, get the better APIs.

Douglas: Well that’s one of the reasons we’re excited about Node JS, because it allows us to run all of our JavaScript in the server if necessary. If we’re talking to a retarded device, then we can just send HTML and be happy with that. We don’t have to write the application twice.

Jeremy: How do you test for that? Is there content negotiation going on?

Douglas: Yes, well the browsers identify themselves, you get to use user agent.

Jeremy: So you’re using a white-list of user agent strings?

Douglas: We’ll give the good content to the white list and if something comes in we don’t recognise then we’ll degrade to the web 1.0 experience.

Jeremy: I think that could be, or should be the way we should be building anyway, for mobile or not, is that we stop thinking about support as this binary thing.

Brian: I generally agree with you except some bits of me in the back of my head still think that, because a lot of websites have m.foobar.com, m.bbc, and it’s a completely different website. A lot of the same information, but it’s completely different. So the downside is you end up maintaining two websites, and it’s not progressive enhancement, but at the same time is it really the same objective?

We build a CMS that we’re trying to please everybody with, and it fails completely. We build this progressive enhancement website which should try and fit every situation, but it’s not necessarily, like a little piece of me says…

Jeremy: Adapts to every situation. By why do you need to be in a separate URL?

Brian: Because it’s technically…

Jeremy: God forbid a .mobi domain!

Brian: …that’s a whole problem in itself.

I worked for an airline who had the same website in half a dozen different languages, and then what’s the .mobi? Is it English? Is it French? Is it German? Whereas if it’s .dk, .de, you obviously know the localisation. When we dealt with the airlines, when you go to the .com website, you need all sorts of information; destinations, flights, prices, where things are, but maybe on the mobile, you’re like, “Well I don’t need…”

Jeremy: Now you get into tricky territory. You’re trying to mind-read what people want in the context of their device.

Brian: No, I’m just saying you can pick which URL you want to go to. If I go to m, I know I’m getting a very lightweight version with cancellations and flight times. If I go to the www, I’m getting the full site. That’s independent of the device.

Jeremy: It is interesting that we’re starting to see this “full site,” a desktop version and a “pared down site” for mobile. Quite a lot of times the mobile site is nicer because it is focused on one single task.

The reason why I’m excited about mobile is that it does, like you say, make us refocus on the way we’ve been doing things for years. “Wait a moment: why is the other site so big, bloated, filled with all this crap that nobody actually wants?”

For me this resurgence in interest goes back to the original spirit of the web, of one web, where it doesn’t matter what device you have, you should be able to get at the core content. That’s why I’m excited. It makes us revisit the sites we’ve been building for ten years.

I think a lot of people get confused that when we’re talking about this new way of doing different mobile that we’re effectively saying, “Oh we got the web figured out, we figured out that for ten years, and now we have to figure out mobile and we can apply what we’ve learned.” Whereas actually what’s happening is we’re turning ‘round, looking at what we’ve done for ten years and going, “Wow, we have not got this figured out at all,” we’ve been doing it wrong this whole time, building desktop-specific websites,” which is as bad as building mobile-specific websites or fridge-specific websites. It should be one web.

Bruce: A little while ago, about 2001, 2002, Tesco did a very good project. They built an accessible website and they had a special “cripples only” site really, it was a screen-reader site. People I know in the disability advocacy community said, “You know, this is crap. If you’re selling ads, serving ads to the desktop site, we want it on the real site, we want the ads too and know what’s going on.” That got merged. To me, mobile-only sites in 2011 is like screen-reader only sites in 2001.

Jeremy: And what’s interesting is the same thing happened back then, which was that the perfectly-abled customers were going to the accessible text-only version because it was easier to navigate; it was simpler.

Bruce: And quicker.

Jeremy And quicker, exactly. So once again, I think we’re seeing the same mistakes. Just as we did do those separate but equal sites as a bad practice back then, we’re doing the same thing now.

Brian: What happened was the separate but equal sites got merged into the big bloated site with just accessible things.

Jeremy: We went the wrong way. We went in the wrong direction, and we should have been removing stuff but we just started throwing stuff in there

Douglas: Yes, we absolutely did, we’ve had a generation of product managers and product designers who do not understand how their application delivers value, so instead they’re delivering bloat.

Jeremy: This is the classic thing where good design should be I think subtractive; it’s all about taking away but what happens is people throw stuff in.

Douglas: Minimalism is undervalued.

Jeremy: I agree.

At this point I’d like to throw it open to the audience. We might need a little bit of light to see the audience. We have some runners with microphones, so raise your hand if you have…

We’ve got someone over here on this side. Over here.

Relly: They are a beautiful bunch, aren’t they? What a good looking set of attendees.

Jeremy: Somebody’s waving madly. We’re just getting the microphone switched on. Keep your hand up sir, and we’ll get to you momentarily. There we go.

Audience member: This kind of goes back to what you’ve been talking about, Douglas, before around IE6 and how you’d like to see it die. Do you think we’re about three years away from having exactly the same problems all over again with IE8 because they won’t port it to XP?

Douglas: We already have those problems with IE9. I’m hoping 10 gets it right. But we still have the XP problem. Microsoft has dug in saying that they don’t want to go back, and I understand why they don’t want to go back. So my advice to anybody who’s on XP is, use a web browser which is not from Microsoft, and then it’ll be fine.

Jeremy: Problem solved!

Relly: Ta-da!

Bruce: My advice is use Opera by the way.

Jeremy: So the thing is, what I would say is—the situation we were saying earler about in two to three years will be the same problem with IE8, IE9—the parallel I actually see is in a few more years we will have the same situation with mobile Safari, in that people are now making browser-specific websites, specifically for Safari, maybe for Android, in the same way that people made Internet Explorer specific websites and that’s how we got stuck with this damn problem.

Douglas: Or Netscape websites.

Jeremy: Or Netscape-specific websites for those of old enough to remember back that far, showing our age.

John, you’ve got a question.

Audience member: I was really interested in Relly’s talk effectively mapping civilisation as this kind of …how we’ve been able to access and use or carry content around with us. There’s another way of looking at civilisation which is effectively our tools. Our ability to do things and make things and manipulate and change the world. In some ways I see this possible parallel that one of the interesting things with mobile is a switch to applications from a world where there were a lot of websites which were mainly about navigating and finding content, to mobile where there was a lot more things that looked and felt like tools rather than places to access content.

Is there any valid difference there? Is this just in my head? Does this really mean anything? Tools as opposed to content.

Brian: I know, Jeremy, you had bookmarked something really interesting a few days ago.

Jeremy: Well I tend to have strong opinions on this question generally. May I?

Relly: You start.

Jeremy: I call shenanigans on web apps. People just use the word as a ‘get out of jail free’ card. “Oh you know, all these best practices we’ve learned about, putting content at a URL on the network that you access through a web browser. We don’t even even have to worry about this stuff any more because this isn’t a document at a URL, this is a web app, therefore none of the rules apply.”

We’ve been here before because this happened when Ajax hit the scene. Suddenly it was like, “It’s Ajax. It’s not a website, it’s a web app, so enhancement doesn’t matter any more, accessibility doesn’t matter any more, because it’s a web app.”

Define web app! Could somebody please do that for me?

Relly: An application on the web

Jeremy: An application on the web. Right. Okay, thank you Relly.

I will freely admit that there are application-like properties and there are document-like properties. I would say pretty much every website exists somewhere on that scale, but there are very, very, very few websites that are either pure documents or pure application. At some point, there’s content, even if that content is a service.

What I see is in the same way that, I mentioned earlier I think some developers use clients as a crutch, as an excuse to avoid trying something like, “Oh, the client will never go for it,” or they’ll use Internet Explorer 6 as a crutch to say, “Oh, we can’t try out this new technique because of Internet Explorer 6.” I see apps being used as like, “Oh, we don’t have to worry about making it with progressive enhancement or making sure it’s accessible because it’s a web app.” It literally is like people using it like a ‘get out of jail free’ card.

So while there is lots of revolutionary stuff going on and things moving to mobile devices, the context, the portability of the content or service, I call shenanigans on web apps.

Fuck ‘em.

Relly, did you…

Relly: Well from my point of view, when I talk to clients about content, I try not to get into specific containers of content. They say, “let’s have a blog,” and I try and say, “What are we doing with the blog? What’s the content going to be? Is it going to be content for education, content for entertainment, content for edification?” Defining it by that content rather than the container.

I see web apps as the same thing. I don’t necessarily think of a blog article and an audio podcast or whatever. I think of it as a category of that content, which I know is kind of unusual. I see the web apps versus web page stuff as a similar thing.

I’m lucky I guess in that a lot of those decisions are kind of made outside of what I do currently. I would like to be more part of them as a content strategist, but often they’re defined before I get there. When I do get involved early enough…

One of the things—I mentioned AlphaGov earlier—is we had to make the decision about what content we were going to create and what format it was going to be in. We had to be kind of arbitrary with the time. Was it going to be a tool, or was it going to be a guide or was it going to be an answer? All these decisions were made, and the further we got into the process, we started finding that our whiteboard, instead of saying guide tool, answer was guide/app/content/answer. It was too hard to draw ring-fences. You have to take it on a case by case basis.

Jeremy: So those fences were drawn up too early?

Relly: Yes

Jeremy: When what you really want to be thinking about is what’s the task.

Relly: Yes, what’s the task. And these things go hand in hand. It wasn’t just, “Right, we’re going to have six tools and nine apps” or whatever. But what we came to define as an app was a bundle of content that may be used in a different way; a tool, a guide to something, maybe a glossary related to that topic.

Jeremy: A bundle of …sorry, can you repeat that?

Relly: A bundle of content.

Jeremy: Okay. We demand rigidly defined areas of doubt and uncertainty. That’s the best definition I’ve heard yet.

I think Remy might have something to say on this.

Remy: I don’t agree with you Jeremy.

Jeremy: You’re wrong, obviously.

Bruce: He’s not.

Remy: I have argued that a blog is a website because it’s content and because you consume it, and anything you’re publishing yourself I would argue, you use a web app to publish that. There are grey areas, and I’m also playing devil’s advocate.

Jeremy: How does the content get on the blog?

Remy: You produce it, so anyway, This the question. No, but a comment is content you publish yourself, but like you said yourself, there is this grey scale. On the web apps or websites like Gmail where it is mostly application, mostly you doing something to produce content, rather than just consuming, their mobile version for their worst possible mobiles, you couldn’t progressively enhance that up to a desktop experience, because it would be awful. So they do user agent sniffing and deliver different websites.

Jeremy: It would be very difficult. It would be quite a challenge. This is the thing. I think a lot of people give up too quickly.

Remy: They do that now. They deliver three, almost four different versions of it, and it means that their mobile…

Jeremy: Because they approached it exactly the wrong way. When Gmail launched, it was the fully fledged one that required a certain level of browser, a certain level of technology, and then they had to retro-actively create the simpler version or versions as they’ve done now. If you start with the simple version—this is the key to all this stuff whether it’s one web, responsive design, any of this—the key is starting with what’s the most basic content or task and building up from there. They didn’t do that.

Remy: But the more advanced you get, the more you have to actually have executing in the browser and as we know, the browser that’s particularly popular isn’t good at loading and running a shitload of jobs.

Jeremy: It’s hard. I think it’s fascinating what Douglas was talking about, the fact that you can make that decision on a browser by browser basis. I would say they are getting the same content but the experience is completely different. And that’s okay. So I too am pretty excited about Node JS from that perspective. Not so much about the event driven speed and performance which is exciting too, but the fact that you could do real content negotiation based on capabilities of a browser.

John has a follow-up point

Audience member: I’d just come back and just say I agree, strangely I agree with both Jeremy and Remy, because I think having …I mean using the fact, “Oh I’m doing an app” as an excuse just to go back to a whole load of crap that we used to do, I mean clearly that’s wrong. But for example, my son is an electronic music, sort of weird, strange bangy noises, music composer and makes tools for composing and performing, and those …to me, that’s not a content thing. That’s a …it’s a tool that you use to do something.

Jeremy: It’s task based.

Audience member: So I absolutely agree with Jeremy’s thing that there’s a continuum, where there’s a tool with a bit of content that floats around in it and there’s a things that are a lot of content that have some tools associated with them. Yes, they feel at the far ends of that spectrum. I think they feel very different from each other.

Jeremy: They look like two very different things. Actually they’re two sides of the same thing.

Audience member: But yes, as the excuse for just being crap; no.

Jeremy: Right, there’s a cop-out.

I will qualify this. Between you and me, the correct answer is “it depends.” Because that’s the correct answer to every question on the web; it’s “it depends.” But just so you know, my public face and persona will always be hard-ass and say no, it’s got to be progressive enhancement and one web and that’s the way we’re going to go, but I know actually some situations …but don’t tell anyone. My reputation will be in tatters.

I’m kind of dominating this here. Sorry guys, I’m not giving you a chance. We need to get some more questions for everybody. There was…

Relly: There was Paul at the front

Paul: Taking on that point that you were just saying about how we should have built the…

Jeremy: I thought we were going to go on to different point! I’ve been dominating this!

Paul: Just one more quick thing?

Jeremy Okay.

Paul: Okay. The Gmail thing—it’s not going to be the case with Google but could be the case in other contexts—but what happens if the reason they didn’t build the basic one first is because they needed to show, they needed to prove the functionality of the bigger one in order to gain funding to continue the project, so they needed to do the big “Wow, yeah”, impress the stakeholders; let’s get some more money in, and then we can go back and do the stuff that we missed earlier.

Jeremy: Effectively what you’re talking about there is a process, a workflow thing, how you approach it.

Paul: I think you’re ignoring that by saying we’ve always got to start with the basics and work your way up.

Jeremy: It’s down to professional integrity as well and being able to sleep at night; being able to say, “I did it the right way.”

Paul: And then lose funding for the entire project as a result?

Jeremy: If all you care about is money, you’re a prostitute.

Paul: No, I’m not caring about the money. Caring about the project’s future!

Relly: Are you calling my husband a prostitute?

Jeremy: Sorry. Again, I’m being a hard ass. I’m being a hard ass. Could somebody more pragmatic than me take this question?

Relly: Don’t look at me. It’s my husband; I can talk about it for hours.

Jeremy: Sorry for calling your husband a prostitute.

Brian: Any sort of Agile sprint development, you’re trying to always build the least, or the most …is it the least minimal? Most valuable product for the least amount of time and effort, so in that case yes, you could easily say we’ve got two weeks to do this; what is the most valuable thing we can build for the least amount of effort? And that’s not the simplest thing with fifteen layers on top of it. It’s let’s build the high end thing, get it working; that’s the most valuable product for the least effort.

Because like you said, in two weeks’ time, your project could be canned.

Jeremy: You’re thinking on very short timescales here. Think about the legacy we leave behind.

Brian: This is also like rapid development.

Jeremy: Again, another crutch people use. Rapid development and Agile, they’re just used as a crutch when half-assed is what they mean. “We were kind of agile in our process.” “We did it half-assed.”

Relly: I love it when people use Agile as a verb, like we Agiled it.

And I’ve worked …I tend to work with a number of different agencies and move around, so I’ve been lucky in that I get to see a lot of different workflows. I’ve seen some really crap stuff and I’ve seen some really good stuff, right across the scale of Waterfall and Agile and things like that. The best things I’ve found is when people, when teams get together at the beginning and say, “Right, how are we actually going to make this work for us and what we’re able to do within a time-scale?”, rather than saying “Right, we’re going to do this and we’re going to do that,” and being able to adapt to that sort of stuff.

I said in my talk that Agile is great for developers; pretty good for designers; really hard for content people because it doesn’t scale too well. Developers have got computer power on their side and they can get processes going and draw up code. And designers, they’ve got Photoshop and other things that help them do bits and pieces and Fireworks enable them to put it together. And then content people have got some words that we type out, and that takes time and scale. So if we’re all working in a one week sprint, I could tell you, it slaughters me every time. By Friday, I couldn’t produce any more words if I wanted to because the human mind doesn’t scale the same way as computing does.

So in some ways it’s being mindful of what individuals can do within that kind of development thing. I try and move myself as far back in the sprint as possible, so I might even be working like on the next sprint the previous …and that isn’t strictly Agile, capital A, you know everyone should be working on the same thing and this Scrum master should be whipping everyone at 9 o’clock every morning about what it is they’ve been doing that day, but it’s what works best if you’re then introducing content into it.

Jeremy: Agile, I mean proper Agile is kind of like teenage sex, right? Nobody’s actually doing it but everyone else assume everyone else is doing it, right?

Relly: Everyone says they’re doing it, and no one’s doing it well, right?

Jeremy: Right, exactly.

Douglas. Help me out. Tell me you wouldn’t tolerate short-term sloppiness for financial gain when the long term code is going to suffer? I mean come on, you gave us JS Lint, lead standards of coding…

Douglas: Yes, I’m very much opposed to doing sloppy crap, half-ass, however you say it over here. I’m against that. Particularly when we’re in these iterative models now where code is never finished, where you’re constantly going back and marking the thing again and again.

Jeremy: It’s like more important than ever to have good coding practices.

Douglas: Absolutely. You’ve got to be working from good, well designed stuff because it will crumble under youif you don’t.

Jeremy: So Paul, I’m glad the way that now it’s been established that you’re on the side of being half-assed and sloppy, but me and Douglas Crockford we’re like, “No; we’re doing it right.” That’s great.

But there are more questions. I think we had, put your hand up …we’ve got a microphone back here.

Audience member: With the implementation of the new cookie law coming in today being deferred by a year, are we going to …does the panel think that we’re going to have to trash the user experience to comply with the spirit of pre-consent, or can we rely on the year for the browser vendors to sort something out that will save our bacon, or is there something else?

Jeremy: Douglas, I don’t know if you’ve heard about what’s happening in this country; well in all of the European Union I believe, that basically cookies, with exceptions, but basically you can’t just set a cookie any more; you have to explicitly ask for user permission.

Douglas: It’s about time.

Jeremy: Tell me why you think this.

Douglas: Okay, so cookies were something that Netscape came up with to fix the fundamental problem with the web.

Jeremy: It’s stateless.

Douglas: The web is stateless and sessionless, and it turns out applications are statefull and sessionfull. So the web was fundamentally mis-matched for doing useful work. So Netscape came up with this silly patch that they called cookies, just to demonstrate how silly it was. And that has been the model by which we added statefullness and session-ness back into the web.

But we use it for a lot of other things, including authentication, and if you look at the original cookie spec, the word authentication does not appear anywhere in it. It was not designed for that, not intended for that. Instead it provides ambient authority which enables cross-site request forgeries and other mishaps.

Cookies are horrible, so I’m glad…

Jeremy: Cookies are example of exactly the kind of sloppy coding that…

Douglas: Yes, absolutely.

Brian: Was there the famous thing they would ask you, can you accept cookies, and if you said no, it had to set a cookie to remember that.

Jeremy: Yes, the Catch 22. Of course, if users could opt in to accept cookies, but if they opt out you have to ask them every single time, because the only way for the site to remember that users opted out would be to set a cookie which they’ve opted out of doing. It kind of messes with the head.

Relly: So from my point of view in terms of going back to the user experience stuff, and if you were here last year, you might have seen me talk about microcopy, and this is going to represent a microcopy nightmare, because we now have to explain to users what a cookie is. Apart from “Yeah, I’ll take cookies; who doesn’t have free cookies, you know?” (I fully expect the CD drawer to open and a cookie to come out.) But we now have to explain to people what cookies are; why they’re not dangerous, why they want them, what if they don’t want them, and this becomes a whole …and I’m not saying we shouldn’t do it because we should, but I just think there’s going to be a whole lot of sloppily-written explanations.

Jeremy: The thing is, the reason why this new law’s coming in—you’re going to love this, Douglas—the one kind of cookie that is allowed and doesn’t fall under the purview of this legislation is cookies for authentication.

Douglas: Oh dear.

Relly: It’s the best of everything

Jeremy: It’s the nice-to-have kind of cookies that are actually pretty harmless. Those are the ones that are getting outlawed.

Douglas: Bollocks!

Jeremy: Nicely localised!

So how do we get state on the web if we don’t get to use cookies?

Douglas: So does this new cookie regulation apply to local storage?

Jeremy: You see this is the interesting thing. They don’t specifically mention cookies; they mention …it could be interpreted as including local storage, I think. Does anybody want to interpret the text of the legislation, but the way I read it, it’s not specifically cookies; it’s any kind of locally storagey type thing that would include HTML5 local storage.

Relly: Can I just do a quick straw poll here? Who has actually read what this thing is? Who has read it compared to actually just heard of it?

Jeremy: I read the Cliffs notes. Somebody did a great blog post, some people at Torchbox did a sort of “here’s what you need to know” and boiled it down. I’m relying on them to have interpreted it correctly.

Relly: Yes, that’s a really handy point for me.

Jeremy: Have you ever tried to read legislation?

Relly: Well that’s exactly it, because one of the things that I’m looking at as part of this Government project is how the hell do you handle matters of legislation and make it understandable for people?

So that was a great straw poll. Thanks; that’s handy for my research. You can all collect your tenners on the way out.

Jeremy: We do not read that stuff. But an answer I guess to the question about how we’re going to deal with this cookies business, anybody got plans? Do you have a contingency plan in place at Opera for what you’re going to do?

Bruce: I was saying to Doug before, I hate doing these things because every time I come on the stage I get an email from the Opera lawyers saying, “What the fuck have you just said?” So this is …I’m a browser manufacturer. It’s the law. I can’t comment, except to say it’s a stupid law. I can’t comment because the lawyers will kick my arse every time.

Jeremy: Sorry.

Relly: Could you do it in interpretive dance and maybe we could…

Bruce: An interpretive dance about the law would just be… this does not reflect the opinion of my employers. TM.

Jeremy: All right. We’re going to have to wrap up pretty soon, but has anybody got some …oh, Remy wants to take it on. It’s going to be local storage?

Remy: No, no, no. It’s a copy question. Relly, you said that you’d have to explain cookies and so on. Aren’t the generations of people kind of rolling over, that actually you don’t need to explain cookies because they all know what it is? You don’t have to explain a mouse to your children because they know what it is already.

Relly: Yes, except that the moment that we have to ask permission for something that we didn’t really have to express too clearly before becomes the point where people ask questions.

So a kind of tangential explanation to that is if you say to someone, “We’re not going to use this for anything other than what we’ve said,” they start wondering about all the other things around that, that you haven’t given that declaration to. As soon as you’re complied to give one declaration, that’s where questions start that people don’t know.

Now those questions may be an excellent starting point for people to find out and think about this. But I don’t think there’s going to be legions of copywriters employed to give very good explanations to stuff. I think it’s going to be left to designers and developers to try and wade through and explain to users, without getting too technical, but also not leaving out stuff that’s legal. And then there’s going to be companies that have legal requirements around it who are going to add it to massive terms and conditions and it becomes another load of legal bloat.

Jeremy: Or we just flaunt the law.

Remy: Can’t we just bury it in the middle of the terms and conditions and say, “If you’re using this website,” just like the browsers where no one reads.

Jeremy The End User Licence Agreement.

Bruce: That’s not explicit agreement, is it? I’m not a lawyer, and I’m not Opera’s lawyer and I’m not allowed to speak.

Relly: Yes, I would go with that thing that it’s how we define it.

Jeremy: You are not a lawyer. Thank goodness.

So we have just touched on a few hot topics today I think, and there really are a lot of hot topics, a lot of exciting stuff happening. Things like Node JS, HTML5, CSS3, video, all this stuff.

At the same time, it does seem scary. How do we convince our clients, how do we get to use this new tech with older browsers like IE6 and how do we get past that? It’s kind of going back to the Ryanaircomp versus Mujicomp. Is this the best of times or is this the worst of times?

How do you feel about the web today and web development today? Thumbs up? Thumbs down?

Brian. Happy? Sad?

Brian: I’m happy. There’s no way this would’ve happened ten years ago. We’ve come so far. It can only go up.

Jeremy: And the price you pay is the complexity of what you need to know these days?

Brian: I think that’s inevitable though. A hundred years ago you needed to know how to drive a horse. Now you need to know so much more, I think it’s just part of life.

Jeremy: Bruce. Happy?

Bruce: Definite thumbs up. If nothing else, we’ve got even guys at Microsoft committed to doing standards-based browsers. The HTML5 stuff for better or for worse, and its genesis might be murky, but all the five browser manufacturers sitting down, committed to inter-op. Ten years ago, the idea that you could write some script and it would just work, it was a dream as you know. It’s a good time.

Jeremy: I guess in some ways we are having another browser war, but it’s a better browser war because the browser war ten years ago was about browsers creating proprietary crap and throwing it out there, whereas the browser war today seems to be, who can be the fastest at implementing the agreed-upon standards. Who can have the best JavaScript; who can have the…

Bruce: I wish it weren’t. I wish it weren’t about who could be the fasted to implement standard X.

Jeremy: But surely all browsers are engaged in a permanent pissing contest?

Bruce: I wish …the idea is that instead of you can only use your bank website on IE, or whatever, which was stupid because every website should work everywhere, that’s going away now, but the pissing contest, who can implement feature X fastest, is interesting for about nineteen seconds, but the good thing is that once the browsers aren’t competing to implement proprietary nonsense, they’ll be competing upon ease of use and features for the punter, and that’s good for everybody.

Jeremy: You must be pretty happy with the situation now, just the fact people even talk about content strategy?

Relly: We’re allowed in the room, it’s really great! But I’ll say kind of how I finished my talk. I feel we’re on a knife-edge here in terms of content. It’s up to you guys to start letting us in and inviting us to conferences and giving us space to talk so that you can meet us and we can meet you and form partnerships, because I think only by forming those partnerships and having content involved is this web thing ever going to take off. Up until now it’s just been playing around, but if we’re really going to make it a mode of communication and a historical record and a thing of value, that’s the direction to go.

Jeremy: So it’s time for us to grow up?

Relly: Yes, I think so.

Jeremy: Time for the web to grow up.

Douglas; you’re an optimistic, happy kind of guy?

Douglas: Absolutely. The worst of times are way behind us, and ended about the time that Netscape failed. Things have been getting progressively better since then. Enhancing, if you will. So things aren’t as good as they should be and there’s going to be a lot of pain and misery going forward, but that is our lot in life. But overall yes, it’s all getting better.

Jeremy: And it will always be thus. There will always be some browser that’s lagging behind…

Douglas: Yes. Part of the dilemma about the web is because it is open, it’s always going to be lagging in some way, and it’s always going to be tough to get everything to move together. This community suffers more than anybody else around that. But even so, I think it’s a good place to be.

Jeremy: Good. That’s a positive declaration from everybody.

Bruce: Can I make a tangential announcement by the way, talking of better browsers and better user experience.

Jeremy: You’re not going to plug Opera?

Bruce: No, no. We’re hiring. There’s three Opera guys walking around in Opera T-shirts and we’re looking for some bad-ass User Experience people to help make the actual browser better, as well as Web Developers. So if you’re interested…

Jeremy: Well if you’re allowed to do a blatant job plug, then I’m also going to say that Clearleft is hiring. We want a User Experience person.

Bruce: We pay more!

Jeremy: We have cookies and cupcakes!

We’re hiring a User Experience person, whatever that may be, and a Project Manager. If you know any good Project Managers, send them our way.

But I believe it is now time for booze and music. Ian Lloyd is going to be spinning the decks. Is that what you say?

Relly: We had this discussion. It’s all buttons. He’s going to be buttoning the deck.

Jeremy: Okay. Ian Lloyd will be buttoning the decks. We’re going to have a DJ; we’re going to have booze outside.

But I would like you to please join me in thanking the panellists; Brian Suda, Bruce Lawson, Relly Annett-Baker, Douglas Crockford.

Saturday, July 2nd, 2011

Mobilism transcription

Remember that mobile browser panel I moderated at the Mobilism conference in Amsterdam earlier this year? Well, I’ve had the whole thing transcribed. You can now:


Thursday, June 30th, 2011

Mobilism 2011 Mobile Browser Panel

A panel I moderated at the Mobilism conference in Amsterdam featuring representatives from Nokia, Opera and RIM.

Jeremy Keith: Okay and thank you for that lovely introduction. Hello everybody. Is everybody having a good time?

That’s nice. That’s good to hear. I’m having a great time, I think today’s been pretty excellent. Great mix of talks we’ve had today, and this is going to be the last event of the day before beer, which is very important, so here’s how it’s going to work. We’ve got a kind of a …this is all going to be pretty unstructured. Even how long this is gonna go on is kind of unstructured. We’re beginning now and we’re going on ‘til at least five, but it could be five thirty; who knows? It could even be longer. But any time from five we might finish up if they’re really dull and boring; it won’t be my fault, right, if they’re really dull and boring? We’ll finish up early and we’ll all go for beers at five, but it could continue on. I’m only kidding. They’ll be wonderful.

So we’re going to have some questions for the people who make browsers, we’ve been putting the call out for a few days now, PPK on Twitter and me and my blog saying “if you have any questions you’d like to put to mobile browser makers, let’s hear them”, so I’ve had some responses on my blog, most of them people commenting “first!” but after a few of those there were some genuine questions, so I’ll get round to asking some of those, the good questions.

Some people have been asking questions on Twitter; thank you very much, I’ve been checking the #mobilism hashtag throughout the day, and there’s been one or two questions in there, along with nice comments about all the talks which was great to see, and the occasional comment complaining about whether the chairs are comfortable or whether the food is any good, right. It wouldn’t be a conference in the Netherlands if it didn’t have people moaning about something or another. This is the language that gave us the word mierenneuker; that makes sense that Twitter is the perfect medium for this.

If you haven’t submitted a question by Twitter, too late. You had your chance. I’m not going to be looking at Twitter while I’m supposed to be talking to these guys. However, you will get a chance to ask a question. As this progresses, I’ll open it up to the audience, so be thinking of questions. If, in the middle of this, you just can’t take it and you have to scream out your question straight away, do it man! Just do it! Like, stand up, wait for somebody to bring you a microphone and then just scream out your question.

Anyway, so this is the way it’s going to work. We’ll have some pre-prepared questions to begin with. Probably start with some of the more technical stuff—and the people want to know about technical issues—and we’ll broaden it into maybe more philosophical debate about the mobile web and the future and browsers and the meaning of life, and then we involve you guys, so it could go anywhere. Who knows? Who knows where this will go? So let me introduce the people I have with me here today.

To my left, I have Eli Fidler from Toronto in Canada. He works at RIM, which sounds rude, but isn’t. It’s Research In Motion, and you’ll know them for the Blackberry. Over there we’ve got Andrea, Andrea Trasatti, and I should be rolling the Rs as I pronounce both his first and last name, but I’m incapable of rolling my Rs. I apologise, Andrea…

Andrea Trasatti: Practised …we practised rolling them yesterday.

Jeremy: I’m sorry, I just can’t do it. Stage fright. Andrea is from Nokia, and then we’ve got Andreas Bovens, who is from Belgium but now based up in Norway, because he works for Opera. So basically representatives from RIM, Nokia and Opera.

And that’s it as regards representatives. Hmmm …hmmm, “how strange?” you might say. “I can think of a few other mobile browser manufacturers that should be on a panel about mobile browsers.” Indeed. And PPK has been doing its utmost to get representatives from other browser makers here and …no.

I mean Apple; forget about it, right? Apple never send anybody to any of these kind of conferences. Steve Jobs is allowed to speak, Phil Schiller, that’s pretty much it. No one else at Apple is ever allowed to speak at an event, so there’s no chance of having a representative from Apple here, which is a shame, and PPK tried to get someone from Google to come along, and there isn’t anyone specifically involved with dev outreach for Google Webkit; for Android Google Webkit. There is for Android in general, but not specifically for Webkit, and that’s a shame. It has to be said, the timing is kind of awkward because Google IO is going on and all that. And PPK reached out to lots of other people too, but this is it.

These are the people who were brave enough to step up to the plate, so I salute them for their bravery, and I have to begin with a disclaimer, and this is …you know when you put the DVD in the DVD player? You remember DVDs? And you get the disclaimer at the start saying that the views and the opinions expressed are purely whatever not the opinions of the …you know, the usual crap where they cover their ass about what they’re about to say in the commentary. Imagine that’s here, right, I’m putting that disclaimer up. The opinions expressed here are total bollocks just shooting the breeze; they do not represent a company’s opinion. So don’t be trying to hold Nokia to a certain standpoint just because of something Andrea says. And don’t think that Opera are taking a certain position on something just because of something Andreas says, okay? These are just opinions. I’m also saying this as much for your benefit as for the panellists here so that they know they’re in a safe environment, okay? Feel free. You can relax, all right? Nobody’s watching, right? Ignore that camera up there. Nobody’s watching.

Okay, so that’s the ground rules I’ve set. So what I wanted to do was, I was going to begin with a targeted questions for each of the panellists, specific to their browser, then we’ll get into the more specific technical questions for everyone.

So let’s see, who will I begin with? Andrea. And this is a question that PPK put together. He wants to know exactly which browsers does Nokia maintain, and for which platforms? How long will they continue to exist? PPK tried to do a count, let’s see we’ve got like Symbian Webkit; S40 Webkit which is like Symbian, MicroB for Meego, Ovi for S40, and soon, Internet Explorer mobile. How many are there?

Andrea: I stopped counting after three, but right now in development we have two, so there’s Webkit for Symbian and Ovi Browser for Series 40. That’s all we have in development.

Jeremy: So that’s what you plan to maintain?

Andrea: Yes. So …the Webkit, for example, for Series 40 is not currently in development, so that’s end of life. There used to be actually a WAP browser in Series 40. That is not going to be maintained any further. Of course it is still coming and devices that are being released now…

Jeremy: What does end of life mean for …like, you’re not going to answer the phone calls when people have…

Andrea: We never answer phone calls anyway, but …no. It means that unless there is some major security issue, then that’s whatever is in the browser and that’s the amount of capabilities that you get. On the other hand, for Symbian for example, we keep maintaining the Webkit. We announced Symbian that is coming in the next few months, and you can already see it on the C7 stand, the one that is on sale in the US, that one is already pretty much the 7:3 browser that is coming to Symbian across the board, so on all Symbian 3 devices and also non-touch devices and previous devices, and the Ovi browser for the Series 40 which is a proxy browser.

Jeremy: And this whole Microsoft Nokia thing, you’re just ignoring that? Putting your fingers in your ears, going la-la-la?

Andrea: Well you asked me, PPK said, which ones Nokia is maintaining.

Jeremy: I see.

Andrea: So IE is a Windows phone thing and Microsoft maintains it. So far the plan is when the Windows phone comes it will run whatever browser is on that Windows phone.

Jeremy: Okay. So Nokia’s still Nokia: Microsoft’s still Microsoft?

Andrea: For the software platform, yes. So …mix Nokia …Microsoft talked about their I7, the IE9 coming in their next release which is I think Mango, so…

Jeremy: But if people have questions on that, you’re not the guy to talk to?

Andrea: No. Correct.

Jeremy: Okay. Good that that is cleared up. Speaking of maintaining end of life products, Eli …what advice do you have for people trying to deal with the old, the pre-Webkit Blackberry browser?

Eli Fidler: It’s a very good question, and we get it a lot from people, and I guess the first thing to start with is that Blackberry 6 and onwards is Webkit; that was the first Blackberry OS version that has Webkit, the Torch was the first device out, and in most respects, it is compatible with Webkit on all of the other mobile platforms, there’s obvious subtle differences between what you get on IOS and what you get on Android and what you get on Nokia’s phones, but Webkit is Webkit to some extent. Before that, we had the 5-0 browser, and the 5-0 browser is kind of a hybrid. It’s …it’s not Webkit. It does have some basic HTML5 and CSS3 support, but certainly not to the level that people who have been writing desktop websites expect, and supporting it can be a challenge sometimes

Jeremy: You didn’t mention JavaScript there…

Eli: Actually has decent JavaScript support. Performance is not amazing …so I don’t think that people are really going to be doing a lot of JavaScript based animations and highly visual things on the 5-0 browser but basic support for things does work better than a lot of people would expect and we are maintaining support backwards to 5-0 for our WebWorks platform which is our device APIs and widgets framework that I’m sure will come up in future questions. Before that, so 4-7, 4-6 and earlier the browsers were frankly not that great, and I think that everyone kind of knows that. Outside of the company there’s a lot of expertise on people who are being forced to support these platforms, probably more than I know. I joined about the 6-0 time so I don’t have a lot of personal experience there but there are some framework out there like JQuery Mobile that’ll be doing some of this work for you. So that’s definitely something to look into. All that being said, the market share of 4-6 and 4-7 and earlier is dropping quickly, and the market share of 5-0 and 6-0 together has well surpassed 4-6 and earlier, and that gap will continue to widen. The biggest use right now for the earlier releases is corporate devices in North America and that’s still an important market to target, but most of the people who are doing that are very specifically focused on those platforms.

Jeremy: Okay. Good answer. Although when you said Webkit is Webkit, I could pretty much see PPK kinda …tense up

Eli: I know

Jeremy: Because I believe you have strong opinions on that viewpoint.

Eli: I hope everyone’s read PPK’s article on how Webkit is not Webkit!.

Jeremy: It is well worth reading. So Andreas, for you, Opera, in the mobile space has two products and I can never keep straight in my head which is which. What’s the difference and which is which between Opera Mobile and Opera Mini?

Andreas Bovens: Okay. So to explain it simply, inside the Opera browser there is core rendering engine; we call it core internally. To the outside world we call it Presto. It sounds a bit fancier and faster even. And so what we try to do is in all the deliveries we do and all the products we make, we ship the same …sorry, the same Presto rendering engine. This means that in Opera Mobile, you get the full rendering engine; the same rendering engine you get on desktop, on the desktop browser is also available on the phone. And so the Opera Mobile browser is currently at version number 11, and it’s available on Androids and on Series 60 …for Series 60 phones, so we’re not supporting Windows Mobile 6.5 any more, and I’m not sure yet what will happen with Windows Phone 7, so that’s a little bit up in the air still. So that is Windows Mobile, so you’ve got the full …the full browser, the full rendering engine on the phone. In the case of Opera Mini, there the rendering engine lives on the server. That sounds a little bit strange but what happens there is it’s a proxy browser, which means that whenever you load a page on Opera Mini, which is sort of a thin client on the phone, it quickly connects to a server, it says, hey I want to load this web page, the server connects to the site, fetches the web page from the site, renders it on the server and then sends back a strongly compressed version to the phone. That happens with …that sounds pretty complicated, but it happens really fast, actually often faster than if you would render everything on the phone, so that’s …that’s Opera Mini, and so we see that a lot of people that have feature phones are interested in this because their phones are not capable of running a full a full rendering engine basically; their devices are too slow, too outdated or there are other issues, so for them Opera Mini is perfect because it allows them to get a decent web experience without having a a smart phone or the latest model of phone.

Jeremy: So just in terms of numbers, which gets more use?

Andreas: Opera Mini gets more use because there’s much more feature phone users out there than smart phone users, so I believe we surpassed in March we had 102 million monthly users on Opera Mini, and they viewed if I’m correct 60 billion pages within that month, which amounts to 8.8 petabytes of data that was compressed through our servers and then, well you keep about 80% or so of the data traffic, so it …it’s interesting for users also because while they have to pay less in they have to pay less per megabyte of course because they get less data, and which is especially cool when you’re roaming, because you have to pay less, so it speeds up things significantly.

Jeremy: Well, I mean, as we saw in the talks earlier today what is a feature phone; what is a smart phone; the lines …I would hope to see those numbers drop off.

Andreas: Of Opera Mini?

Jeremy: Yes, and more and more people using say Opera Mobile.

Andreas: So …yeah, so there is …so we see people increasingly also using Opera Mobile. I believe right now we are about 50 million people use Opera Mobile monthly, so it’s increasing there as well. However, what you do see, and we were also surprised a little bit, so you would think Opera Mini is only for a feature phone and once you have an advanced phone you go to a full rendering engine; it’s more powerful, and that’s true, I personally prefer it as well, but still in certain scenarios, for instance when you have bad coverage, it was mentioned a couple of times today, then you actually see that hey, Opera Mini is …is just useful there as well, and so we see that even on high end phones like on Android phones, we see that there are a lot of Mini users out there, even although they have the built-in Webkit browser or Opera Mobile to their disposal; they still also use Opera Mini aside, or to combined, or exclusively, yeah …so..

Jeremy: Andrea: does Nokia have a similar kind of service …Ovi…

Andrea: Yeah, so the Ovi browser that I mentioned earlier is what they call distributor user agent, so it works pretty much the same way as Opera Mini where there is a proxy on the server side for us that fetches the page, computes, does everything compression, and then delivers to the Client, and the reasons are petty much the same where small screen, low bandwidth, reduced cost and reduced CPO.

Jeremy: So would you agree that it’s not going away any time soon, that’s going to be a long term trend?

Andrea: Well, depends what you mean by long term, but definitely right now there is interest, a lot of interest in this type of technology, mostly for data usage and accessibility basically on remote servers, so it makes it easier.

Jeremy: Okay, well let’s get into more sort of how devices deal with …with the web pages out there on the web, and one of the issues, of course a lot of web pages aren’t made for small screen devices, so you introduce zooming, but you could zoom in different ways. Some browsers would choose to literally re-flow the text maintain what’s on the screen; others would zoom so that the text is now going off the screen beyond the viewport, so if each of you could tell me what your particular browser does and why you went for that solution. Eli?

Eli: Okay, so our zooming is …different on some of our different platforms, but if we look at the 6-0 Webkit browser that we’ve released, right now it does re-flow text when you do a double tap zoom, so we call that a block zoom, and by default it will change the line breaks within a block bubble element that has text in it that they fit on the screen if it fits within a reasonable set of parameters, if it …you don’t have to make the text too big or too small to do that, to make the line breaks too ridiculous. That feature can be turned off, but we’ve found that people don’t want to scroll horizontally as a general rule, so that’s why we did it. It’s a slightly different implementation than what some of the other platforms are doing, particularly IOS and Android, but achieves basically the same result that when you …indicate that you want to focus on a block of text by double-tapping on it, we make it so you don’t have to scroll horizontally. That was the problem statement that we tried to solve. It has historically been done by much more drastic measures on our 5-0 browser we had something called Column Mode, which literally took all block bubble elements of the page and oriented them vertically, so the entire page does not require horizontal scrolling; as you can imaging that makes web developers crazy because it totally breaks your page layout, and we’ve tried to break your page layout as little as possible. On our larger screen devices like on Playbook, we don’t actually re-flow text at all because we haven’t found it to be particularly necessary in talking to users on the larger screen.

Jeremy: Fair enough. And Andreas. Opera, what do you do on Opera Mobile?

Andreas: Yes, so I think …so this goes way back, there was mention of this …what was it called …Column Mode or something like that…

Jeremy: Yep

Andreas: So we had something similar which we called Small Screen Rendering. SSR. Nobody knows what it stands for whenever we …we have it in the US, so now it’s called I believe Mobile View. It’s still there in the options in Opera Mobile, so that also re-flows everything in one long column and it sort of alters the page. Web developers don’t like this very much and users are often confused, although we still see a lot of people using it, interestingly enough, so that is one way of dealing with it. The other way where we deal with it so the browser sits with this Mobile View or SSR mode turned off by default, so you get an experience where you get the full overview of the web page and AU pinch to zoom, and then wherever you are, so that that block of text gets actually re-flowed and sort of fit nicely within the available screen width. We did a little alteration before, so let me go back one step, I believe in Opera Mobile 10 we did that before, so we didn’t have pinch to zoom; we only had two level zoom, so you were zoomed out or zoomed in, and then we would already pre-calculate, okay, this is how big, how wide the text block is going to be when you double tap, and then people who are not web developers and users were not very happy because you had these wide, wide blocks of white space randomly over the web page and they thought, oh my blog or my website is broken, and we always had to explain well no, it’s just because of two zoom levels, otherwise you would have to scroll left and right; that would be really annoying, and then we experimented a bit with only doing it on tap or only when …sorry, only when …only on tap and not when pinching, and then we saw, so that was in 10.1 data which came out in November, and then we thought no, this is way too complicated; nobody understands it any more, and then we said okay, let’s just give the user the option, it’s on by default, so you pinch everything is re-flowed, and if you turn it off, it doesn’t re-flow and you can …you can scroll left and right if you want or just not zoom in too much, but so …yeah.

Jeremy: I know you could actually use the small screen rendering even on the desktop browser?

Andreas: Yes, that’s correct.

Jeremy: Is that still in there?

Andreas: No, it’s not in there any more. So also because we …it sort of …I believe it was listed as something like, well that you could give the impression that it was like a mobile emulator or a mobile view …view mode, which it wasn’t really because we didn’t ship it any more by default and sort of people would be confused to think like, oh …that’s how Opera renders mobile pages …ha ha ha …so that’s why we didn’t…

Jeremy: Don’t use a desktop browser for testing mobile websites.

Andreas: No exactly

Jeremy: Okay, fair enough. Andrea. Re-flow or zoom?

Andrea: Good question! Nokia has a large variety of devices so on the low end, if we’re talking about the old browser that was re-flow because of the screen, and the same happens in Ovi browser where the default behaviour is to re-flow, but actually as much as Opera, you can just go into your settings and change it, and you will get an overview and then you can zoom in, and the reason there as much as the Symbian devices that are not touch, is mostly usability, so it is not very easy to point and zoom in or double-tap or zooming, pinch and zooming is so much easier, and with old devices with no-touch wasn’t that easy, and so for consistency, even on touch devices right now, we zoom automatically onto what the browser thinks is the main content of the page, and we try to re-flow it, let’s say…

Jeremy: That does bring up an interesting point, that basically you were trying to avoid actual zooming when people were trying to navigate with keys or a joy-stick or whatever, but now that there are more and more touch devices, is that as much of an issue, I mean maybe you’ve had to re-think it?

Andrea: Well right now, Nokia still is selling both, so even tough the move is towards touch only, there are still devices, and even the browser 7-3 that is coming with Symbian Anna will actually …is actually being back-ported to the non-touch devices so for consistency, we’re now going with mostly re-flow. Now if you have a very big image, you will still have to scroll left and right, but we try to avoid that as much as possible.

Jeremy: Fair enough. Fair enough. Do you have any idea of numbers of touch-screen devices, non touch-screen devices that Nokia’s shipping, planning to ship …it’s okay if you don’t, that’s fine.

Andrea: I’m trying to think, because there were some …we are talking about shipping 150 million Symbian 3, and all Symbian 3 are touch. But that is going to be between the end of last year and next year.

Jeremy: Okay, so we’ll see. All right. Enough pussy-footing around. Something I have to bring up, because it’s come up in the talks today, and I have the chance to talk to browser makers, have to bring this up. Device APIs, right. We web developers, we want access. Grant us access! Why don’t we get …native apps get to use stuff, native apps get access to the contact details, address book, photo library, the camera …the camera! All the stuff and yeah it’s coming, it’s coming, it’s coming …why is it so hard? What’s the problem here? Andrea?

Andrea: We had device APIs in WRT for years now. The only point is that it was not standardised so WRT came before even the W3Z started doing the …widget packaging and distribution, so at the time we were ahead of the curve and then we never standardised towards one

Jeremy: So how does it stand now, making a native app for…

Andrea: Yeah. WRT is a package that you develop and it’s web technology, so it’s HTML and JavaScript.

Jeremy: So whether making a website or making a native app, you’re saying I have the same access to…

Andrea: No. That’s the thing. So in WRT you do. In the web browser you basically have access…

Jeremy: It’s the web browser I’m interested in.

Andrea: Yes. I know. But I can even bring one more item to the discussion that was mentioned by Brian Leroux earlier which was Qt Mobility and through Qt, you can use Qt Webkit and you have access to a bunch of API sensors, a number of things. The point is that you still have to built a shell in Qt, but then you …once you fire the Qt Webkit, you have actually access to a lot of device APIs.

Jeremy: I can’t just visit the URL and that URL have access@

Andrea: Not right now, no.

Jeremy: Why not?

Andrea: Er ….because we haven’t done it yet!

Jeremy: Yet. Yet. Okay, that’s good. Yet is the word I wanted to hear there. Andreas? Is it hard?

Andreas: Yeah, it is hard I think. At Opera we’ve been playing around with this for quite some years, mostly in the context of widgets, but still, you can’t load this in the browser in the URL, so then we talk a bit about that. I think the dual location API is a good example of something that came to W3C was agreed upon through, well a process the W3C process, they always take time, but this one went fairly smooth I think and then implementations followed in desktop. I think two years ago there was not even a single browser with this in and now we have it all on desktop and mobile and everywhere, so that’s …that’s something that went really well. And … but it’s not so easy to do it for all the APIs, so to give one example, a couple of …let me see …two months ago or so, or maybe even less, a couple of weeks ago, we created a special built of Opera Mobile with support for the device element

Jeremy: That’s right

Andreas: So we released …we released a post about this and so we said, look, we’re going to do this and we think this is very interesting, the device element will allow you to sort of hook into the camera on the phone, and …I never really know what it is, the front face, the one that points that way, not to your own face, and so you could …you could play around with it and script it and do all kinds of stuff, and so we said, well we’re about to release this and the moment we announced this on our core blog, the specification changed. Literally the same day. Probably as a bit of a reaction to …it’s a lot of politics in these working groups and so on. There’s always a lot of things…

Jeremy: No …No …Politics? It’s W3C! No…

Andreas: So anyway …so then we …but that’s a good example of, well you want to ship something but there is stuff so much changing and very often there’s a significant investment. You have to decide in advance, okay are we going to put a couple of people, a couple of man months of work on this, knowing that it will change and so we, in this case we knew it. Luckily we were well prepared, because one week later, we actually shipped the version public with the new get user media API implemented, and so that was there. It also had device orientation events and stuff like that, so we are experimenting with this, but if you try to build, it’s quite interesting, you can play around with it. It’s still a bit unstable; it’s a little bit crashy; the specification is still changing. So is it ready for deployment in the real browser? Maybe yes, it still needs some work. What do you do for instance with privacy …do you prompt the user every time …do you want to access this application or this website wants to access the camera, are you fine with it? It’s a whole other different matter from oh, this application wants to access your camera because you get a sort of …you have this point of control in between which you don’t have with websites…

Jeremy: You install the application?

Andreas: You install the application so…

Jeremy: But you just visited a website

Andreas: Exactly, so you’ve already sort of given consent or so those kind of things are all …well more complicated I think than with native web apps, and that’s why they take more time, and that’s why browser vendors are very interested. We love this kind of stuff. But at the same time we also have to see, okay, what takes well what do we do first? There’s so many things in the list, and…

Jeremy: Yeah …actually I was kind of disappointed that the device element got removed and now it’s pure JavaScript API because I genuinely preferred the clarity of solutions, but you do bring up the whole point of if you try and innovate too far ahead and you …you end up making something that’s proprietary. Unintentionally, because you’re going ahead at a standard, but then you’re waiting for a standard like W3C to finish something, you’re waiting for years, so it does seem like there’s this dance between implementation and specification, and that’s not just with mobile stuff. Obviously that’s browsers in general. Yeah, so Eli, device APIs. Now you have …you got the hardware as well as the software, right? You’ve kind of got that…

Eli: Yes

Jeremy: You’ve got that tie-in. That’s gotta help.

Eli: It definitely enables us to do things, but we’re in a very similar situation to what these two guys have already talked about, where we do have a widget framework, for web technology based apps, WebWorks that provides you access to almost 100% of the same issues…

Jeremy: Sure, but we’re interested in what happens when they go to URL in the browser.

Eli: So most of our APIs that are accessible from an arbitrary website in the browser, we get from upstream Webkit, so we work very closely with the upstream Webkit project, and that means that things that go into the upstream codebase eventually will make their way into our browser as a general rule. It’s not true for absolutely everything. Which is why geo-location and that sort of thing is very well supported. None of the other mobile Webkit browser makers other than the Qt browser are upstream, so in particular the mobile Safari Webkit and the Android Webkit are off in their own worlds, very far diverged, which is why it’s hard to come to agreement on these sort of things, so we are participating in the W3C to get some standardisations on some of these things. A big restriction for us is that once we ship something, we are very stuck with it forever and…

Jeremy: So you want to get it right

Eli: It’s very, very hard for us to say the kind of things that Opera can; hey, we’re going to put up a dead built and have people try it and see what’s going to happen, because we have to support it forever.

So making choices, those initial choices, you may rue the day further down the line. Speaking of making choices you may rue, video codex. Which ones to support; which ones not to support. Why? Why not? Technical reasons? Political reasons? So on a Nokia browser what …if I have a video element for example, what’s going to play?

Andrea: So the Nokia browser doesn’t play anything embedded in HTML5 there’s no support for that but anyway, usually what is supported so you can download it and play it offline or you can play it in a Qt application. It’s H264 is usually…

Jeremy: So you are paying the piper? You are paying the…

Andrea: Not only that, you are also paying Adobe so you can also play Flash like video. So we’re paying everyone, except the free one that is Google.

Jeremy: But you’re not going to support that?

Andrea: For now, no. So it’s not in the devices right now.

Jeremy: So you like to pay money?

Andrea: Yeah …yeah …but then we charge it on the customers.

Jeremy: Okay, fine. So you think if it’s free, it can’t be any good? That’s basically your philosophy?

Andrea: No, no. At this stage of course there’s for example a chip reasoning where chips have hardware acceleration for example for H264…

Jeremy: Is that mainly the reason then? Because of hardware acceleration?

Andrea: Well, right now it is one of the reasons, yes, and the other is that we’ve tested and used it three years and we know how it works and everything. WebM for example is still the new technology and hasn’t been tested enough for us…

Jeremy: So it’s like a wait and see attitude with WebM?

Andrea: Yes. It could come. If it is a better standard I don’t see why we wouldn’t. But at this stage, H264 is the kinda safe horse.

Jeremy: You might want to work on that video element support as well, you want to get that in there. That’d be good.

Andrea: But you can try it in a Qt application.

Jeremy: I’m interested in going to URLs in a web browser. I don’t know how often …

Andrea: I’ll send you a line of code of…

Jeremy: I know you all love your little wrap this stuff up in and standalone thingies…

Andrea: You can sell it on the App store.

Jeremy: Monetise. Right. No; I want to go to something in a URL, in a web browser, and have it just work. Am I asking too much, apparently?

So video codecs. Obviously, okay, you’re in an interesting position because you, as well as making this mobile browser, Opera Mobile, you also make desktop browser. I take it it’s the same …the same factors, factor into what you do and don’t support?

Andreas: Mmm …yes …yes and no. So there’s a couple of differences. On this stuff we have Ogg support, and WebM support. On mobile there’s no Ogg support. We do support WebM from Androids 2.3 and onwards, so Opera Mobile running on Android 2.3 will be able to launch or play WebM video in the native player, so we hand it off when there’s a video element, with a WebM URL, or a source link from it, you click on it and then it will launch the native video player that’s available on the device. So you don’t have to download it first. It starts playing right away. Or there is …so in the other Android devices but also in all Android phones basically, we also support H264 because it’s already present on the system, so we just the same there, we hand it off to the system and …so

Jeremy: So the system’s doing all the work?

Andreas: The system’s doing all the work basically. So if you want to run …so in-line video support is not …so inside the page is not yet …we don’t have that yet, so there’s performance issues mostly. It’s …you mentioned also how it works acceleration. For instance WebM doesn’t have this yet. It might be coming. I’m not entirely sure how close that is, so there’s an issue there. So we don’t have that running yet. So probably if you really need in-line video on your mobile application, your only choice is probably Flash for now which runs, but, well, it’s Flash.

Jeremy: Okay, that’s a shame. Can I watch a video on my Blackberry?

Eli: So …in our in market hand-helds right now on 6-0, we do not have support for the HTML5 video element. On Playbook which just came out in the last month, we do. It supports H264

Jeremy: So you’re paying the piper as well?

Eli: Yes. And similar to Opera, I guess, from my perspective, we hand it off to the system. So Qnix has this very nice video playback API and the codecs all come from there.

Jeremy: So you really are making those decisions about which code …it’s the system…

Eli: As the browser team, we are not involved in that decision.

Jeremy: Okay, fair enough

Eli: But embedded video works very well in the Playbook browser, and will be coming into the Blackberry 7.

Jeremy: So still on sort of technical details, something else that web developers might occasionally mention that they’re interested in …a little CSS declaration …position fixed! Now I mentioned that this is happening at the same time as GoogleIO and I think the Android guys were quite excited to announce that they now do support position fixed, so has the bar been raised do you need to get on that?

Eli: Blackberry 6 again in market 1, we support position fixed the same way that Android used to, which is when you scroll, the position fixed scrolls with the page and then jumps back afterwards, which is …not what anybody wants, but in the Playbook browser, we have true fixed position support. If you put position fixed on something, it will be fixed for real, and the page can scroll underneath it and be fast and that will be coming to Blackberry 7.

Jeremy: Okay. Good. Glad to hear it.

Eli: And I still haven’t seen it running on Android, so as far as I know, we are the only mobile browser in market that does support that.

Jeremy: Oh yes, a pissing competition. Just what we want. Andrea?

Andreas: Yep. In Opera we do the same, so we …it’s sort of fixed as in, when you scroll, it’s still stuck to the page and then when you stop scrolling, it jumps back into place, indeed not particularly smooth.

Jeremy: But is it really that hard. I mean, I don’t make a browser…

Andreas: It is …it is very hard, so to be honest I’m also not …so it’s fairly complicated because it relates to …so …well, how to say this simply. Basically if you make a mobile browser, there’s a lot of hex involved in sort of getting or …a lot of tricks involved let me say it like that, to make this …to the view port stuff and the zooming and all that, and so you have to calculate a whole lot of things and there’s a number of layers, so for instance what do you do when …so if you have a web page with a view port metatag, and then what is position fixed? Well there’s fairly obvious what should happen, like you always want this bar to stay at the top regardless if you scroll the page, but if you also zoom at the same time and then what should happen then, and what if a whole say sidebar with a lot of elements is fixed and you …so there’s a lot of calculations to be done there, and it seems …so in our older infrastructure, in our older way of rendering web pages on mobile, which was pre-Opera Mobile 11, that would have been basically impossible to do, to support position fixed. However, now with Opera Mobile 11 we have if you pan, it goes very fast and so that’s because we have a new way of putting the layout and everything…

Jeremy: Calculating it?

Andreas: Calculating it. And so now they’re thinking …so we haven’t done it yet, but they …I was talking to developers a couple of weeks ago, and then they said, well there is a possibility we can actually get this to work properly…

Jeremy: You think you might beat these guys to the punch? You might get it out in time?

Andreas: I’m not sure yet, but we’ll definitely try. So it’s …I don’t think it’s that far away, I’m not going to make promises but, yeah, it seems to be less impossible than it was before. So that’s very vague, isn’t it? So anyway.

Jeremy: Andrea, you got position fixed for us?

Andrea: In 7-3, so the one that is coming soon, yes. So it mostly works but I would agree within there sometimes you might have some…

Jeremy: There’s a lot of things I’m clearly not thinking of. It’s not as simple as it sounds.

Andrea: Yeah. You might get it wrong if you zoom…

Eli: I could maybe give you just a little bit more detail on that. So right now there’s the big question about what to do with zooming and position fixed together; should you zoom the fixed position element or should you not; if you zoom the fixed position element and it’s stuck to the side of the screen, eventually it’s the whole screen, then you can’t get any content underneath it.

Jeremy: It sounds a lot like Frames all the complicated stuff that came along with Frames, there’s more to it than…

Eli: I think that there will have to be some evolution in the standard to decide what to do when you combine those two things. Right now, mobile browser zooming is kind of just a layer on top of existing web standards, so everyone does something a little bit different with text re-flow and and…

Jeremy: I as an author can’t specify how I want the mobile browser to zoom.

Eli: So I’m trying to actually do some prototypes right now on some interesting things that we could do with fixed positioning and zooming together, but we don’t have anything done yet. We also …some of the things that we tried to do with fixed positioning on the existing browser, where it does zoom by the way, are very complicated because of the layout, so there are some limitations where you do have to fall back to the jumping behaviour that nobody likes but eventually does get you something fixed, but some of the partners that we’re working with on the frameworks, like jQuery, have started…

Jeremy: I’m going to stop you there, because it’s getting boring!

Eli: Okay.

Jeremy: I wanted to talk about calculating. Calculating, because, come on, time’s pressing; we don’t want to spend all the time on these technical things.

Eli: I’m sorry…

Jeremy: One more little quick technical question is when you’re calculating how big to make a page to fit on a mobile browser, I as an author can specify, in the meta element I can use the viewport width I can say device width whatever. Now for Opera, you also support a way for me to do that in the CSS, which is the @viewport …it’s not a selector, declaration block, whatever. Why? What’s wrong with the meta element?

Andreas: So …we felt strongly that …well the meta element was sort of a bit of a …well it’s a little bit of a hack to override specific browser behaviour. Originally it was defined by the iPhone; it came to other browsers as well. We also implemented it, played around with it a bit and then we felt, well this is actually more something that belongs in CSS because you’re controlling the layout, the width or …well, in a way…

Jeremy: So it’s like you’re crossing the streams by having this presentational instruction…

Andreas: …element inside the mark-up, yeah. So that’s what we were feeling, so we tried to work a lot on our viewport implementation, and he made, well, a proposal to the CSS working group called …I’m not sure any more what it’s called …device …sorry?

Audience member: Device Adaptation.

Andreas: Yeah, Device Adaptation, thank you. Device Adaptation and so that defines it at viewport rule where you put basically …it’s sort of a mapping of all the attribute …all the properties in the viewport metatag, but you convert them to CSS. So not all of it is the same, so a lot of them look similar; you have certain things that are different, like initial scale for instance becomes zoom, because I believe IE has a sort of zoom…

Jeremy: It does indeed

Andreas: Yeah, so we tried to see there what makes sense. I’m not sure yet if that’ll be the final naming but for now, so we implemented it like that.

JKIt makes sense if you put it like that, that it is …it’s presentational, so it doesn’t belong in the mark-up there.

Andreas: So the interesting thing is Patrick Lauke, one of the guys in my team, he’s been experimenting with using, well applying viewport conditionally dependent on media queries, so you can change the viewport dynamically depending on the size of the screen.

Jeremy: Because otherwise you’d have to use JavaScript to edit the meta element…

Andreas: Yeah, exactly, so…

Andreas: ….detection. I mean you must use server side detection, otherwise to set the right viewport size which can be a problem, and that’s also why viewport is kind of developing into a little bit of a monster with DPI and scalability and initial scale…

Jeremy: Do I detect that you’re wary of implementing it, perhaps?

Andrea: No, you’re wrong, because we have it in the C7 it’s already implemented, it’s at market in the US and it’s coming to 7-3, but we are facing pretty much the same problems where there are developers that design websites for the iPhone or for some specific Android devices supporting a certain width, and then it doesn’t work. We’ve seen funny pages where they define the viewport, they define you cannot scale it, even though without defining the width, so our device sets it right but then the images in the page are actually fixed width of exactly the size of the iPhone screen, so then the page looks odd ‘cos you have the text flowed right to fill the screen but the images don’t fit, so…

Andreas: We have exactly the same problem actually. We see a lot of sites that use, say first they use width 320, and then, oh they heard, width equals device which is better, but then they forgot to adjust your images and then everything starts becoming funky, once you look on it …look at it on screens that are not exactly iPhone sizes…

Jeremy: You guys any plans for this…

Eli: We do support the viewport metatag…

Jeremy: The meta tag; sure, but what about shifting it out…

Eli: We don’t support the CSS right now, just because there’s no real agreement on it and we’re…

Jeremy: Sorry, yes…

Eli: …watching what develops there.

Jeremy: Oh, I’m sorry; I mis-interpreted …I thought you were saying you supported …sorry. …disappointed now. So are Opera the only people that have…

Andreas: Yeah, …I think, I mean it’s a fairly recent specification so I’m not surprised that…

Andrea: Wasn’t the app meta tag something that came in the last few weeks as a W3C thing? I don’t know about when you guys implemented it, but…

Jeremy: In theory it does make sense, to take it out of mark-up and put it into the presentation there.

Eli: We at least have no fundamental opposition to…

Jeremy: That’s a good as I can hope for, I guess.

Eli: I mean the meta tag is turning into kind of a disaster right now. It was over-specified when Apple first released it, so everybody has different behaviour in the edge cases and so most of the sites out there were copied and pasted from a few early blog articles about hey, you should use this combination of things and everybody’s …especially behaviour under like specifying a height and then rotating the device, that kind of thing was different, so…

Andreas: Even something simple like the limiters between viewport values in the meta tag…

Jeremy: Right it’s commas, semi-colons…

Andreas: Yeah, so it’s please use commas; don’t use semi-colons. It’s not CSS. Because we’ve seen this on older Opera versions, I believe I believe Opera Mobile 9.5 or so; we only supported the commas and not the semi-colons, so then you won’t get viewport…

Eli: There’s a large number of top 50 sites that are using semi-colons, and it’s very annoying.

Jeremy: They’re making browsers hard!

Andreas: So there’s somebody who did this blog post, and everybody just copy pasted from there, and it continues haunting us…

Jeremy: I guess I don’t think it has enough credit. There’s a lot to consider that I guess I don’t …I don’t realise when I’m ragging on you guys. I mean …somebody …somebody wanted to bring up the subject of …DPI and media queries and resolutions, PPK, a certain somebody felt this might be an interesting subject, I dunno. Can’t say it’s something I’ve ever thought about, but it does seem like there’s a lot of variants, like which browsers report back different thing about DPI. Is that another sort of minefield of…

Andrea: It sometimes is and Nokia I think is the one actually most at risk because we do any possible screen size from tiny to big, so it gets complicated and the other things is that the user expects it just to work and so you end up in a minefield where you either do what the developers say, but then they design it for another device and it doesn’t quite work on yours, so the guy that just bought the new fresh phone, it doesn’t see …he doesn’t see nice …or you adapt it and then the developer is pissed because it doesn’t do what the developer said, because there are a lot of sites that define the width. For example using viewport, they say it’s not scalable, then we have devices with a high DPI, what do we do? We show it this small or we adapt it and piss off the developer, and there’s…

Jeremy: Damned if you do; damned if you don’t…

Andrea: Yes.

Jeremy: I mean …so this kind of keeps coming up a lot; it keeps saying developers make a site for mobile but actually what they’re making the site for is iOS, maybe Android. I mean, I came up on one of the slides today as well. I sense frustration. I sense a certain amount of frustration. How do you deal with that? Do you just …are you always going to be playing catch-up to iOS and Android; not because of their preference but because that’s what developers are developing for? I mean Opera on the desktop, you had this situation on the desktop where you had to fake your UA string, or…

Andreas: Yeah. So we’ve a lot of experience with that. It’s not …it’s not easy. We obviously don’t want to be, well, running after developers and say, hey, hey, don’t forget about Opera and adapt your code. A good start …well what we often see is that developers only test in Webkit so they use dash Webkit dash prefix properties and so that, well obviously it doesn’t work in any other, well, in non-Webkit browsers, so good practice there is to just include everything and include also generic fall-backs, those kind of things, so we try to document it, talk about it…

Jeremy: Opera’s a good resource for this

Andreas: Yeah, so that’s what we try to do and yeah, so it’s a matter of education I think and …and I think also, well the more devices we’ll see right now, it’s only the iPhone or the iPad that they’ve bought and they’re looking at, but I think also the Android devices are, say the Blackberry Playbook, it’s great to see some competition in this space because that will force them to see, oh this is also very compelling and interesting device; I shouldn’t only look at …at iPhone or i-devices to develop on, because there’s a much wider gamut of devices out there that people …

Jeremy: …people will start to realise…

Andreas: And I think, well, say in the developing world or in …in markets with a low …where Apple’s penetration is lower, we’ll see this is much more important so…

Jeremy: I mean, so Eli and Andrea, do you have it a little bit easier because you are Webkit based, and so there is a lot of commonality with somebody develops a site and only tests on IOS or Android; maybe both.

Eli: One of our biggest problems on Playbook with that is that people are UA string detecting and not sending us the page that they designed for iPad, and if they just sent us the page that they designed for iPad it would be fine, so we have a fair amount of work talking to content developers and making them not send us WML, but …so this question of Webkit compatibility across everything I think is pretty good.

Also, to get back to the original question a little bit, DPI adjustments, so Android put in some target density DPI actually into the meta viewport tag to deal with the fact that there are multiple classes of Android devices, right, and we are in a similar situation to Nokia in that we have devices with a wide range of screen resolutions and densities, so we’re basically going down a similar path to what Android has done with the target density meta viewport, but in general we try not to do hacks like pretend we’re 320 pixels wide and scale it, or anything like that, tell you what we are and all of the JavaScript functions return the real numbers and you can design your site to do the right thing.

Jeremy: So this does bring up the whole question of UA sniffing. A useful tool for developers or spawn of Satan. Which is it?

Eli: I have a very hard line on UA string detecting. I think that there are good reasons why you would want to do some server side detection of…

Jeremy: Were you around in the 90s?

Eli: Yes. And it was definitely abused, but I mean we have people who are on very …plans where their data is very expensive and so sending down a lot of JavaScript code to detect what they are and adapt it run-time isn’t necessarily the best option for everybody, but we would love people to do less drastic things with UA string detecting than they’re doing now.

Jeremy: I would take it that Opera would not be a fan of…

Andreas: Yeah, so we’re also not a fan. We recommend developers to do feature detection, see if capabilities are available on the …in the browser on the devices and otherwise serve fallback content, so that’s what we generally recommend. We have a lot of issues also with UA sniffing gone wrong. For instance, if you look at our UA string, it starts Opera 9.8 and then will end with Version 11.10. You’ll wonder why is that. The reason is because if we would say Opera 11.10 in the beginning, there are certain JavaScript scripts that interpret 11 as 1 because they only read the first digit and then we don’t get…

Jeremy: They tell you to upgrade to …Explorer 3 or something…

Andreas: So they say, please upgrade because you’re in, I don’t know, in 1996 or so …so yeah, it’s very rough and actually every release that we do, there’s a whole discussion always about what are we going to do with the user agent string; should we call it like this or like that and yeah…

Jeremy: Somebody tweeted about this recently, the user agent string isn’t just a user agent string. It’s a history of the Web…

Andreas: Yeah, so for Opera Mini that runs on tablets, we had to call it …we couldn’t call it Opera Mini Tablet, because otherwise we would get Opera Mini Content. We couldn’t call it Opera Tablet Mini, because then we would get Opera Tablet content that possibly wouldn’t work, so we called it Opera Mini Tablet, which is very weird. I proposed calling it Opera Maxi, but nobody liked that …it became Opera Mini Tablet.

Jeremy: But in general, can we agree that feature detection is going to be better than browser detection?

Andrea: Well at Nokia we don’t preclude anything and in the documentation we’re always going to explain exactly how to detect even the individual browser or platform if you want to do that.

Jeremy: You don’t take any moral stand on that, whether you’re doing a good thing or a bad thing; whether you’re educating or mis-educating developers by doing that?

Andrea: Well we work with the W3C standards and we provide all the means to also use feature detection if you like it better that way, and of course sometimes people just attack Nokia as the first five characters and send us WML, and that’s a shame, but it goes with education as well.

Jeremy: You say that, on the one hand you’re saying, well we leave it up to the developers; you can do feature detection; you can do user agent detection, but then I’m hearing these horror stories from you guys about bad scripts the developers wrote because they copy and pasted some code. You can’t have it both ways. I think maybe you should take a stand. Maybe you should like have a position on this and say, we think this is the right way to do it, and this is not so right. Evil even, one might say, but no, you’re going to be totally agnostic about it …you’re gonna…

Andrea: Things can go wrong in any way; you can feature detect it wrong or you can …or JavaScript broken or …so…

Jeremy: You’re being very diplomatic. You’re being Switzerland here if you like! “I don’t want to come down on one side or the other.” I think Opera, you kind of do some education, some outreach in saying, in terms of best practices, that’s what we’re talking about here rather than what you can do.

Andreas: Well I would say today it’s a better practice to do feature detection.

Jeremy: You would say that? You would say that on the website?

Andreas: I say it here on stage.

Jeremy: Okay, it would be good to see that written down in the documentation for developers.

Andreas: It might come.

Jeremy: Good, that would be …this does bring up the whole issue of outreach and education for developers, like me I need to know about this stuff. What do you do? What resource have you got? I’m familiar with Opera’s Dev site. I haven’t been to…

Eli: On the Devs on there’s a fair amount of content for … both reference content for how the web engines work on 6-0 and 5-0, and on best practices. We also have a number of people at different web conferences giving talks on dos and don’ts of the mobile web and that kind of thing.

Jeremy: Good. Glad to hear it. Yeah …that’s good. In terms of outreach, somebody …it came up again today, the sheer cost of trying to test on so many mobile devices. It is prohibitive and so you can hardly blame developers when they do only test on the iPhone or the Android phone that they have in front of them. You guys want to give away any free phones to developers?

Eli: We are giving away free phones.

Jeremy: Yeah. As a policy, anything along those lines …well for example, let me tell you; there’s a project being set up in Portland right now where a bunch of different agencies will pool together to create essentially a pool of mobile devices that people could share. Now, to be interested in supporting projects like contributing devices. Be good PR; be really good PR for your company.

Andrea: Nokia has a programme actually called Remote Device Access. It works pretty much like Device Anywhere and it’s free; you just book some time and we have one or two hundred devices…

Jeremy: Is there much paperwork involved? Shipping papers…

Andrea: No. No paper. No, you book the time online …you just go in and you say, I want to try a Nokia N8 and it tells you we have these slots at this time, today, tomorrow, whatever. You can book I think a few days in advance like…

Jeremy: Where do I physically need to be to do that?

Andrea: Anywhere. On internet. It’s a Java outlet in your browser.

Jeremy: Okay. In terms of getting hold of an actual device, getting hold of a phone. Getting phones into the hands of developers

Andrea: We’re not doing it, but I think if I recall correctly there’s a company in France that does that. It’s a …again it’s a consortium of a bunch of companies that did that, and you buy a subscription for like 100 euro a year and then you can just go there and try the phones or you can get them to test it for you.

Jeremy: Because I’m very intrigued by this idea of having a community pool of devices to test, so I’m watching the Portland experiment with great interest. I might try and start it up in Brighton if a few guys could help out …send us some phones …it’d be good.

Okay, you don’t want to commit yourselves I see. That’s fine; that’s fine, you don’t know …what I’m not getting for Christmas!

Andreas: I don’t know; maybe it’s worth mentioning here so we …well, being a browser maker, we don’t have …we have to buy these devices ourselves as well, so we don’t …we’re not ready to give them away, but what we’ve been working on, and it’s going to be released soon, is we have an Opera Mobile emulator which is another emulator, we just call them emulator because that’s the easiest way to explain it. It’s basically Opera Mobile running on your desktop, and you can choose a profile and DPI and all kinds of zoom settings or keypad input, touch input or whatnot, and then just run it on your desktop, basically, and it would show, well what it would do on the phone, so in a way that’s maybe even more useful than the actual device, and it has…

Jeremy: The word emulator generally has bad connotations for most of us I think.

Andreas: It sounds a bit scary but it’s actually better than you would think, So if you haven’t tried it yet…

Jeremy: I’ll give it a try, yeah. But I’d still like phones. Phones would be nice.

Listen. We’ll open up to the audience now if you’re ready, I’ll just ask one more question, …get ready for your questions, because I’ve kind of kept steering you guys away from this. You clearly want to talk about it, about this whole idea of taking a website web app and wrapping it up in something, some wrapper, that you can then stick it on your home screen and “ooohh, now it’s like a native app; isn’t that wonderful?” So what do you …what are you getting behind there? Are you …can we standardise on something here or are you all going different proprietary directions? What’s the wrapper that I can have on Nokia to make my website into a…

Andrea: Right now, today, you can develop a Qt application and can be just merely a wrapper that starts Qt Webkit and that gives you access already to HTML5 device APIs through the Qt Mobility and you do have access to that type of information, and we still have active in the devices the WRT, Web Run Time, with the browser update it will also update the Webkit engine behind it, and it also allows you to …collect all your requests. It was quite interesting earlier talking about permissions do you want to give me access to contacts? Yes, and position, and this and that. Finally, we are going to have one request for everything in WRT for whatever it is, and then of course we are looking into WAC if we have to and what is the interest there.

Jeremy: With Opera I think you’ve shown a lot of interest in a W3C widget spec, right?

Andreas: Yeah. So we’ve been driving that for a while. We’ve sold widget runtimes to a number of operators such as Vodafone. We have also a project on WAC with Telenor; there’s co-operation with other telephone operators as well, but so they maintain an eco-system of apps built with standards so you’re basically built with whatever you usually use for websites, and then wrap it up in W3C widgets as a W3C widget and upload it to their store, so that’s how it works, so this is …well …well the problem or …it doesn’t have that much visibility because very often this is tied to certain specific markets and say for instance, Vodafone is active …well not only in the UK but in a lot of other markets as well, so it doesn’t get, I know for instance they shipped mini widgets in certain markets in Africa which nobody here has hear about, but …they’re known, so there are a number of ways on building apps and getting access to, well…

Jeremy: Wrapping it up…

Andreas: Yeah, exactly. Wrapping it up and…

Jeremy: You decided not to go to W3C widget spec?

Eli: We have our WebWorks, both on hand-held back to 5-0 and on Playbook. WebWorks is …very, very similar to W3C widgets…

Jeremy: They all sound very similar.

Eli: It’s basically a superset that includes the security and permissions aspects that that standard doesn’t cover, and right now we’re seeing huge, huge uptake of WebWorks applications, so I think right now the numbers are over 25% of apps submitted on the Blackberry for Playbook are web apps.

Jeremy: And I do understand …I do understand why people want to have an app: “…pick me; pick me; put me on your home screen. Make my website into an app so you can put it on your home screen”, but I mean I wonder, this desire to create all these separate silos of standalone applications that sit on your home screen. Don’t we then lose some of what makes the web great? Addressability; linkabilty; the fact that you have a URL, the fact that anybody could link to that. How do I link to an app? Anybody else think that it’s not this wonderful gold-rush of standalone apps, that we’re losing the very thing that makes the web great?

Just me?

Eli: Oh I think that there’s…


Jeremy: Thank you!

Eli: I think that there’s also a range, so from opening up your browser and typing in a URL to a full-fledged application that you can’t tell isn’t native. There are like say the home screen type things; Apple’s done a little bit of work there and we have support for that on all of our platforms now, where you can take a website and save it to the home screen and then using some meta tags you can override what the icon is and that kind of thing, so you can have a a half-way app.

Jeremy: You can’t link to.

Eli: Well, to some extent that’s a URL, so you could link to it. But I don’t really know what it means to link to an app.

Jeremy: Exactly. That’s kinda the point!

Eli: It’s not like there’s something that people wanna do that we’re not enabling. I don’t know what it is.

Jeremy: That’s what surprised me. That people do what to do this, I guess, it’s like we had CD-Roms. They kinda sucked. Now we had the Web, it was awesome and we’re like, “no, let’s go back to having individual things that can’t communicate with other things.” It surprises me. It surprised me that there’s this desire.

I guess maybe there’s a monetisation thing, the fact you can wrap it up and sell it for money. I mean you clearly do see a desire as well; you see lots of people want to do this, want to build standalone …wrapped up…

Andrea: Well, definitely users like the idea of the application installed as the home screen button or, for example, on Symbian you can have this WebClip space in your home screen, so…

Jeremy: Citation need. I think I’d like to see the numbers, how many actually get added to the home screen, from users, but that would be a big study.

Andrea: Well it’s hard to tell ‘cos we don’t look into the…

Jeremy: Isn’t there a danger which is perpetuating it, like we’re just saying, “oh, users want to have things that behave like apps, so we’re going to allow developers to make websites but then wrap them up, behave as apps, let sit on a home screen,” and then users come to expect that, because the reason why users want something that’s an app because they’ve learned, when they first turned on their mobile phone a couple of years ago, that “oh the web sucks when I use my mobile device”, and actually that’s no longer the case. The web on a mobile device can be awesome, but we’re encouraging the cycle of, “oh you don’t want to go to the browsers, woo-hoo, no; don’t type in a URL, oooh no; nasty. You want something nice and wrapped up on the home screen.”

Eli: Device APIs aside, save to home screen plus app cache plus local storage is pretty much an app, but it’s a website, right; it’s all web technologies and there’s a URL and all of that sort of thing.

Jeremy: And all of that should be do-able in the browser as well? I mean app cache?

Eli: Yeah, and all, I mean on our platforms, all of that is do-able in the browser.

Jeremy: So maybe we will see less of them; we’ll see this …this craze for adding to home screen fade out as people realise, actually I need one app on my home screen; that’s my web browser.

Okay. That’s my little rant over. Questions. Let’s see some hands up.

Oooh, I definitely want to get a question down here. So at the very back of the room; very, very back. Keep the hand up please …Liza, if you could keep your hand up so that we …there we go. That’s great.

Lyza: Hi. I’m one of the people in Portland. I have a question for people who suggest remote device testing. Have you every tried it?


As Brian Leroux would say, it made me want to set myself on fire. So I’m hoping that we can convince some of the device manufacturers and carriers that this is a real winning situation for everyone. We wanna make stuff, so we hope we can work with you and get some great devices. Thanks.


Jeremy: Any responses?

You don’t have to respond. You can just sit here and take it, you know.

Fine; that’s good.

Andrea: I did try the remote device access; sure, it is not as having a device but for example, I don’t pay for data if I use the remote device access, and I can test a range of devices, a range of networks; yeah, having the device, having someone bring in the device to me at home or shipping me to Norway to test it would be better.

Jeremy: You can’t beat it, right …you gotta …nothing beats having the phone in your hand. Okay, any other? We got one here, okay.

Audience member: I have a question…

Could you bring the microphone closer to your mouth?

Audience member: Sorry; I have a question for Andrea Trasetti. You mentioned the new browser, the new Webkit browser at Nokia. How many of the existing devices will be updatable to that version and how will those updates be pushed?

Andrea: Yeah. So the browser update is going to be for all Symbian 3 devices, and all …S-65th edition and 3rd edition, which means the old Symbian devices that had the touch screen and the generation just before that, so we’re talking like up to 3 devices, so about 3, 2 or 3 years ago, and for Symbian, sorry for Symbian 3, the update will be pushed as a suggested update for the whole range, so when you plug in your phone and you have the Ovi suite running you can get it, or you can get the over the air update, and for the other systems it will just be the browser that gets updated.

Jeremy: That brings up the whole question of auto-updates. Do you do it? If not, why not? I mean do you, with Blackberry would you automatically push out an update without asking?

Eli: Historically on the hand-helds, we haven’t done a lot of in-market updating. Most devices have gotten about one update, a major update, but about one update in its life-cycle, and with Playbook, I hope we’re convincing people that we are changing that drastically, so it’s been out for about three weeks and there’s been three major updates so far.

Jeremy: But it doesn’t happen automatically?

Eli: Oh, you get a notification that there is an update and then you can click Yes.

Jeremy: I guess …with Opera you may be in a tougher position because you don’t …you don’t have access to the hardware?

Andreas: No, but well, say for instance the Android market allows you to push updates and so we’re pretty confident that, I think, well most of the user base on Android, will get the latest version sooner or later, so that …yeah, that’s the way we update. There’s also one other way which is …we have this mechanism which is in the browser; it’s a sort of huge Javascript file that includes a number of small tweaks and patches for websites that don’t function properly in Opera because they …I don’t know, the serve us the wrong content or they think we are …you know…

Jeremy: So you constantly need to keep that updated?

Andreas: So yeah, we keep that updated; we keep …we maintain that. So that’s …but those are small tweaks but those go live just the user doesn’t need to do anything; this just happens automatically.

Jeremy: I mean I think in general, auto-updating is probably a good idea. I mean, mobile, desktop seems …that does seem to be that Trident Chrome, just updates constantly.

Andreas: There’s a big trend but it’s also good because it allows …it makes web developers’ life easier because they don’t have to think about …oh, this doesn’t work on whatever just a few betas back, a point one version back it doesn’t work and now it does work, and how many users are still on that old version, so it’s very good I think.

Jeremy: Yeah. If only we could invent a time machine and go back to Redmond and convince them that that would’ve been a great thing to do with Internet Explorer!

Ah …we had a follow on…

Audience member: Yeah, just one more thing, regarding what …regarding the previous question. Do you really …do you really know what developing goes through when we do developing testing for mobile, because I was in this particular situation; we had to test and we wanted to include more devices that we support, so we went through tests for cloud …cloud based testing and desktop apps that support different the ones that support iOS and everything, we tried everything, and it’s not working.

Jeremy: It’s not the same

Audience member: It’s not the working, so are you going to do anything about it to help us?

Jeremy: So I hope you guys are getting the message here, right?

Eli: We’ve been getting this message for a long time, especially from the web community. We know that web developers like using Notepad and Firefox on their desktop to do all of their development, and that message has strongly gotten across to the tooling teams at RIM. We know that people don’t like our simulators, so stay tuned.

Jeremy: You kinda get a free pass because you don’t make hardware, but I mean also I will …I will say we can meet them halfway, and projects like the Portland community project, and I’d like to maybe try my hand at starting one up in Brighton would be good. If there was a discount rate or something…

Eli: I personally try to give away as many devices as they let me, but…

Jeremy: I’ll get your card later, that’d be really useful. Okay, good.

Andrea: Nokia actually has a programme. It requires paperwork, but you can get advance devices and discounted devices. It’s called LaunchPad.

Jeremy: So I think we as developers, maybe we need to start a Wiki or something, so we can get together with people in your local community; it could be just a good community project generally and say let’s build a pool of devices. And then maybe they can meet us halfway in terms of giving us discounted or free devices.

We have another question over here. Jen.

Jen: One of the things that maybe could be done is something like Neighbourhood Goods could be used as a way to trade back devices, because I have a closet right now of devices and if someone in the LA area needed to borrow…

Jeremy: So NeighbourGoods.net…

Jen: Neighbourhoodgood.net. It’s Micky Krimmel’s project.

Jeremy: I think that’s US only, right?

Jen: Yeah, but I think they’re expanding.

Jeremy: Okay, NeighbourGoods is basically like …you go on …I need a drill, and somebody else says, I have a drill. That’s pretty much it, and it’s really, really useful. No, that’s …it’s awesome. That is genuinely disruptive technology and doing that for mobile phones …it sounds simple but …that would be awesome. It is …it’s awesome. NeighbourGoods is awesome.

Who was first, over here?

Audience member: I have a question, I’m aware it’s a very big one, and the big player on it is not here, being Apple, but so far, nothing really has been said about the micro problems of typography, webfonts, and there’s a lot being done but there is way more to be done, and especially on micro devices like simple things, hyphenation, which …small columns and narrow type, is especially something to be addressed, but finding in hyphenated words which is not …not sufficiently covered. Font face; yes there are …there is some consistency about font files now, although it’s not …it’s not open type at all. How about open type features; how about kerning; how about being sure that text flows equally on different browsers, that’s …I’m aware it’s a very big question.

Jeremy: It has to be said that having heard what goes into making a mobile browser today, and trying to figure out how much space to allocate, and zooming and all the stuff, it does sound very, very hard to figure it out. But I will also say that when we talk about mobile development, we do tend to focus on apps and we’re talking about device APIs; obviously we are about that. But the reading experience is neglected, I would say.

Now whether this is at a device level or a browser level, this does speak to larger issues. Where do you prioritise? Where do you decide to put your efforts? Do you say, okay, we’ve got to really work on getting these sexy device APIs into the next release, or do you say let’s work on good hyphenation, web fonts, support for the shy-hyphen, something like that. How do you prioritise features and where does good typography fall in your priority list? Eli?

Eli: So …for Playbook, the original release there and for Blackberry 7, our biggest focus is on graphics performance. It’s been a major thing that people wanted better CSS animations, that sort of better SVG rendering, that kind of thing, but definitely typography is on my list.

Jeremy: Okay. It’s on your personal…

Eli: It’s on my personal list.

Jeremy: Is there a list, like a public list, of “this is what RIM plans to support in the next release, which will be released on this date and this is what we’ll have?”

Eli: No.

Jeremy: You know I think that might be useful.

Eli: Sure.


Jeremy: Let me re-phrase the question! Why don’t you have …a milestone list or just a, “here’s what’s coming in the next release” document, publicly?

Eli: That’s a good question. I don’t have the answer for you; I’m sorry.

Jeremy: Okay. I mean to be fair, they aren’t the only ones that’d clam up when it comes to release cycles or what’s going to be in the next version, but I think most companies are not doing it because most companies are not doing it. In other words, they look around and see, well our competition isn’t saying anything. We’d better keep schtum about what we plan to release. Do you publish milestones and do you put like, yes we’re gonna have web fonts in this next release, then we’re gonna do…

Andreas: Yeah, so at Opera Development, so it happens on a number of checks at the same time, so there’s a core engine that is being developed constantly, and so they release regular milestones. Older documentation is published on Opera.com/core …no Opera.com/docs/specs, and so that’s usually ahead …a little bit ahead of what you see in the actual Opera browser, and desktop, and even more ahead for Mobile, so because Mobile is…

Jeremy: So you’re seeing what’s coming down the line?

Andreas: Yeah, so you can …you can see there and say, hey there is support coming out for this or that feature, and that’s probably going to land soon in a desktop or Opera Mobile, that it will be released soon, so that gives you an idea. I think the problem with …so we try to document that keep it as up to date as possible, and so for the ones really interested, it’s the …you look in the user agent string, there’s a …there’s a last digits; right now we are about at milestone 130, no, 141 I believe, and Mobile is at 81, so there is a bunch of things in the pipeline actually, and looking at that, you can see that say for instance gradients, gradients will come to Mobile soon and things like that, so that gives you a preview. I think the reason, and that’s probably also true for …for everybody, at least for Opera, I think we …well we don’t really announce like we’re going to release then with these and these features, because very often this changes so much that even internally, we sometimes have a hard time keeping up like “is that in or not?”

Jeremy: So you don’t even know…

Andreas: Yeah, so sometimes it’s in the core, it’s in Presto, but there’s platform work needed. Say for instance video’s a typical example. There could be video support but if you’re not doing anything intelligent with handing over the video to the native player, then it’s not going to work, and so there’s more, and so because of the standard support becoming more and more complex, and it’s not only about hey, this isn’t a rendering engine and now, I don’t know, both texts with b text around it is now bold and that works everywhere…

Jeremy: So you’re just trying to protect …you don’t want to hurt us by saying, oh…

Andreas: Well maybe, yeah, sort of to keep expectations in check I think, and simply sometimes because we don’t know ourselves, so it comes along and sometimes things take more time than others, and so that’s why there’s a bit of uncertainty, I think.

Jeremy: In general though, Andrea, how do you decide what to prioritise? Is it, do you listen to what web developers are asking for, or are you always playing catch-up and looking what’s out there on the web, because web developers are actually just making sites for iPhone and Android and just making sure your browser can render those sites? How do you prioritise?

Andrea: It’s a combination of many things, so we try to collect feedback as much as we can from the full Nokia perspective…

Jeremy: From blogs, mailing lists, Twitter? Where do you look for this?

Andrea: Anywhere. I mean conferences and meeting people and talking and listening about what people talk about in conferences and stuff like that, so we try to listen, keep our ears open. We also have the platform, so since we’re developing everything from the hardware to the highest layers, it also depends on whatever chips are in the next devices, whatever libraries are included in the next devices, so for example, font faces whatever is pre-installed in the platform is what comes in the browser, and the browser doesn’t have the freedom of saying, hey we also want this other font face because it’s cool.

Jeremy: Well, that’s fonts as opposed to @font-faced; they are two separate things. You’re talking about the system fonts that you get?

Andrea: Yes

Jeremy: Okay.

Andrea: That’s something different.

Jeremy: Okay.

Andrea: So the browser doesn’t have the freedom of saying, we want to add another one, of course the installing third party’s another thing.

Okay. And do you guys publish a road map of here’s what we plan?

Andrea: No.

Jeremy: Interesting.

Eli: I guess maybe one more point to that is that we do track upstream Webkit right now, so …so does the Android port, so

Jeremy: That’s the place to look?

Eli: That is a good place to get an idea about what’s coming in the relatively near term, because we regularly take commits from there, but steering the direction of the Webkit project for future stuff also will of course steer anything that uses Webkit as a rendering agent.

Jeremy: Okay, so if we want to see what’s coming in the next versions of RIM, Nokia, we just need to look at the release notes for the last versions of iPhone and Android.

Eli: Well, as I said, iPhone and Android are both very forked so…


Jeremy: That was kinda mean?

Eli: Yes


Jeremy: Do we have any more questions from the audience? These are good. These are great questions by the way.

We do have one, right here.

Audience member: Okay, I have a lot of questions, but yeah, first, Apple isn’t here so…

Jeremy: Apple isn’t here, is that what you’re saying?

Audience member: No, I was saying Apple don’t have too, so you don’t know what they’re going to release. That’s it. Then …

Jeremy: Okay.

Audience member: The thing is, when are you going to release video and audio, because like externalising it to native apps isn’t HTML5

Jeremy: I think the problem is that asking these guys for a date when are you going to implement this feature, that feature, I could sit here and do that but I don’t think I’m going to get answers, right, if I sat asking about specific features. So maybe that’s not a productive line to go down because …it’s going to be frustrating for us; it’s going to be frustrating for them. I think we just have to accept that we’ll get ‘em when we get ‘em. But it’s valuable feedback for them to know that we want this stuff.

Andreas: Yeah, I think it’s …at Opera so I didn’t answer to that part of your question actually Jeremy. We also look at, well of course, what is happening in the industry where there’s developer momentum, and very much so that’s what my team and myself, we go to a lot of conferences, we try to talk to a lot of people and here, say for instance what people constantly complain to us about is for HTML5 forums that they want to have stylable forms and the calendar drop-down, why can’t …why isn’t it stylable, so we’re making a proposal for a core team. It’s not there yet, but we made a proposal, we influence their decision process.

Jeremy: Because you’re hearing it from developers?

Andreas: Because we hear it from developers, so we have sort of a bit of a direct line to our core team where we …where we give them feedback. It doesn’t always mean that it’s okay straight away, drop everything, we implement this, but it’s definitely …well we have a say there in sort of the prioritisation. So that’s all your feedback definitely helps, so let us know if you’re frustrated with stuff, let us know and then we look what we can do.

Jeremy: There is also the conspiracy theory of why things take a while to get into the browser, which is that when you have this essentially competition within the same device between stuff you can do in the web browser and stuff you can do natively in an app, and the app store is where money is made from selling apps, that maybe the company, maybe the boss man wants to keep the browser weak so it doesn’t threaten the business model. Is that pure tinfoil hat conspiracy theory stuff?

Oh. Silence.


Silence speaks volumes.


Come on; surely …surely not?

Eli: I want the browser to be as good as it can possibly be.

Andreas: I think we do, yes, but…

Eli: I think we’re probably aligned on that, and we are not…

Jeremy: Do you mean your company?

Eli: I mean …we …and …we’re not doing anything to make the web engine used to render apps worse than the web engine to render browser or anything like that.

Jeremy: Okay.

Andrea: I agree with him and in particular in Nokia, I mean the browser is relying on the libraries that the platform offers so the browser can only be as good s the platform.

Jeremy: Okay. I was expecting maybe stronger push like, “that’s a ridiculous suggestion!”

Andrea: No. Why would we limit any platform?

Jeremy: Okay, good. Maybe the conspiracy theorists are onto something.

Sorry, there was another question…

Audience member: Thanks. Yep. As a disclaimer I’m in by no means fan of …user agent sniffing or for …feature detection…

Jeremy: You’re going to say ‘but’, aren’t you? You’re going to say ‘but’. It’s like, “I’m not a racist, but” …Sorry, that was totally inappropriate!

Audience member: So one of the main problems I think not only I am facing is sending appropriate sized images to a browser, so it’s not that important which JavaScript APIs a browser supports. That I can figure out on the device itself. Sorry …but are there any plans to that let browser …let the server know which, for example, string size it has?

Andrea: String size is supported in JavaScript since 1985…

Audience member: Yeah. I would love to support devices without relying on JavaScript enabled.

Eli: So we’ve always …not always, but up until 5-0, the definitive Blackberry approved way to detect what Blackberry you were on was to check the XY profile header, which points to a URL that everybody ignores, but points to an XML file that describes the device, so we’re still sending the XY profile header and you could use it as a key to find that if you wanted to do server side detection.

Jeremy: Interesting. I’m not sure if that’s evil or not.


Sounds like I might be able sleep at night if I did that…

Andreas: So for Opera, you could use Media Queries and surf other content, and the content is only downloaded if the media query is applied, so…

Jeremy: But that isn’t all browsers, is it?

Andreas: That’s not on all browsers, no, but Opera does that, so that helps you actually, so you can surf different versions of the same image and only have the one downloaded that is actually needed on your page.

Jeremy: And I do share your frustration. I wish we didn’t have to rely on things like JavaScript to have to figure out which images to serve, but it probably is the best solution for now and Scott, Scott Jehl was going to have some more…

Audience member: I’m looking forward to it. Just one …one remark to …Media Queries …the problem remains with, for example, images that are within the HTML code.

Jeremy: Rather than background images?

Audience member: Background images are not the problem, but content images are the problem.

Jeremy: I agree. I agree it’s an issue, but it’s also what makes it a very exciting time for web development that we’re trying to figure this stuff out, right? It’s an exciting time.

I sense people are getting restless. I sense like people are starting to want beer, but we’ve got a question over here. Do we have more questions to come or are we starting to feel like it’s getting towards …like I said, this is very open-ended I could stay here all night!

Let’s hear what the next question is.

Audience member: Actually great that you mentioned this project at Portland because we have the same issue with buying mobiles and all that. We buy a lot of mobiles, we have this pain so I actually thought like we should start up something local to share among, but that’s just not the question.

Jeremy: Where are you based?

Audience member: We’re based in Munich …Germany, Amsterdam, so we’re around European area. RIM is really good supporting by sending devices, so they’re doing a good job there, but the question actually …is the …we have a lot of screen sizes, we get a lot of devices with different resolutions and all that, so is the actual solution to that, and I would be a really big fan of it, I had the pleasure to work with one of the RIM times that did it right, in my eyes, to use exact units so a button should be one cm wide and one cm big …high, because my finger does never scale, but if I as a developer have to think of that all the time, like okay, I get a small device or get big device, whatever, I want the button to be the button and be clickable, and by using touch interfaces, so it becomes more relevant…

Jeremy: So because your finger isn’t made of pixels, then…

Audience member: Exactly. Yes. Make cms or inches or mms, make this work …I know it’s hard, but I don’t see an effort on going in this direction. Is that something that should be done? I mean, will this be done?

Jeremy: This goes back to the tougher question of figuring out how big is a pixel, right DPI stuff, it’s a hard problem…

I think there’s a fundamental conflict on mobile between zooming and physical sizes, because people …sometimes assume that the zoom level that you’ve loaded the page at when you type in the URL and finish loading is 1.0, and therefore if you say it should be 1 inch by 1 inch and you load the page, that it’ll be 1 inch by 1 inch, but that’s almost never true, and we can’t make it true because people don’t design their content that way.

Hang on for the microphone, just a second.

Audience member: On an interface, things like buttons, drop-downs, anything else that is functional, shouldn’t those be just made for the fingers and the other stuff should be zoomable.

Andreas: But then if you zoom in you would get everything to be zoomed in and the button would stay the same size.

Audience member: Well yes, right now, yes. But why don’t we think about it in a different way?

Eli: So are you specifically asking about some sort of way of making an element on the page not zoom with the rest of the page?

Audience member: Absolutely. Functional elements should…

Eli: I think that that’s a very interesting question. And we are working on stuff.

Jeremy: And in a way it harks back to what you were saying about position fixed.

Eli: Right. It’s the same sort of thing that I was talking about with position fixed, where having some elements of the page zoom according to the mobile browser and some not is a very interesting idea.

Andrea: But it needs to be thought through to avoid monster evolution like the viewport where now the viewport supports scalability DPI width, height and the different combinations generates sometimes effects that you wouldn’t want.

Eli: Absolutely.

Audience member: But if you would layer you entire page with centimetres, it would work, but actually what I was trying to say also, bringing up another example that is not mine, besides my finger doesn’t scale, the other example is actually Robin from W3C, he brought us up and he said, think of a use case that you have a mobile and you want to buy a ring. You just take your ring off the finger, put it on the screen and size whatever you see on the screen to exactly that size. Then it has to fit because it has to be in a proper unit. And I thought like, yeah, that’s really reasonable.

Jeremy: If the browser knows how big a pixel is, I guess.

Audience member: You may still want buttons or clickable elements on a much bigger or accessibility…

Jeremy: I feel …I feel like we’re bike-shedding now. We’re kind of starting to go down a rabbit hole. Someone jump in if you’ve got a separate question …okay, you’ve got a completely different question here …or did someone else have the mic?

Audience member: My question’s about responsive web design, currently what we have, what we call responsive web design is simply responding to the size of the device, the size of the screen on the device as we’ve heard from Stephanie. We can’t deduce anything about the context from that. All we know about the context from that is that we know nothing about the context.

Jeremy: Yeah, but I mean responsive web design doesn’t cure cancer either, but …it could be because it never claimed to cure cancer. It also never claimed to solve the context problem.

Audience member: But we need to solve the context problem to take responsive web design onto the next level.

Jeremy: I think it’s orthogonal. I think it’s a good thing it’s a separate question.

Audience member: Yeah, but my question is to the browser manufacturers. Is there anything you can do to help us solve the context problem and if so, what?

Jeremy: You mean, as in providing, giving us information about the user’s context?

Audience member: Exactly, yes.

Jeremy: Okay, is there anything you could give us? Because right now we’re inferring …we’re trying to infer context from the fact that it’s a small screen, and we’ll say, well, they’re probably narrow bandwidth. Bandwidth. Can you tell us? Do you have any way of knowing? Can you get that information to developers?

Eli: We do have a JavaScript object that tells you whether you’re on wifi or on cellular.

Andreas: So device APIs which would help there to provide more context, so say battery life or …or …cellometer or wifi…

Andrea: Sven also mentioned the system info, W3C work that is around; sensor lights but also network speed, network connection, am I online or not; this is all work that is happening right now in the standards and experimenting. There isn’t nothing really out there definitive available and solid that you can rely on, but it is coming, and then Nokia also had some experimental native application that had I think some interesting aspects where basically they were putting together a bunch of elements that the device knows about, like what time is it? Do I have appointments? Does the sensor light see that there is light or is it completely dark, and based on that, it is adapting the type of ring-tone that you have so if it is night, and there’s no light, it goes on mute because you’re probably sleeping.

Jeremy: It’d be pretty awesome to get that information to the front end so we as developers could serve up a different style sheet depending on the amount of available light or something…

Andrea: It is something that is right now I would say in R&D stage but it is coming. It is something definitely we are looking into.

Jeremy: That could be very exciting. Yeah, that could be really neat.

How are we doing on questions? Any more or should I …oh yeah, there’s …Jen’s hogging the microphone over here.

Jen: I’m sorry, Martha and I have been twittering, and it just hit both of us it would be really cool, I know quite a few big, interactive agencies do keep a library of devices in house, so if you’re at one of those agencies, please consider maybe once a week on a Friday afternoon having two or three open hours that people from the community of developers could come in and with your permission, sitting in house, do testing and if you guys have a beer Friday just have them bring the beer!

Jeremy: Sounds good!


Jeremy: On the subject of beer, I gotta say…

Jen: I was just going to say, or charge for it; I’d be happy to pay a monthly fee to someone who would have that. I would pay a lot of money every month to be able to test on a lot of the devices, so…

Jeremy: Yeah, you could monetise that shit!

Jen: Make an app of it! Make an app for it

Jeremy: You could make an app for that. Yeah, have device: need device.


Is anybody else starting to get thirsty here? Starting to …hunger for a beer? Yeah …I’m starting to feel it like we could be continuing this maybe over a beer in a couple of minutes? Okay, let’s wrap this up.

I’m going to finish up with one last question I got from comments on the blog, I also said, hey have you got any questions for browser makers, and I’ve interspersed them throughout, thanks for answering those questions. The last comment I got was from Andre Luis, who says, and it’s kind of a good way to end things …it says, how close are we to arrive at a blissful scenario where building mobile web apps comes with true cross-platform compliance as a given? Here I use cross-platform as iOS, plus Android, plus RIM, plus Nokia, plus Opera. Are we there? Is it near future? Is it an unattainable goal that could never be reached? Anybody?

Andrea: I would say that as soon as anything is solid we always tend to try to invent something new, and the W3C is actually the living proof of that, where you write …you write the draft, you wait for someone to implement it and then it becomes a recommendation, and so I would say when would the developer to do the work because do I start when the experimentation happens? Do I start after the recommendation has happened?

Jeremy: So what you’re saying is, you can have completely cross-platform, as long as you use a certain sub-set of technologies?

Andrea: Yes

Andreas: And I think the big difference compared to a couple of years ago is that this sub-set of technologies is much more compelling than your pages must be small and don’t use any big images because otherwise everything will fall apart, now you have a full set of very powerful APIs, a lot of HTML5, CSS3 support, so I would say this time is already there where you can built something that will reliably run across all these platforms.

Jeremy: So, the sort of base-line has got…

Andreas: Has gotten much higher, yeah, and so you have a much bigger playing field, basically.

Eli: I think I agree that we’re definitely there to some extent, in terms of being able to build compelling experiences that work across different devices. I think that there’s a lot of projects out there that are making this much easier, so all the big frameworks are working on this and we, and we all work closely I’m sure with …with jQuery and with Dojo and Sencha and PhoneGap…

Jeremy: That’s true; the frameworks really help to kind of level out the playing field, so you do have a true cross-platform environment. Yeah, so we can live the dream, as long as we’re not doing user agent sniffing, we can have proper cross-platform.

Well, I want to thank you guys very much for agreeing to be here. You had to take quite a beating up here from me, but come on, it was fun, right? It was okay.

Eli: Absolutely.

Jeremy: Thank everyone for your questions. Thank you very much.