Firefox Developer Tools Input Summary Jan 26

Standard

Lots of Feedback

Firefox Aurora has a fairly small audience, but it represents a good time to start collecting feedback on new features. Firefox Beta has a much larger audience. Both Aurora and Beta have a handy “Feedback” button in the toolbar, and I thought that now was a good time to dive into that feedback since we’re reaching the end of the Firefox 10 beta cycle. Firefox 10 is a big deal, because it adds the Page Inspector and related tools for web developers.

In this post, I’m focused on the input that we’ve received from the Feedback button. We get input from many other sources as well:

  1. user studies
  2. blog comments
  3. Twitter/G+/Facebook (mostly Twitter)
  4. Google Alerts (blog postings, press articles)
  5. Bugzilla
  6. dev-apps-firefox
  7. irc.mozilla.org #devtools
  8. surveys
  9. and, of course, the Feedback button input from Aurora and Beta users

I’m probably forgetting some input channels.

Those of us working on Firefox developer tools have ideas of what we (as developers ourselves) would like to see in the tools. Hearing from other web developers goes a long way toward making sure that we’re doing the right things to make tools that work well for many people.

Keep the input coming!

Summary of Input

The entries from the Firefox Feedback button are collected and searchable at input.mozilla.com. I went through the input for a variety of searches going back to mid-December to get an idea of what the sentiment was like.

During that time, I counted 63 positive feedback entries for our new built-in tools and 22 negative entries. That’s 74% positive. Across Firefox as a whole, most people (between 55-65% over the past month) who hit the Feedback button did so because they found some aspect of Firefox they didn’t like. People are going out of their way to say that they like the new tools, and that’s fantastic.

Firebug has its own feedback channels (a mailing list, bug tracker, etc.), but we get some input about Firebug via the feedback button. I saw 36 positive and 22 negative entries, which is a 62% positive rate. Again, this rate is much better than the overall and the sentiment that I’ve seen toward Firebug in other channels has been super positive.

More interesting information comes up when you look at some of the specific feedback…

Recurring comments about Firebug

Of the 22 negative comments about Firebug, 10 were about Firebug crashing, or the browser crashing in conjunction with Firebug. People working on Firefox and Firebug take crashes seriously, so I hope that people file bug reports or ask for help for these kinds of problems. It turns out that there is a known crashing problem that is fixed in Firefox 10 (due on Tuesday). Let’s see how these numbers shift after 10 is released.

Five comments about Firebug reported a problem getting Firebug to run on the user’s version of Firefox. I find this a bit unexpected, because Firebug has broad compatibility these days. See the listing at the top of this blog post about Firebug 1.9. If I had to guess, I’d say that this problem is because some people did not get their copy of Firebug from addons.mozilla.org. Hopefully, the number of people getting Firebug elsewhere (getfirebug.com) has been dropping. Firefox Nightly users need to get Firebug from getfirebug.com, but those of us running Nightly generally know the risks we’re taking, right?

All of that said, the majority of comments about Firebug were along the lines of “I love Firefox because of Firebug”. Some of them were marked as praise with the simple comment “Firebug”.

Recurring comments about the Firefox Developer Tools

Three people stated that the tools should live in add-ons because the user is concerned about memory bloat and speed. On this point, it’s worth noting that every commit to the mozilla-central repository (from which Firefox is built) is checked for memory usage and speed. The tools we’re adding to Firefox do not negatively impact Firefox’s memory use and speed.

On the flip side, six people stated that they like having the tools built-in.

Three people said that they don’t think we should be duplicating Firebug. I’ve written about this already, so I wont rehash it here.

Four people want a “layout view” that shows margins, padding, etc. for an element. Those people are in luck! We’ve got a patch in progress.

Quotes like “THE NEW DEVELOPER ELEMENT INSPECTOR IS SO SLICK!!!” and “3d Web Developer Layering. (Ctrl + Shift + I) This is SO helpful!” reflect a lot of the sentiment in the positive feedback.

Thanks, and I’m looking forward to more!

