This is the CastingWords transcript of my interview with David Storey and Jan Standal of Opera Software. You can find the video and audio versions of the interview here.
Joshua Allen: I'm here today with Jan and David from Opera Software. Jan is
the director of product management for Opera,
And David is the chief web opener, which means that he helps people
like Microsoft make our sites compatible with Opera.
So, I've actually been working with you guys for some time on
various compatibility with Microsoft sites. Obviously, we always
have room for improvement; but we think it's very important to be
compatible with Opera.
Can you guys talk a little
bit about why it's important to be compatible with Opera?
Jan: OK. As you obviously know, Opera is among the four
biggest browsers in the world-wide statistics. So if you start
from a statistical way of thinking, we have a market share of a
little bit less than 1%.
Joshua: (interrupting) We definitely get more Opera hits than Safari on Mix Online.
Jan: That's David. 
But if you look at
the world-wide statistics, you see that Opera, for example, is much
bigger in Europe and Asia than it is here in the U.S. So our market
share goes up to like 10-15% in some countries.
But this is not really the reason you should build for Opera and
make sure your software is compatible with Opera. There's obviously millions of
users, but the most important thing is that you should stay to the
ultimate standards and make sure your software works properly
according to them. From that point of view, you'll automatically support
in browsers like Opera and Safari really quickly.
Joshua: OK. You mentioned market share numbers, and obviously in Northern
Europe, high. Also, there's millions of game consoles out
there today that are running a version of Opera, in the form of the
Wii. You mentioned some numbers for mobile, do you want to talk
number of handsets out there?
Jan: So, if you're looking, for example, we have two mobile links. We
have Opera Mobile, which is the same browser core as we have on the
PC. And that one is shipping on a lot of phones from handset
vendors, like Sony Ericsson and Motorola. We have shipped more
that 100 million phones so far.
In addition, we have the Opera Mini, which is a thin client
product, which is basically a small Java application. And it's a
free download, so people can go and download it and get the same
full web experience. It has a few things that are a little bit
different in the capabilities. It doesn't do, full AJAX, but
other than that it's pretty much the same experience.
Joshua: Cool. How do Opera Mobile and Mini compare to other mobile-based
browsers in terms of standard support and so on?
Jan: If you look at the Mobile, you can perhaps say that there's two
type of browsers in mobile phones. There is the classic wap
browsers, the historically low limited capabilities and low use.
The other category is full web browsers that have gotten
into the mobile phones. There you have the two new web-kit based
ones, which is the Nokia and Safari on the iPhone. And then Opera,
and then to some degree there's Internet Explorer, although it's not
compatible with what you have on the PC today.
Joshua: Yeah, it's always a little bit behind on the product cycle. So I
guess, let's get into some of the compatibility things here. A
lot of our developers and a lot of developers on the more LAMP
open source side of the house will start with either Firefox or
Internet Explorer for their development.
And depending on which browser they start with, then they'll go
tweak it for the other browsers. That's generally done, and they
yell at whichever browser they didn't start on. So, can you guys
talk about whether that's a good approach and how you recommend?
David: Well, generally you have to start with design for one browser, of
course, because you're testing your site. But we generally
recommend testing in both browsers as you make a major change. And
as you get more experienced with browsers, you'll start to learn
when a browser is slightly different to another browser. So then
you'll know when to tweak it instead of just designing it for
Firefox or IE, finish the site, and then end up with your pages all
over the place. And you're like, "What's happened that I don't
know?"
And also, if you do it with mobile browsers, you start to find out
you're starting to use vendor-specific extensions which you didn't
realize, so if you keep testing in mobile browsers you can avoid
them. I would say Opera is probably one of the most strictest at
sticking to the standards. So at least from my biased point of
view, I think it's very good to start designing from Opera from the
start, then Firefox will generally fall into line and so will
Safari.
But you might have to do some tweaks for IE. Generally, I would
recommend using the Conditional Comments for that.
Joshua: And particularly for IE6, right?
David: Yes, for IE6. IE7 is much better.
Joshua: Yeah. So there's
still a lot of cases where people will test with only Firefox and IE.
David: Right.
Joshua: And they won't even bother testing with Opera, Safari, et cetera.
What are some of the thing that you guys do in the product to
account for those situations?
David: In the product itself we have two things. We have this thing called
Browser JS, which is similar to Greasemonkey on Firefox. It's
packaged with the browser, it's updated approximately once a week.
And what it can do is it can step through the document to change
your code. So if we have things that synch in IE but it doesn't
really happen Opera, we can change the JavaScript to change it to
Opera specs. And that obviously changes the site; it will become
Opera compatible, and in the error console it will say that we've
done that.
The second thing we have is user-agent switching. And that can be
important because there will be a lot of sites which do things that
will detect Opera and give it broken content to block it. Or there
will be sites where you use very old menu scripts where, for
instance, they're assuming old bugs from Opera 5, six and 7, and we
don't have those bugs any more.
Joshua: Yeah. That's actually something we had a big problem with, with the
IE7 rollout as well. We had a lot of people who were doing
user-agent switching and giving bad behavior that we'd fixed in IE
7.
David: That's our biggest problem in compatibility.
Joshua: What are your biggest categories of issues? So if people are
out there building their sites, starting with another browser, what
are the things they should be looking out for as the biggest
gotchas that can hurt them when they go to test on Opera?
David: Probably one of the biggest is document.all support. Because people
are just convinced that document.all equals IE, which is not
really the case. Because Opera supports document.all too. So we'll
end up getting the IE branch of the code, which is not what we
want. So we do recommend object detection, but don't do object
detection to a single browser. And generally if you're using
something, test to see if it's supported first.
The other thing we have is generally browser sniffing, but it's
generally something that people do on purpose. We used to have a
lot of problems with overflow x and y, because in Internet Explorer the
browser didn't support it. But that's now part of CSS 3, I think,
so it's become less of a problem.
We often have problems with the object and embed elements, because
people will often update the Flash or the movies or whatever and they'll
forget to change the parameters, or they'll change the embed but
not the object, or do it the other way around. And you end up
without the video showing up.
Joshua: OK, cool. Is there any place for some of these issues, like the
object, embed and the proper way to do detection? Are there any
good resources that you guys recommend that people can go to that
show, "Here's the best way to do the detection, " or "Here's some
common issues?"
David: We have article on object detection by Hallvord
which is on our Opera site at dev.opera.com. That has a lot of
articles. That's a fairly new site, so we're building that up with
an editor called Chris Mills, who used to work for aPress.
Joshua: OK.
David: So that's becoming a big resource that a lot of people like. (Also)
the typical sites like A List Apart and things like that.
Joshua: Right. There and QuirksMode and those kind of sites. So, we've
talked a little bit about web standards, and I know that you guys
have been active in the creation of the HTML 5 efforts, active in
HTML, CSS and so on. Do you want to talk a little bit about Opera's
role in creating web standards?
Jan: Yeah. As you said before, we spent a lot of time on working with
web standards in general. We try to implement things early. We have
very strong dedication, especially the CSS, which our CTO -- Hakon
Wium Lie -- was on that, a core writer on the first specification
in the early '90s.
And since then, we're always trying to stay ahead and keep
implementing and use standards, that's just around the corner type
of thing, especially in regards to CSS. But also on the standards,
we're working quite a lot on, and we're very active in HTML 5 and
the specification area. And we have a working group there and
WHAT-WG.
David: SVG as well, where we're very strong. I think we have the most
compatible SVG engine, even including the engines which only do
SVG.
Joshua: Yeah. And you were one of the first to package it in the browser as
well.
David: Yes, we were the first.
Joshua: Cool. Cool. I want to move on to discuss some industry issues, and get
your take on these. One of the things we see is this trend away
from some of these core web standards, these mature WC3 things,
towards people, say, leveraging Flash for offline storage all the
way to moving their entire UIs to things like Silverlight and
Flash. And just kind of pushing the boundaries with AJAX even.
On the one hand, that's getting away from web standards. On the
other hand, if you're using a library like Dojo or Silverlight, you
can assume that there's some compatibility built in there. So,
what's your guys' take on that trend overall?
David: One of the big issues we have with these kind of rich interfaces,
is we're very strong on mobile and devices generally.
Because these rich interfaces are owned by one corporation, like
Adobe on Flash, Microsoft on Silverlight, they don't always
supply the runtime to every device.
So if you're married to one of these technologies that's not open,
it's very difficult for browser vendors like us to supply their
experience on every device, so users can't get the content they
want to access. There's also, sometimes, some things like
accessibility issues with these runtime environments.
I know Flash has done a lot of work with accessibility world, and I
guess Silverlight is probably doing that too.
Joshua: Yeah, definitely working with the AT vendors and stuff. But I think
that web standards themselves haven't really caught up yet with the
legislation and so on. So that's definitely an area of concern.
You mentioned mobile a little bit, and you've seen some talk in the
community about Eric Meyer saying, "Never develop specifically for
iPhone," and then others saying that it's actually really nice that
you can do a pure web standards based application for the iPhone.
So what's your guys' take on just the whole mobile thing and what
should our audience be thinking about when they are developing
their web sites?
Jan: The first thing is, if you have the chance, sitting down and
looking at the architecture of the sites. I think it's important
that you start planning for how it's all supposed to work on all
the medias in the future.
If you look at what's going on, look at all the PCs and mobile
phones, you see that the boundaries between mobile phone and the PC
today are disappearing. People are going to access your site with a
PC and with a mobile phone.
The only thing that's going to be the difference between them --
because they are all going to have a full web browser -- is the
screen resolution and perhaps the input methods. So you need to
start planning for that from the beginning.
Our recommendation is, if possible, to keep on using... We believe
the semantic web -- using markup -- is the essence of this. And
also using media types to control this layout
without having to use external style sheets, which gives you a lot
of flexibility and it gives you the possibility to do profiling for
the various screen resolutions.
I think putting your contact on a specific site -- saying, "If
you're on this phone, you have to go to this content, " -- is not
very sustainable. Once again, what's been going on with the iPhone.
You've got your main dot-com and then you're going to get something
specific to the iPhone. Then they launched the iPod touch with the
same thing.
That's not sustainable at all, especially if you look at the fact
that you see that all the millions of people are already online
with full web browsers with these devices. So just targeting a
niche spot, that's not very sustainable.
Joshua: Actually that brings up the point about Opera Mobile being on a 100
million devices. Clearly those aren't all exactly the same
resolution. So it's not as if somebody can target just one...
Jan: Exactly. You get a dynamic shape... You have to think of just the
things like all these phones they have portrait and landscape view.
Some of them have really high DPIs. So you need to start planning
for these things. That's going to be very interesting to look for.
If you also look at statistics and if you look at the usage, you'll
see that the iPhone usage is from zero to five percent of the
international browsing. But if you look at the Nintendo Wii, which
also comes with a full Opera-based Internet browser, you'll see
that it's three to four times as large.
And if you look at Opera Mini as a product, for example, it's much,
much more significant already in market share. So this is not
really the first time. You can do these things with mobile phones
also.
Joshua: Yeah, so for mobile web development, you just have to expect
diversity.
Jan: Exactly. Yes. So the good news is that when you have a full
browser, you can build it on one. But it doesn't even have to use
it as such, building specific things for specific systems. I mean,
that's wrong, right?
David: We also have to remember this has already happened with the desktop
browser with IE. Web developers, because their sites didn't work,
went with things like Firefox and it became very popular.
And also then Microsoft, because when they want to update IE7,
they are getting all these problems because pages had designed for bugs
in IE6. IE doesn't have the bugs anymore, so it causes problems.
Apple also has it on the mobile web where Safari will have bugs
that people have taken advantage of. Safari will lose some bugs and
all of a sudden they have different designs on the iPhone sites.
Joshua: That actually raises the point about -- XHTML 2 and
there's mobile vendors working on that -- Do we really need to stick with standards to
handle this diversity issue?
David: I believe so. Yes. Because when you stick to standards, that's the
only way to get it to work across browsers or across devices. When
you go to proprietary solutions -- iPhone has its own web kit
extensions -- and you start using them, it's only going to work on
one device.
If you use standards, there could be some browser that comes out of
nowhere which suddenly becomes huge. For instance KHTML came out of
nowhere to became big through Safari. If you're designing for
standards, at least it will be very close to working.
Joshua: Right.
David: Like who would have predicted that the Wii would have come out and
got a browser which suddenly took off with a huge amount of users.
Joshua: Yeah, definitely. So is there anything else you guys can think of
that you want to tell the audience or anything they should go do?
Jan: Well they should go download Opera!
If they don't have Opera already, obviously.
Joshua: And Opera Mini.
Jan: And Opera Mini, if they have any other Opera products on their
phones. And keep the code clean. Don't
use proprietary extensions. As David said, testing on browsers when
you start.
These are things that are painful in the beginning, but it
pays off over time. And then you don't have to explain to your
manager why doesn't this work on this...
David: One great thing about mobile design too is a lot of the
experience of making things work in the mobile are also the same
kinds of things you need to do when you're designing for
accessibility.
So if you design to make it work well for mobiles, that will really
help you a long way to making your site accessible. Or if you have
accessibility knowledge in terms of the other way.
Joshua: Yeah, and it makes it easier to use it for mash-ups or whatever later.
Definitely.
Jan: We also have the Opera Mini simulator if you can't actually get
Opera Mini on your phone or just want to do a quick test before you
go to the device. You can go to operamini.com. I'd recommend
testing the simulator out. Give it a spin.
Joshua: OK, great. Thank you guys for your time.
Jan, David: Thanks.