This is part of our larger effort to bring open video to the web. We’ve been glad to work with NVIDIA and Youtube on this project building the solution entirely on open standards like WebM and HTML5. Our hope is that by lowering the barrier for 3D video on the web, we’ll see more interesting apps being build on open web technologies.

This feature requires that you have 3D Vision hardware. If you do have 3D Vision Hardware, go to youtube.com and search for ‘yt3d‘. Files encoded with 3D have this tag. You will also have to set your 3D mode for the type of hardware you have.

Even if you don’t have the hardware, trust me. This feature is pretty cool. I was able to load up some 3D trailers on youtube and it was pretty amazing to see a little world appear in the video box.

But over the last few months I’ve been focused on one aspect of that job more than others – helping to drive the web-facing side of our platform. A big part of that work has been listening to web developers who are building on top of the web and understanding what they need. (This is a big part of the role of the Evangelism group inside of Mozilla.) I’ve also been working closely with Mozilla’s engineering team to help determine what’s important and what’s not. I think that I’ve discovered – and others inside of the project have discovered as well – that having someone doing that full time with a specific focus on the web platform full time is really important. (In the past that role was spread across various parts of the project.)

To that end I’m moving on from leading the Evangelism team and moving to help manage the web-facing side of Firefox full time. It’s easiest to think of this as a product manager for the web.

This is going to be an interesting job, to be sure. It’s entirely built of soft skills: listening closely to web developers, both frontend and backend. Working with the Mozilla community to communicate and understand where the web needs to go next. Working with partners to build great partnerships and products. Working with our user and developer engagement groups on the best way to talk about the web. Maintaining a roadmap for Gecko. And, last but certainly not least, working every day with the people on the ground doing the great work that make Gecko the best platform to advance the web.

I expect that I’ll keep posting on hacks and on this weblog. But expect to see different kinds of questions from me from now on. I expect that I’ll be spending a good bit of my time on what the web will look like 2-5 years from now and what we can do at Mozilla to make that happen. That’s going to require looking for the best ideas that people have and working to make them a reality through the Mozilla project.

The web is a platform that’s still ripe for improvement and change. So I’m looking forward to your feedback and your help.

How it should go: browsers innovate differently, users pick the best one, later W3C standardizes what users chose, losing browsers conform.

Joe hasn’t been part of the web for a while, so he might not notice that there’s a lot of that going on right now. Mozilla does participate in standards, including HTML5, the CSS working groups, and quite a few others. But participation doesn’t have anything to do with our ability to innovate, and very often we’re out way ahead of the standards. We’ve got a vision for a better web, and that sometimes takes the roads of standards and sometimes doesn’t.

Just so people know I’m not just blowing smoke here are three specific examples of places where we’ve stepped out and led in this space. Standards are still part of the picture, but certainly not where Joe thinks they are:

Geolocation

As part of our mobile browsing work we built Geolocation into the browser to take advantage of location-aware capabilities in mobile devices. We built it, we shipped it in our browser on Nokia devices and then we took it and found a way to put it into desktop browsers as well. Even though it was shipped in Firefox only (and is finally starting to show up in other browsers) it was widely adopted. You can find it on use on Google Maps (click the little button above the zoom slider and it will ask for your location), twitter, flickr and a number of other web sites.

Once again, the model here wasn’t “wait for the standards committee to figure out what’s important” it was “figure out what works for developers, what it should look like and figure out how to get it into the browser in a responsible manner.”

We’ve worked with other browser vendors since we shipped the feature to get it into their browsers as well, and that’s gone through a standards process. Our implementation has changed as a result – and for the better. But no one was waiting.

Orientation

Once again, out of our mobile work we took the idea of being able to detect orientation on mobile devices and we’ve added it to our desktop product. Firefox 3.6 just includes the ability to detect the orientation of your machine. We’re not waiting, and we certainly haven’t had the same use on the web that we saw with geolocation, but we didn’t wait to include it.

WebGL

This is another giant thing where Mozilla has been leading the web forward. WebGL started as Canvas 3D. Mozilla didn’t wait to start 3D work that we thought was valuable to bring the web to the next level. That implementation, done largely as an extension on top of our advanced addons platform, was a great way to experiment and learn about how 3D fits into the web model. (Note: we’ve shown that it works on mobile as well as desktops, showing how these technologies are running in both directions.)

This is an interesting case because we decided to take the work that we had done and go down the standards route, working through the Khronos group. In a lot of ways that’s turned out to be a really great decision. It brought Google to the table, it brought Apple to the table, it’s allowed us to engage with all of the hardware vendors who are also part of the 3D world and we’ve been able to build something that’s really good without watering down the original concepts and designs. It’s going to be something that’s really amazing.

Don’t believe me? Check out the number of demos and libraries that are already underway for WebGL. It’s never shipped in a production browser, and people are incredibly excited about it. It’s likely to change the face of gaming.

Conclusion