The release of Firefox 10 and new notices for Aurora and Beta users will likely net us more feedback in the coming weeks. We’ll be listening!

I’ll close with this tweet from Brian Blakely:

“Perhaps the next-generation webdev IDE will be a browser. Somewhat related, FF’s dev tools are really coming along”

Future Firefox Developer Tools Updates Nov 17

Standard

Information Gathering and Organizing

Since my last update, I had some back-to-back busy-ness. First, I was prepping and presenting at the 1DevDay Detroit conference. I spoke about a number of web developer tools there.

That was followed by a work week in San Francisco and Mountain View. Mozilla’s product team is working on the product roadmaps for 2012. You should start seeing drafts coming out for review and comment soon.

I also did three more user interviews. These have been very interesting, and will undoubtedly improve our product plans. I’ve also heard about some other user research going on at Mozilla around app development that may have some interesting information for developer tools as well. Once I figure out the best way to package up the research we’ve been doing, I’ll get it posted.

Aurora 10

The most exciting news is the release of a new Aurora build last week. Five of our feature pages landed for Firefox 10. You can find a more coherent version of what’s exciting about Firefox 10 (due January 31, 2012) in this Mozilla Hacks article that I posted yesterday.

New Feature Pages

Consistently, the users I’ve interviewed use the console, CSS tools and network request timeline the most. We have other data that shows a great many users also use the debugger features of web development tools. We now have a console, CSS tools and a debugger in the works. That leaves a network timeline, for which we’re figuring out scope and a plan.

In the meantime, I added feature pages to cover a couple of things that didn’t make it into Firefox 10. The enhanced property views page is about making the way CSS properties are displayed and edited in the Style Inspector even better.

The Layout In Highlighter page is for adding a feature that web developers find useful in other tools: being able to see margins and padding around an element right around the element itself on the page.

I had created a page to track against our plans for multi-process (“electrolysis”) Firefox. The engineering team has decided to take other approaches to improve Firefox’s responsiveness, which means that we don’t need to tackle multi-process rearchitecture work right now.

A Comment on the Feature Page System

Something that has felt a little awkward to me about our feature pages system is that improvements (like the “enhanced property views” above) to previously shipped features need to either get glommed together into a feature page or just live as bugzilla bugs. So, there are actually two places (feature pages and bugzilla) where useful work to be done or things that have been done can appear.

The line for me seems to be that bugzilla is used for the details of implementation and prioritizing the parts of the implementation that need to happen. The feature pages provide higher level context of what we’re trying to accomplish.

If you’re interested in helping out with Firefox web developer tools, I’d suggest looking at our Get Involved page which has links to both our feature pages and to our bugzilla bugs.

Tools for Web Developers (1DevDay)

Standard

This past Saturday, I had the pleasure of speaking at 1DevDay Detroit 2011. The event was held at the fantastic Compuware headquarters in downtown Detroit. It’s a beautiful building, and the training center facility works well for events like 1DevDay.

I spoke about “New Tools for the Open Web”. My goal was to show off a bunch of tools that people might find useful and to talk about tools for the future. It’s impossible to talk about all of the great stuff that’s going on. The world of open source tools for the web is huge and growing, and there was a standing-room-only crowd for my talk (thanks for packing in there and letting me run over my timeslot a little bit!)

I started with some tools that aren’t new, hopefully showing off some cool features along the way.

  • The Web Developer Toolbar has an incredible number of utilities packed into its menus. It’s not new, but it should be in your toolbox.
  • Firebug has had a huge influence on tools for web developers and continues to get awesome new features (such as more fields on the Net Panel and the ability to select which ones you want). I also pointed out Firebug’s non-standard but amazingly useful control for quickly selecting script files on the script page.
  • I spoke about a couple of neat JavaScript features in the Chrome Developer Tools (the ability to tweak JS on the fly and the ability to prettify JS while you’re debugging)
  • I showed off the Web Console and Scratchpad tools from Firefox, in particular showing how Scratchpad provides a very clean, usable interface for experimenting with JS.
  • I gave a sneak preview of the new Firefox styling tools that will very soon be in Firefox Aurora builds.
  • I showed of the Firefox style editor which should be in the next Aurora. For now, it’s available as an add-on
  • I also demoed Tilt, an amazing 3D visualization of the DOM

