Blue Sky On Mars

My goal as a product manager at Mozilla is to represent the needs of web developers well and make sure that Mozilla is doing what we can to help them.

I came to the realization last night that when I talk with others about what “developers” need, the picture of that “developer” that appears in different people’s minds can be quite different from my own. In fact, while I may imagine someone sitting at a keyboard getting frustrated at trying to make something work, someone else may be thinking of a company that “wants” to get an app into Mozilla’s Marketplace.

In my view, when you’re figuring out what you need to build, imagining a company is almost always not what you want. Companies don’t do anything. People do. People have a variety of reasons for doing the things they do, and understanding what those people are trying to accomplish is key to building good products.

This is what I like about personas ^[1]. Personas describe realistic people, allowing you to empathize with them and ensuring that you’d never mistake a person for a company. They can help give clarity to which things are important to build and also help catch gaps. Imagine a coworker coming up to you and saying “Can you believe I just met someone who was trying to make our product [do something outlandish]?”. It’s possible that the person in question is an outlier that you can safely ignore. But, it’s also possible that there are other, similar people out there and adding a new persona to the mix may open up a whole new market.

All of that said, it’s perfectly reasonable in many contexts to talk about a company as a “developer”. “Mozilla is the developer of the popular Firefox web browser”, for example. There are certainly times in product development where talking about a developer as the entity that controls an app in the Marketplace is perfectly reasonable. But, when you get down to planning features, I think it pays to think about individual people.

Yesterday, GitHub announced their new “Command Bar”. I am a fan of command lines, and this is an awesome addition for navigating GitHub. I love being able to get more done without pulling my hands away from the keyboard.

You may remember that we’ve added a command line to the Firefox developer tools. It’s currently in beta, slated for release in about 3 weeks.

My reason in bringing this up is that if you want to add keyboard controlled command line goodness to your webapp, you can do so easily. The command line in Firefox is actually a separate open source (BSD-licensed) project called GCLI that you can incorporate into your own webapps!

Fork GCLI on GitHub and let’s see a thousand command lines, um, bloom.

Live editing of CSS in the browser works great. You get to see your changes immediately, and there’s nothing like live feedback to keep you rolling, right? The Style Editor in Firefox makes it really easy to edit your CSS and save when you’ve got everything looking just right.

CSS is purely declarative, which makes it a bit more straightforward to implement live editing. Swap out the rules and the new rules take effect without weird side effects.

HTML is declarative as well, but there are two problems with “live HTML editing”:

1. You’re changing the Document Object Model (DOM), not HTML
2. What you’re changing is often not the same as what you started out with

DOM vs. HTML

I won’t dwell on this, but the first problem is that even if you’re looking at a “static HTML file”, once the browser grabs onto that HTML it turns it into a DOM. The browser’s tools will show you what looks like HTML, but it’s really just a visual representation of the DOM. JavaScript can manipulate the DOM and change things entirely from what was sent down the wire. JavaScript can also add properties to DOM objects that don’t even appear in the “HTML view” that the browser shows you.

Of course, using Firebug (and, soon enough, Firefox as well) you can make live changes to the DOM in an HTML-like view. Some kinds of these changes may mess up things like event handlers, but you can still try out your changes.

The real problem is…

What you’re changing is not what you started with

A fundamental bit of building a webapp is taking some data and plugging it into an HTML/DOM structure so that the user can see it and interact with it. Consider this view of Mozilla’s GitHub repositories:

Let’s say I wanted to add a new bit of information that’s already in the database into this compact repository view. I could open up Firebug and add it to the DOM. This would at least allow me to try out different DOM structures and get the styling right. However, I’d need to go back to my server code (I’m assuming the view above is generated by GitHub’s Rails code) and make the change for real there. Plus, I’d only get to see how the change looks on one of the elements, until I’ve updated the server and reloaded.

Back when I was working on TurboGears (2005), almost all of the stuff that ended up in the DOM got there from HTML that was rendered on the server.  Then, as today, people used all kinds of template engines on the server to take a mass of data and munge that into some kind of HTML structure for the browser to display.

Many developers have been experimenting (with varying degrees of success) with moving the conversion from “hunk of data” to DOM into the browser. That means that the browser will take a hunk of data, combine it with some sort of template and then update the DOM with the new content^[1]. So, the browser has the data and the template in hand.

What if the browser tracked the relationship between data, template and elements of the DOM? Wouldn’t it be cool to fire up the Page Inspector, point it at one of those repositories in the screenshot above and then tweak the template rather than tweaking the DOM? If you add that new field to the template, then all of the repositories on screen would immediately be refreshed.

Even better, once you’ve got everything looking the way you want, you could save your template to disk^[2], much like you can with a CSS file in our Style Editor right now.

How do we get there from here?

