text:
Mobilism 2011 Mobile Browser Panel
A panel I moderated at the Mobilism conference in Amsterdam featuring representatives from Nokia, Opera and RIM.
- Watch the video of this panel.
- Listen to the audio recording.
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…
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…
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…
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?
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!
Andrea: String size is supported in JavaScript since 1985…
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.