Interview: Opera on the Web of Devices

Opera announced their TV app store at CES 2012. I took the opportunity to chat with Andreas Bovens, Group Leader Developer Relations and Divya Manian, Web Opener about Opera and the Open Web Platform on diverse devices.

IJ: What are Opera's development priorities on different platforms?

AB: We are on a lot of platforms including desktop (Windows, Mac and Linux), mobile (Android, Symbian, J2ME, iOS, BlackBerry, Meego), and selected TVs. All of these are important to us, so it's not like we prioritize desktop more than mobile - development continues simultaneously on practically all of these platforms.

IJ: How do you maintain market share on so many different devices?

AB: On the desktop we rely on word of mouth. But on mobile, the situation is different, especially with Opera Mini. People like Opera Mini because it runs on a lot of devices and improves performance through compression. Lately we have been striking deals with carriers that see a lot of Opera Mini usage on their networks. The carriers like the fact that Opera Mini uses less bandwidth. And users appreciate the lower costs. Some carriers are even promoting the browser themselves: "With our network you can use Opera Mini." We are driving growth through operators, and that share is growing. Opera Mini has a strong presence in CIS, Indonesia, India, Nigeria, and a large number of other African countries, and we also see fast growth in Latin America and the Middle East.

IJ: Interesting. Why is that?

AB: Opera runs well on all hardware - not only on the latest state-of-the-art devices. In some cases, we've gotten traction with a certain critical group of users, and then adoption spreads virally - this was the case with Opera Mini in Indonesia, which took off and reached critical mass in a short time frame, but there are many more examples.

IJ: Meanwhile, the Open Web Platform keeps growing. How do you manage?

AB: We have our core engine, which runs about everywhere. We built it with mobile and performance in mind, then ported it to the desktop. There are some components that we include on the desktop (e.g., integrated mail) that we don't ship on mobile or TV. But there are no browser concessions across the devices. There are some different behaviors according to the platform (e.g., which video codec is supported).

IJ: Do you find the lack of a single Royalty-Free video codec for the Web a problem?

AB: I think WebM plays an important role. I am not sure whether we need another one. On mobile devices we don't implement the codecs ourselves; we use the support provided by the underlying system (e.g., H.264 on Android).

DM: From where I stand WebM seems to be a robust solution we should adopt. I think we hear more complaints about video from developers than from users. Developers are the ones that struggle. Video codecs are a problem, but that's true for almost all the HTML5 features.

IJ: The Open Web Platform consists of a lot specifications at varying degrees of maturity and implementation. What do you think is critical to the success of the platform?

DM: Developers have been promised a lot of magical things. But when they start to use the features, they find the reality does not yet match the promise. Some implementations may be broken or only half-completed. Or a draft specification can change radically, invalidating implementations and causing confusion among developers. Today some developers are focused on Webkit even though there is inconsistency even among different Webkit rendering engines. When developers optimize for a single browser, they leave others in a lurch. What we need to do collectively at W3C is promote robust implementations. We need to have tests before we start implementing. We should also be quick to drop older implementations (that are broken) before developers come to rely too much on them.

IJ: Do you think implementers are likely to wait for tests before implementing?

DM: This is a persistent issue in the world of implementers. But it is still worth suggesting.

AB: Much of what we see is that developers rely on a specific browser (e.g., Webkit) and they forget about other engines on various devices, including Opera, Firefox, and others. The problem seems most persistent on mobile, perhaps because of Webkit's market share. Things break and developers don't understand why; or they don't notice the problem, of if they do they do browser sniffing to avoid the problem.

DM: The Android browser implementation of HTML5 is pretty broken.

IJ: What can be done?

AB: In our developer outreach we've been trying to warn developers. A monoculture of one rendering engine is likely to backfire as it has in the past. A monoculture of one rendering engine was disastrous for the Web - we're only just getting rid of IE6 now, and China still has 20% IE6 share. A monoculture on mobile will be even worse. Some people rely on Webkit defaults thinking they are standard features.

DM: Some browser vendors are considering implementing Webkit prefixes. But we need more outreach to developers. To developers I would like to say: in your demos, make sure that those demos have the right prefixes. At least when you are showcasing them.