In a category all its own is Weinre which provides a way to debug apps running on a mobile device.

Then, I stepped into a collection of CSS tools.

  • ReCSS is a bookmarklet that’s been available forever. One tap of the bookmarklet reloads your CSS without refreshing the page.
  • LESS extends the CSS language with a variety of useful features and compiles down to standard CSS to run in the browser. It’s written in JavaScript, so you can do the processing client side or server side. Neat trick: if you are doing client side processing, you can add #!watch to your URL and LESS will periodically refresh the CSS from the server automatically. Make a change on disk and see the change almost immediately in the browser. I also mentioned Sass and Stylus as alternatives.
  • CSS Prefixer helps you out by expanding your CSS3 declarations to work in all of the browsers that support them with a prefix (-moz, -webkit, etc.)
  • Prefix Free is an alternative to CSS Prefixer that works client side and adds only the declarations needed for the user’s browser.
  • Rainbow is a Firefox add-on for working with colors. Among its many neat features, it will give you the color palette for the page you’re looking at. The Colour Bookmarklet does something similar as a cross-browser bookmarklet.
  • DOM Monster is a cross-browser bookmarklet that will take a look at your page and give you specific advice on how to make it faster

I put out a call on Twitter and G+ for suggestions of tools that people rely on for their web development. Several cited their editors, so I thought I’d mention a couple.

  • JSFiddle takes the pastebin concept a couple of steps further by giving you a way to easily share snippets of HTML/CSS/JS that are put together into a preview pane. JSBin is an alternative
  • The Eclipse Orion project is building a browser-based IDE with workflows and plugins that feel very much “like the web”.We ship the Orion text editor component in Firefox
  • Cloud9 IDE provides a beautiful and feature-rich IDE for working on both the client and server parts of your application… all in the cloud!

I didn’t talk a whole lot about JavaScript-specific tools, because a lot of what we use for JS are libraries and not tools.

  • I showed JSHint, a fork of Douglas Crockford’s ever-popular JSLint. JSHint provides nice static analysis of your JavaScript code to catch some errors early
  • CoffeeScript is a nice language that provides a friendlier syntax on top of JS without changing the semantics. This means that the JS it produces is quite readable (and quite close to what you’d write by hand). I’m still hoping that some of CoffeeScript’s best parts make it into ECMAScript.next (and there’s a good chance that a lot will).
  • Using a language like CoffeeScript makes debugging a bit harder. I showed off our not-quite-ready-yet source maps feature for Firefox. Source maps will also be really useful for debugging minified JavaScript.

I spoke a little about docs. Documentation is important, and the more we do to have better docs for our tools and libraries, the better.

  • I think JQAPI is awesome. They took the standard jQuery docs and reformatted them to be more useful.
  • Docco lets you do literate-style programming in JavaScript (or Python or any of the other ports that are available).
  • Eloquent JavaScript is a book that teaches you JavaScript and provides interactive exercises to help with the learning

Then, I spoke a bit about the future.

Almost everything I showed was created in HTML, CSS and JavaScript. If you can make web apps, you can make tools. Even the tools that are built into the browsers are built of the same basic stuff.

Invest in your tools:

  • Find the good ones, use them and tell others!
  • Give feedback (this really helps people who make tools to make them better)
  • Make them better
  • Make entirely new ones

I mentioned how some tools, like Matthew Claypotch’s localStorage bookmarklet are very simple to write but can meet your needs precisely and even show toolmakers what you’d like to have.