So I don’t think that Joe understands that browsers – or at least Mozilla – aren’t waiting to innovate. Not even a little bit. And we’re doing this up and down the stack, everywhere from how you interact to data to performance to CSS to multi-touch support to hardware-accelerated graphics. And we’re still doing it in the context of the web. Firefox 3.6 is light years of IE and somewhat ahead of other browsers on the HTML5 front. We’re also leading in a lot of other specs as well.

But that isn’t what Joe is worried about, and honestly it’s not what we’re worried about either. We want to go fast. We like to go fast. Finding the balance between going fast and shipping is where the hard decisions are, but we’re almost always to ready to fall on the side of innovation. And that shows in our history and roadmap. The fact that IE has been basically moribund for years hasn’t stopped us from building a better vision for the web or carrying through with it either. And now everyone is following us.

And a huge amount of that work didn’t come through standards. It came through our actions.

I’ve traded some mail with Joe about his visions for where he thinks the web should go, and they match up surprisingly well with our own visions. Expect to see Mozilla standing out in front on these issues. Connecting the web with new sources of information, bringing new technologies to bear and improving the experience and sense of ownership that everyone has over their data. You can start to see that showing up in our new Firefox Sync functionality (your data, encrypted on the server, it’s yours, not ours!), Contacts, Account Manager, Canvas, Video and a bunch of other technology where we’re leading the web where we want to go.

Basically we’re looking for a word Ninja.

If you fit the bill, feel free to apply.

(Note: Ninja outfit not included with hire offer letter.)

Ryan points out that there are significant differences between what Google has built here and what we’ve built. I thought it might be worth it to expand on that a bit since it isn’t explained in depth in the Ars article.

Google’s 3D work is a plugin.  So much like how Flash or Silverlight works you get a rectangle in the browser to draw into.  They provide a high level scene graph API which uses the COLLADA format for loading objects underneath.  It’s a very large chunk of code.  If you take a look at the API and click around at the packages and classes you can see that there’s a lot there.  Their use case is games and game-like things – virtual worlds.  So it’s a great piece of work, but it’s also at a very high level.

Mozilla’s current proposal to Khronos is a very simple API that’s a wrapper around OpenGL ES 2.0.  It’s currently available as an extension to Firefox 3.5 and is likely to be rolled into a version of Firefox after 3.5.  The proposal is very focused on 3D.  For example, we didn’t try to include video or audio because those are being covered by other web standards and we’re interested in making sure they are well integrated instead of trying to wrap those into a 3D spec.  We’ve bound it to the canvas element so you can use it in much the same way you use the current canvas 2D context.  Things like asset loading (via COLLADA or other systems) are things we haven’t dealt with because those can be handled entirely outside of the 3D api and layered on top of it.  (Later in this post you’ll understand why this is important.)  But the important thing is that it’s something that you can easily mix with the rest of the open web.  Open Video and Audio, CSS, HTML, Canvas 2D, Canvas 3D, etc – you should be able to mix them all together and that’s our goal.

So these two 3D things from Mozilla and Google are pretty different.  Not really competitive, either, because they have such different goals.  The Google software is a very high level API 3D graphics API and what we’re proposing is more akin to the low level graphics API that those high-level systems are built on.

Given the title of the google blog post (“Towards an open web standard for 3D graphics”) it’s important to point out these differences since they affect how the standards process might look, and what the output might be.  We’ve been through this a few times with different standards and it’s easy to point out what the key success factors are to build a successful standard.  Here’s a quick iteration on those principals in my mind:

1. It’s important to keep the scope as small as possible.

The smaller the scope of the standard, the easier it is to understand the interaction of the various parts, what your goals are and what it takes to build an interoperable implementation.  It’s also the easiest thing you can do to remain as future-proof as possible.  It’s easier to add new APIs later if your scope is very very small.

2. Clear rules for interaction with the rest of content.

How does it work with the rest of the HTML spec?  CSS?  Video?  Images?  How can you copy content in and out?  Can you use them as textures?  These are just some of the questions that you have to raise as a way to describe how something like this might work with content.  Once again, this is gated on #1 above – if the functionality is simple then the interactions can generally be pretty simple as well.

3. Allow the scope to change slowly over time.

Understanding that technology – especially on the web – does not exist in a vacuum outside of time.  Standards do change over time and understanding how people use technology in the real world is the best possible way to understand how something should change and improve.  Understanding that standards are an iterative process is important.  Note that in #1 above – controlling scope – I mention that it’s important to keep things future-proofed via small and simple APIs.  This is why – because you know that you will need to improve that API once you understand how people are using it in the field.

4. Allow most of the innovation to happen next to and on top of your API.