IJ: You opened the Opera TV app store. How do you see the TV market changing?

AB: Traditionally the TV market has been closed. HTML5 apps running on a TV is a new concept that is opening up the market. We'll have to be careful that there's not too much fragmentation.

IJ: Tell me about the store.

AB: The television industry wants people to engage with social networks and access Web-based content from their TVs. We feature access to sites that have been optimized for TV (e.g., 4-way navigation through a remote control).

IJ: What is your vision for multi-screen scenarios?

AB: We are looking into this. WebSockets can be used for these sorts of interactions, and media queries and feature detection play an important role when it comes to adapting content for different devices However, there are other technical aspects to be decided upon - for example, the interaction modes differ from screen to screen: there is touch input, 4-way remote control input, etc. Without a doubt, this is something for implementers and standards bodies to look into and decide on.

IJ: Tell me about getUserMedia: accessing the camera and privacy UI.

DM: If you want to share your camera image you can use APIs to capture images and render them back as a data URI. This will allow people to create image manipulation apps.

AB: The overall effort is towards real-time communications and augmented reality. You use a camera stream and plot information on top of it, or do analysis. There are a number of use cases. The direction is towards WebRTC (Web Real-Time Communications).

DM: You might also combine it with WebGL for 3D rendering, and bring gaming, video, and 3D interactions more into the browser.

AB: Yes, you could create WebGL objects and place them in a video. You need orientation events as well. I believe there are some iPhone or Android apps that do this natively. All the new standards that have been implemented in the past year will provide new ways to interact with content. We have only just scratched the surface of what people will be able to do once we start to combine these features. More experimentation is necessary.

IJ: How difficult or easy is it to combine these technologies in innovative way?

DM: Right now we are at the edges of finding out how they work together. We don't yet know what we will find (e.g., performance issues). We need to experiment, and this will also tell the people writing specifications what to fix.

AB: Sometimes you can combine things you didn't know worked together. For example, you can combine SVG and media queries in interesting ways, for instance changing the SVG rendering depending on the resolution (even though SVG is resolution-independent). That's something that people in the media query work weren't thinking about. But people discover interesting uses and it works cross-platform!

IJ: What should we expect in Opera 12 and when?

AB: We're working hard on 12, and while we can't say yet when it will be ready, people can track progress on our desktop team blog as well as our standards support pages. One of the things we're working on is GPU-accelerated WebGL support for instance, and there is also the earlier mentioned getUserMedia integration.

IJ: I hear from others that using the GPU makes a big difference.

AB: In the long run we are looking at offloading other things to the GPU as well. As far as I understand a lot has to do with how things are architected; there are not immediate performance gains for hooking directly into GPU. It's not magic. There are more architectural things that need to happen. What will get better? Some animations, but not everything magically. You may not need it for ordinary page rendering.

IJ: Any advice for W3C? Where to focus? What to change?

DM: I'd like to see specifications become standards more quickly. I understand why they take time but it would be great to speed things up. Also, I'd like to see more developers and designers learn what to do "first hand" from the specifications. A lot of people get their information 2nd or 3rd hand from browser vendors. That also results in people creating apps that are specific to an old way of doing things.

AB: I agree that education of how to use web technologies the right way is important (as we said about vendor prefixes). It is important that people learn how to use features in a way that doesn't cause sites to fail on new devices, for example by using fallbacks.

IJ: Do you have suggestions around good practices for living with vendor prefixes?

AB: In general we suggest that people include all the known vendor prefixes. There are also a couple of JavaScript libraries that take the pain out of doing that. Or online tools. Or Sass, which gives you programming language features that CSS doesn't have.

AB: I think people need to think about mobile differently. We work directly with people to improve their code. We sometimes see that people handle "Opera compatibility" as a business development request. It's like they think they have to support another platform, but the purpose is the opposite - that you write once and with little effort it can run anywhere. People designing for one platform miss out on what the web has to offer. Project coordinators need to understand the values of developing with standards.

DM: Use standards. That's the best way forward for getting something on multiple and varied range of devices.

IJ: Thank you both for the conversation!