Other tools mentioned to me by others but not part of my talk:

  • Glimpse is a client-side view into a server-side ASP.net applicaiton
  • Edit This Cookie is a Chrome extension for editing cookies. There’s also Firecookie for Firebug
  • YSlow is a tool from Yahoo! for spotting performance problems with your pages
  • stat.js is a bookmarklet that gives you information (such as frames per second) for the page you’re looking at
  • h5o provides an outline view for HTML5 documents
  • LiveReload automatically reloads your JS and CSS as you change it (oh, and it will recompile your CoffeeScript, Sass or LESS for you at the same time)
  • ReloadEvery is a Firefox extension to reload periodically automatically
  • redbot spots problems with the way you’re serving up your pages
  • HttpFox is a Firefox extension that provides an alternative view of network requests
  • ColorZilla is another set of color tools for Firefox
  • Fiddler is a web-debugging proxy

And there are many, many more. It’s a good time to be building web applications.

Future Firefox Developer Tools Updates Oct 27

Standard

Unlike most organizations, Mozilla’s product management is open. You can see what we’re building now and planning to make in the future just by looking at our feature pages. Open, however, is not always discoverable and it should be easy for interested people to follow along as plans are revised, help make those plans better and make it easier for everyone to spot features they’d like to get involved with.

As the product manager for Firefox developer tools, I am most heavily involved in the creation of these feature pages.

We had a feature page that conflated two different concerns with a joint user interface. While the user interface we talked about might be a great way to go, the two features have different priorities and it’s worth considering other approaches properly. The more important feature is the ability to lock in a pseudo-class when working on the styling of a page element. For example, viewing the styles for the element as if you were hovering over the element. This is high priority because web developers have no way to peek into the details of hovered styles without tools support. Once they’ve moved the mouse from the page element to the tools, the element is no longer hovered!

The Web Console’s queued messages display is a feature that will allow the Web Console to display messages logged from before the console was opened. There was some complexity found during review of the code and, given the other things on the plate for Firefox 10, this feature is not likely to make that release. This is definitely still a feature we want, but I have dropped it down to P2 to reflect that the other items on the list are higher priority.

There are also some recent additions to the feature pages:

  • Tilt in the Page Inspector adds a 3D view to the forthcoming page inspector (aka highlighter). Victor Porof recently wrote about the add-on which has a whole bunch of interesting features. The core 3D view is something we want to be directly available in our tools, as it will help people solve nesting problems in their markup.
  • CSS Source Mapping The buzz around source mapping continues to grow (see this recent issue for HTML5 Boilerplate) and CSS needs source mapping for exactly the same reasons that JS needs source mapping.

I created some other stub feature pages, and I’ll write more about those as they’re fleshed out.

I’ll be writing more about Firefox developer tools feature ideas from this point onward. Your feedback is always welcome. You can talk about ideas on dev-apps-firefox or contact me via email, Twitter or G+ (see the sidebar on my site).

Students Seeking Jobs: Show Of Your Code

Standard

This past Monday, I attended my first career fair on the employer’s side of the booth. I’ve done a fair bit of hiring in my career, but this was still a new and fun experience for me. Career fairs have gotten a lot bigger than they were when I was a student, and the three of us manning the Mozilla booth had a constant flow of students to talk to (sorry for anyone who didn’t get to talk to us before the 4pm cutoff!).

IMG_0595
Tony Chung (far left) talking to a student. That’s Julie Deroche on the far right.

I had a good time talking with the students and I’m sure that many are laying a path to successful careers in software. At the end of the day, one thing stuck out in my mind as being unexpected: where was the open source experience? I think that only a single resume I saw mentioned a GitHub account or some open source project that a student was involved in.

Many students just had their coursework to talk about. Here’s the problem with that: every other student has that same coursework. Using different paper for your resume is not going to make you stand out. Having something beyond your coursework will.

US News ranks the University of Michigan as one of the top 15 grad schools for computer science and in the top 30 undergrad colleges overall. Ann Arbor is not a big city, but the University of Michigan is a big, well-regarded school. UM is not a JavaSchool as almost all coursework is in C++. While I can’t say for sure, I doubt that this lack of open source experience is limited to UM.

I’d also expect that many students who are fans of open source software would likely gravitate to a Mozilla booth.

The students that seemed the most promising to me came across as loving to code. They did things beyond their coursework, in their spare time… They learned Haskell or programmed robots or compilers.