The creators of one of the MV* frameworks could make a browser-based editor that understands the templates used in their system and lets you make on-the-fly tweaks. The disadvantage to that approach is that it only benefits that one framework. And, even for users of that framework, that editor would stand alone from the rest of the browser-based tools (would they create their own CSS editing in addition to template editing?)

Another way to go would be something like the Model-driven Views (MDV) project. The idea there is to add templating directly to HTML and the web platform. MDV is nice because changes to the data are automatically propagated back into what the browser displays. I don’t know if MDV would also automatically propagate changes to the template back into the display, but that would be the idea.

There are many different opinions on how templates should work. I’d be happy if we pick one approach, make it a part of the web and enable smooth live editing of the entire appearance of our sites and apps.

Feedback

Mardeg writes:

The “Model-driven Views” puts <template> tags inside the html and relies on them being parsed with javascript, whereas it might be feasible to use javascript to generate/alter a template from combined MicroData and explicit role attributes already existing within the page, which wouldn’t affect how the page is viewed with javascript disabled.

If MDV becomes a part of HTML (as in “baked into the browser”), then it may not rely on JS at all. I like the idea of being able to combine a template with microdata. Personally, I think we’re reaching a point where if you want to run web applications you really need to have JS on.

Last week, I had the opportunity to join a planning meeting for the newly coming together Orion project. Orion is a new take on the IDE coming from some people with a raftload of IDE experience with Eclipse. Orion is also a new take on the web-based IDE, which is something I’ve enjoyed exploring a bit through the Bespin project.

The meeting brought together people from the Eclipse Foundation, IBM, SAP, Microsoft, Nokia, RIM, GitHub, Nitobi and I represented Mozilla there. Rik Arends from Ajax.org, makers of Cloud9 IDE, also made it to the meeting, which was really cool. I like the way that open source “competitors” are often willing to exchange knowledge and ideas in ways in which traditional commercial competitors are not.

Cloud9 and Orion are taking two different approaches to the IDE-in-the-cloud concept. Cloud9 is similar to Bespin and can be thought of as something like the “Google Docs of Code”. It’s a “single page app” that provides something akin to the desktop editor experience in your browser. Orion is taking the approach of being “completely webby”. Instead of a single page app, each URL represents a tool+resource, much more like a “CGI-style” webapp. Practically, this means that when you’re navigating your files, you’re using a page whose sole purpose is file navigation. When you’re editing, you’re using an editor page that has a URL that refers to the file you’re editing. When you’re committing to a git repository, you go to a git page.

The offshoot of Orion’s approach is that Orion does not provide UI bits like a tabbed editing interface. Instead, if you want to open multiple files you just open multiple browser tabs. Not only does this mean that the Orion folks have less code to maintain, it also lets them automatically take advantage of neat browser features like Firefox 4’s Panorama.

One of the keys to the Orion approach is that rather than trying to invent everything and house it within Orion, they want to effectively make the whole web part of Orion (or, put another way, they want Orion to just be part of the web). Rather than giving Orion a “new project wizard”, they can just link over to Initializr, for example.

This is a powerful idea. The web’s loose coupling is likely one of the reasons it has been so wildly successful, and that’s what Orion wants to tap into. The tension is going to come when they try to provide an nicely integrated and consistent user experience for common tasks. If you look at Cloud9 and Orion today, you’ll see what I mean. Cloud9 already has a polished and consistent flow that Orion presently lacks.

Part of Orion’s solution to this problem is through the use of plugins. Orion’s plugin system is far simpler than that of Eclipse and is also quite webby. Plugins are basically HTML pages that are loaded through iframes. This means that plugins have automatic security restrictions imposed by the browser. They communicate with the rest of Orion through postMessage. That means that only JSON data passes between plugins and Orion (no code can get through) and only the APIs that Orion provides at the other side of the postMessage bridge are accessible.

That plugin system is loosely coupled and can be used on its own. If you’ve got a JavaScript app that you want to make extendable, you should check it out.

John Barton (IBM and Firebug) demoed Firebug with editing integration with Orion. The Orion server provided the browser with a header with the URL to edit the file being served. Firebug used this header to provide an “edit with Orion” feature. John showed off editing integration for CSS where the changes to the CSS made in Orion were instantly reflected in the browser. Nicely done! One of the most popular requests to the Firebug project is the desired ability to be able to save changes made to the CSS via Firebug’s UI. There are some solutions available as Firebug extensions, but Orion potentially provides another solution that will integrate very nicely.

There were quite a few times in our discussions where topics and issues that came up were exactly things that we had dealt with for Bespin. Ben and Dion came by and presented about their experiences with Bespin. We all want to see this kind of exploration make progress and are happy to help people avoid the mistakes we made and the pitfalls we encountered.

The activity around Cloud9 IDE and Orion is great to see, because browser-based development is one area that is not yet the norm for web developers but I think will come to be at some point in the future.