Last point – your standard should allow as much iteration and work to happen on top of your API as possible.  This allows you to learn as much as possible about how people are using your software and gives them huge amounts of freedom to experiment and teach you about what you need to improve in the next iteration.  If people are stretching your APIs and finding gaps in performance, you can add convenience APIs to make things faster – as long as they are simple APIs.  We saw this in the real world with the JS libraries (dojo, jQuery) – we’ve been optimizing our engines and APIs over time to assist them as they have pushed our browsers to the limits.  But we would not have known had we tried to implement everything that the libraries could have possibly done at the browser level.

OK, so those are the things that we think make for a successful standards process.  I’ll point out one particular example of a dichotomy that I believe illustrates these rules so that people understand what I’m talking about: Canvas vs. SVG + SMIL.

Canvas is a very simple API (more info), much like what we’ve proposed to Khronos for 3D support.  It’s well-scoped, well understood and integrates very well with other web technologies.  And it’s been getting a huge amount of traction on the web.  People are writing all kinds of really neat technology on top of it, including useful re-usable libraries for visualization.  Have a look through Google’s own promotional site for Chrome – a huge number of them use canvas.  It has traction.  And we’ve gone through a couple of iterations – we’ve added support for text and a couple of other odds and ends once we understood what people were trying to do with it.

Now compare this to SVG and SMIL.  Each of those specs are multi-hundred page documents with very large APIs and descriptions of how to translate their retained-mode graphics into something that’s usable on the web.  (SVG 1.1 is a 719 page PDF.  SVG 1.2 Tiny is 449 pages.  The spec for SMIL is a 2.7MB HTML file.)  We’ve seen some implementation of SVG and SMIL in browsers, but it’s been slow in coming and hasn’t seen full interoperability testing nor any real pick up on the web.  The model for these specs was wrong, and I think it shows.

So I’ve spent some time talking about the context for standardization and what makes standards successful.  How does this related to our stuff or Google’s stuff?  Well, quite a bit actually.  If we want something that browser vendors can easily implement, we need to understand that context and what we’re trying to standardize.  Much of the work that Google did happened before browsers got as fast as they have, so there’s a good reason why they felt that they needed to implement so much of the code as native code and deliver it as a plugin.  Their API is a good example of what a scenegraph API would look like on top of Canvas 3D.  JS engines have gotten a lot faster since they started their plug-in and we think that it’s time that we start using them.  Hence a low-level API that we can build on.

There’s a lot of great stuff going on with 3D on the web.  We’ll be working with Google (and others!) via the Khronos group to try and standardize on a low-level API that browsers can support.  It’s going to be a really fun year and I’m happy that we’re working to drive the web forward.

If you have Firefox 3.1b3 you can try the demo here.

If you want to attend, use this code: “vel09cmb” – it will get you an extra 15% off the price.

•Direct video link: [OGG] [MP4]

Also consider following the openvideo twitter user, identi.ca user and facebook group.

One of the things that we do when we do a release is try to have a “canonical url” for each release.  For major releases, it’s like the url above – a mozilla.com release page.  But for the betas we usually have a post ready in our Mozilla Developer News Weblog.  For the new Firefox 3.1 Beta 3 release, we had a post ready ahead of time and knew what the URL would be.

But ahead of this release one of the things I did was to set up a short url on bit.ly for the release.  One of the nice things about bit.ly is that it lets you track information as people click through the url.  You can see people clicking through the short link for our release at the associated info url for that particular short url.  This is what it looked like a little while after the release:

The data flow is a little flaky and I hate that it goes from live to past week (2 hours to daily is a pretty rough transition) but it’s great to be able to see the effect that particular posts can have on the traffic.  It’s also interesting to see the traffic sources in the graph as well.  It gives you a good sense of where people are reading information and generating click through traffic.

What’s really interesting is that you can take the bit.ly url and use it to track posts on twitter by using twitter search.  Here’s what I found after coming back from dinner last evening:

This was after a post from the @mozillafirefox account which has about 14,000 followers or so.

Search also lets you follow what people’s reactions are as well.  In our case we’re using the #firefoxbeta tag to follow what people are saying.  I’ve been able to interact with some people about their experiences with add-ons compatibility and problems they have had with the release.  (Surprisingly few problems, actually.)  But mostly it’s just fun to watch people talk about how fast this release is when they actually use it.

Tools like twitter search have also let Mozilla set up the Release Rapid Response Team (RRRT).  This small team of people collects information from twitter, identi.ca, facebook, weblogs and other places and raises common issues for our development and support teams to look at.  As an example, here’s the RRRT list for Firefox 3.0.7.  (Yep, it’s a short list but that’s a pretty good sign.)

It’s great being able to passively listen or interact directly with people on the product and I think it’s part of a sea change in search, social networks and product support.  It’s going to close the gap between comsumers/users and the people who produce those products.  And I also personally believe that it’s going to require that companies be more authentic in the way that they operate.  Not only can companies see what users are doing in real time, consumers can also see what companies are doing as well.  The transparency is two-way.

At Mozilla we’ve found ways to adapt and turn it into something that’s really useful.  I wonder what other projects + companies are doing with these new tools?