A great way to show your enthusiasm and your code is to be involved in open source.

It would be good for universities to offer a course specifically designed to introduce students to open source and get their code out there. Students would learn about:

  • distributed version control
  • working with people around the world
  • navigating open source projects (using GitHub, mailing lists, IRC, etc.)
  • possibly bits about licensing (it’s good to know the basics, at least)

And, they would even end up with code samples out in the wild that they can show to potential employers.

Remember what I said about everyone having the “same coursework” to show to potential employers? Not so for a class like this if the students are allowed to dive into different open source projects. You’d have students hacking on Rails or Node, Couch or Mongo, CoffeeScript or nginx. It’s good for the students, and good for the projects.

If you’re a student, don’t wait for this magical class to show up. The catch 22 of “can’t get a job without experience, have no experience because can’t get a job” no longer applies: anyone can step into open source. Just do it!

Making sense of Bugzilla data

Standard

tldr; I have created a project status page for Mozilla developer tools and a library called Buggerall that helps to make pages like this.

Poor Bugzilla. It started life as an innocent bug tracker and has come to be counted on as the source of truth for a collection of significant software development projects, and the workflow tracker of Mozilla’s development process.

As manager of Mozilla’s developer tools group, I was responsible for keeping an eye on how our projects were moving toward completion. It very quickly became apparent to me during the Firefox 4 cycle that getting code through the process was just as important as writing the code in the first place. At the time, “through the process” meant gaining blocker/approval status in addition to getting a slot on the super busy review queues of browser peers and successfully managing the back-and-forth of the review process. There is no query you can run in Bugzilla’s web interface to show you how bugs are doing in this process.

Enter Bugzilla’s REST API. Using this API, you can gather whatever data you need from Bugzilla and munge it any way you want. Even better, you can use this API entirely in client side JavaScript, even cross-domain. For my initial report, which showed where a given bug was in the Firefox development process, I had a bunch of code in the page to gather and format the data.

More recently, I’ve made that code more generic and given it new superpowers. It’s called Buggerall, it’s lightly documented CoffeeScript and it’s available on GitHub.

In my new role as product manager for developer tools, I want to be aware of how things are going with the projects, but at a higher level. I also want to be able to track developer tools work as it relates to Firefox features. To that end, I have created a project status page that builds on Buggerall to give me (and anyone else that’s interested) a view into developer tools work.

Some interesting features of Buggerall:

  • run queries easily
  • you can serialize the result so that reports (like my status report) can use cached data and load very quickly
  • but you don’t have to! queries can be live and cross-domain
  • new Timeline object lets you gather a feed of events for the bugs in a query

My status page has an updater script (invoked from an update page in the browser) that runs the queries using Buggerall and then mashes the data down to a simpler format used by the status page. The updater uses a Firefox-specific API for saving files which I found in TiddlyWiki.

The status page is built around project metadata that I set up. This metadata allows me to group together arbitrary collections of bugs, which is very handy. This can be done with meta bugs in Bugzilla, but it takes a lot more work to do so. Also, since this is all in git, it’s easy to collaborate with other people on the metadata.

I’m always interested to hear about other techniques people have for getting useful info out of Bugzilla. The query interface that Bugzilla provides is quite powerful on its own, but the REST API makes it easy to gather any data you need and present it any way you want.

New role at Mozilla: DevTools PM

Standard

Yesterday, I got back to work after a nice vacation, stepping into a new role after about a year as Manager of Developer Tools.

I’ve had a lot of fun this past year and learned quite a bit along the way. A year ago, I knew very little indeed about Firefox development. I’ve come to have a good handle on the process, which has changed dramatically along the way, and a decent grasp of the technology used in Firefox and how it all fits together.

The team has been fantastic: Rob Campbell and David Dahl got things rolling before a DevTools team even existed. My Bespin partners-in-crime Joe Walker, Patrick Walton and intern Julian Viereck joined the effort. New intern (now full-time) Mihai Sucan was characteristically sanguine about being told he was going to work on Bespin only to find out just before starting that he’d be working on Firefox. We worked hard on the Web Console and Inspector tools for Firefox 4, with the Web Console making the cut and shipping in March along with Firefox 4.

Along the way, Julian left for the university and Patrick moved to working on Rust.

We knew we wanted to go a lot further. Jan Odvarko, who is one of the lead developers of Firebug, officially joined the team. Dave Camp, a long time Mozillian, returned in February with a desire to make developing for the web better. In April, we were joined by Cedric Vivier, Kyle Simpson, Mike Ratcliffe and Panagiotis Astithas. In June, Paul Rouget joined the team, bringing his considerable insight and experience as a longtime developer evangelist at Mozilla. We’ve also been joined by Nick Fitzgerald as an intern for the summer and Victor Porof who is working on a Google Summer of Code project for developers.

This is an awesome team of people and I’m very proud to be working with them.

This blog post is not one of those “it’s time to move on to bigger and better things” posts. Web developer tools is an area with a lot of work to do and boundless opportunity. Taking care of the team and the projects as we’ve grown is easily a full time job and, in May, I raised my hand and told my manager that there’s work that needs to be done that I don’t have time to do.

Luckily, we had someone willing and able to take over the work I was doing in managing the engineering team: Dave Camp. Dave is a sharp engineer and is excellent at helping people lay out a path from point A (nothin’) to point B (working feature). He’s also got a very good sense for Mozilla and working out in the open.

Product Manager, Developer Tools

Which finally brings me to my new position: Product Manager for Developer Tools. Product management is one of those roles that shows up in different places in different organizations. At Mozilla, we have a dedicated product team led by Jay Sullivan. As part of this team, I’ll be able to do the work that I have had little time to do over the past few months, but is necessary for our success.

My responsibility as product manager is to represent the interests of web developers in designing and prioritizing features that will help them build better sites and applications more easily. I’ll do this by taking input from a great many sources (in no particular order):

  • Mozilla’s developer engagement and market research teams,
  • the developer tools engineering team,
  • web developers I talk with directly, and
  • things I read (and I read a fair bit)

With that input in hand, I’ll boil it down to roadmaps and ready-to-build feature specs. Dave Camp and the engineering team will take it from there to iterate on the features and get them to users. And we do all of this out in the open, ready for feedback and help all along the way. Mozilla really is an open organization and community. New product development is among the most secretive parts of most organizations, but not for Mozilla.

I also see communicating about what Mozilla is doing in developer tools as an important part of my job, so you can expect to see more blogging from me here and on the official devtools blog.

Now, onward to the new challenges!

Update: holy cow! I forgot to mention the three most recent additions to the devtools team (sorry Paul, Nick and Victor!) That’s what I get for blogging quickly while I’m still digging out after getting back from vacation.

Browser-based command lines are awesome

Standard

Command lines are an amazingly great way to get things done using the keyboard, and using the keyboard is a way to do many things faster than reaching for the mouse. Of course, I’m a geek and not everyone likes command lines. But, many geeks do… and, I think that what we think of as a command line can move way beyond what a command line was in the ’70s.

TermKit recently got a good deal of attention, and rightly so. Steven Wittens has created a beautiful command shell that runs in a dedicated browser.

We did a good bit of command line experimentation on the Bespin project, and Joe Walker has continued that experimentation with the GCLI project. GCLI has been pushing in some directions that Joe has had in mind for a long time (a command line interface that is also mouse-friendly). At work, we’ve got some big plans for that one. Ajax.org also has a command line (not yet GCLI-based) in their slick Cloud9 IDE.

There’s also been Ubiquity, which had a “natural language” take on the command line. A few months ago, Ian Bicking created his take on a browser-based command shell with jsshell.

All of these are exclusive of the many JavaScript REPLs that exist and have varying and interesting sets of features.

All of these are something that we could loosely call a “webby CLI”. So, I’ve set up a webby-cli googlegroup for people who want to talk about the concepts, projects and niggling implementation details around bringing a great command line experience into browsery environments. Join us, if you’re interested in that sort of thing.

Initial thoughts on Eclipse’s Orion

Standard

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.