~robcee/ more than just sandwiches

Inspector Impetus

Last week I promised to write a blog post to talk about why Mozilla’s building an inspector into Firefox. This is that blog post, and I also hope to explain a bit about the direction we’re taking with it and to ask all of you for feedback on what you’d like to see it do.

Currently, we include View Source in Firefox 3.6. I’ve blogged about how important view source is and how awesome it is that we have it, but inspection is a different kind of activity. Whereas view-source is linear, letting you view the underlying document from which your page was created, inspection is dynamic, letting you dip into a webpage to view a particular node and its associated properties. To find a node and its rules in view source, you might need to browse to several linked documents to locate the specific set of rules. Inspection locates everything for you. Of course, the inspector won’t show you the documents and their relation to each other on the server. For that, you’ll still need view-source. Further, inspection will show you live changes to the document as they occur. View-source is a moment in the life of the web page, and remains static.

Most web developers use a combination of tools outside of their browser to create attractive pages and interesting content: design and graphics tools like Illustrator and Photoshop and a broad array of content editors from Frontpage to Notepad++. For the inspector, we talked about some of the different interactions we wanted to give to developers and looked to these other programs for inspiration. The tool should feel dynamic and yet be easy to get out of the way if you want to go back to browsing the web. You should be able to quickly inspect a piece on a webpage and get as much information out of it as you wanted. Maybe you’d like to make a quick change or remove an element? Manipulate some DOM attributes, or move an element around in a page and have the Inspector make the positioning adjustments for you.

We’re not there yet. I’m still cobbling together pieces to provide some of the basics. But we’re hopeful that with these foundation blocks in place, we can start to build on them to provide unique interactions that have a more “designery” feel like the tools people already enjoy using to create content. We’re hoping the inspector will feel comfortable and intuitive to you.

Over the next little while, I’m rewriting the Tree panel, adding editing capabilities, redesigning the highlighter to look more like what’s in the mockup on the project page, adding rulers and guides to help with layout, and a few basic controls for making all of this easier to manage. The initial Style and DOM panels are waiting in the wings ready for review.

This is a different approach to inspection, for a different kind of user. We’re not looking to replace tools like Firebug and DOM Inspector – they are awesome, and we’re still totally committed to helping them be the best they can be. We think there’s a group however, that doesn’t need the depth of Firebug, but does want tools with a more “designery” feel. My hope is that Firefox and Firebug will complement each other in somewhat the same way that tools like Lightroom and Photoshop do.

To get your ideas and suggestions heard, reply here or on the dev.apps.firefox thread.

I don’t think there was that much outcry about the existence of the new inspector (was there?). It seemed to be more about that the new inspector would be included by default. This still makes no sense. My sister has no use for an inspector. There’s a reason why she has never had DOM Inspector or Firebug installed (and that reason isn’t just wont).

I’ve felt for a while that we should be pulling stuff out of the browser to package extensions—even MoCo. I would think of it as fantastic if the next version of Firefox allowed a custom install that included the new inspector as an option, like older versions did with DOM Inspector. The installer would come with a default configuration, and you could choose to include or exclude extensions based on that.1 This isn’t a new, radical idea; it’s the way many major apps have done things for forever.

Sometimes a pervasive suggestion or underlying theme is that the stuff at Mozilla Labs is just being run in a testbed and will go through a refining process that produces something suitable to be integrated and shipped with Firefox. But why? Why should being “integrated and shipped with Firefox” be anything other than the decision to package some extra XPIs (or, you know, whatever would be the most efficient way to package things) and tweak the default configuration in the installer?

I know the answer to this.

We have this major, additional focus right now on distilling extensions and the extension-authoring process with Jetpacks. There’re various thoughts about what Jetpacks are supposed to become, and whether they are or are not the right approach, and whether the power of Jetpacks will ever allow them to replace anything but the simplest of extensions. That’s another topic. But maybe if we had something closer to an extension-driven vision for Firefox such that Mozilla’s extension subsystem and the processes surrounding it were smoothed out such that it were possible to rely on it internally for general browser functionality, then we’d find that our motivations for Jetpack have been met.

Live Bookmarks? Out. Searchbar? Out. Element Properties? Out.

1. See “Extension driven development” for some musings about applying the approach to Thunderbird.

As for those who were upset about the simple existence of the new inspector, I’m for it. Certainly the useful aspects―the highlighter, for example―will be brought into the DOM Inspector as well. (I can’t imagine that Firebug wouldn’t do the same, since their CSS-twiddling approach has observer effect issues.)

And maybe others would disagree, but I have wanted the DOM Inspector itself to gain that “‘designery’ feel”.

Who knows? Maybe the DOM Inspector and the new inspector will converge again one day. The DOM Inspector could even go away and turn into a set of extensions centered around the new inspector…

It seems like my comment didn’t get posted. Submitting it again complains about duplicate detection.

Rob, is the comment awaiting moderation, or is there any way to recover it?

Something about your message flipped the spam bit in here. Looks like I recovered it though. Now to read what you wrote.

Colby, we love extensions, to be sure. They’re probably Firefox’ greatest feature. Though I’m not sure sending users through a series of checkboxes during first install is the right solution to adding new features, either. Imagine being presented with options for “Bookmarks toolbar”, “Search bar”, any number of sub-boxes for search engines, “Light weight themes” (personas), Status bar…

Essentially making all of the UI features that are in the browser as installable options could create a pretty long list. I think that would be pretty confusing to people. If you’ve ever used Cygwin, or Visual Studio or Adobe CS you might have seen one of these types of installers before. It’s not something I’d want to inflict on anyone if I had a choice. It’d also require quite a bit of effort to strip everything out, create a cross platform installer, etc.

As for why we aren’t developing the Inspector as an add-on, I actually started out doing that, but in the interests of rapid development, it turned out to be easier to work off of browser code. Complex add-ons are quite different beasts than in-browser JS and since the ultimate goal was to include this by default, it would have been more work to convert it back.

Anyway, thanks for the comments. You raise some interesting ideas!

Imagine being presented with options for “Bookmarks toolbar”, “Search bar”, any number of sub-boxes for search engines, “Light weight themes” (personas), Status bar…

I’m certainly not suggesting that, and that’s certainly not what the installer required for Firefox 2.0-. There’s no dichotomy of <current Firefox install process> and <install process which forces the user to choose every piece of functionality before running Firefox>.

There is the potential to create an installer that allows you to choose the (Mozilla-authored and -endorsed) extensions, and to allow them to be disabled or uninstalled in the Add-ons Manager.

It’d also require quite a bit of effort to strip everything out, create a cross platform installer, etc.

Is there even an install process on non-Windows platforms? I’d guess most Linux users get their binaries from their distro, but even the binaries Mozilla builds and distributes are just meant to be dropped in and run. It’s similar on the Mac, right?

This doesn’t preclude anything that I wrote about.

it turned out to be easier to work off of browser code

That’s the primary problem. Extensions are intended to allow anything that browser/ can do. But extension development is more than just XUL + XPCOM + JavaScript. Extension development is, “Do hooks exist to allow me to even begin thinking about implementing this?” If implementing this as an extension were so tedious, imagine what the ramifications are to people who don’t have the privileged development path that MoCo does.

NB: This isn’t supposed to be some sort of class warfare. This is a thought experiment that asks, “What is someone supposed to do where ‘just shove it in browser.js’ isn’t an option?”.

This isn’t some half-hearted, misdirected suggestion for a change in Mozilla. It’s me thinking aloud just as much as (or more) than it is a proposal.

“What is someone supposed to do where ‘just shove it in browser.js’ isn’t an option?”.

Extensions. When I said I built on browser.js for rapid development, it was mostly to offset the pains of reintegration down the road. For the minimal amount of setup pain required for an extension, I think that’s still the best way to build an add-on feature.

The conversation about installers, while interesting, is a little outside the scope of where I was hoping to go with this blog post.

thanks!

“What is someone supposed to do where ‘just shove it in browser.js’ isn’t an option?”.

Extensions.

Like I said, extension development is more than just being head down with the technologies behind them; verifying that hooks even exist to allow you to do what you want to do is a necessary step before you can even begin work.

If you’re already touching browser.js, it’s no big deal to also tweak the code paths there to allow the stuff you’re adding to be called in all the right places and just work.

The conversation about installers, while interesting, is a little outside the scope of where I was hoping to go with this blog post.

It’s not so much about installers; that’s auxiliary. It’s more about general browser functionality being written and manageable as extensions, and everything surrounding extension developers and users being better off for it. Then there’s preventing Firefox from turning into SeaMonkey, but just developed under different leadership and direction.

Like I said about misdirection, etc., this is moreso me thinking aloud than it is a proposal.

pd,

What does not make sense to me is why not just integrate the bulk of Firebug features into Firefox?

The new inspector is even more lightweight than the DOM Inspector, not to mention the bulk that is Firebug.

Firebug development occurring outside of Firefox development has a few advantages for both. First, it allows Firebug to be improved independently of Firefox releases.

Secondly, the Firebug guys have their own approach and way of development, outside of Mozilla’s infrastructure. This is deliberate, from what I can tell. Bringing them in would change this, and also add more stress to review/QA for MoCo releases. Right now, the only process that the two have to share is the AMO review. (That also isn’t to say that this is the only thing they share, just that it’s the only thing they have to, although even the AMO review’s not necessary if they didn’t care about distribution through AMO.)

I’m actually kind of glad the new inspector isn’t being built on top of anything else at the moment. Starting with a clean slate can let you step back and do things that you wouldn’t ordinarily be able to do (easily) if you’re keeping yourself beholden to already-existing things. That mentality gave rise to Firebug, and a lot of people seem happy enough with that decision. Besides, there’s nothing saying future convergence is out of the question. I’m eager to see what will come of the new inspector.

Would there need to be a substantial re-write of Firebug to operate under the Jetpack APIs?

Absolutely there would.

Also, a suggestion: call it Mozilla Designer.

pd asked,

What does not make sense to me is why not just integrate the bulk of Firebug features into Firefox?

That turns out to be a difficult proposition, both for Firefox and for the Firebug project. It’d be technically difficult to include Firebug in its entirety in Firefox, requiring a significant rewrite to get the code in line with the browser’s. Also, I’m not sure it would make sense to include all of the features.

Colby said,

Also, a suggestion: call it Mozilla Designer.

hey, that’s not bad!

Also, a good chunk of Colby’s reply is spot-on regarding the differences between Firebug and Firefox development.

Thanks for the comments, and if you feel like contributing patches or test-cases please let me know… Or just file bugs in Firefox::Devtools!

It seems extremely odd to go and recreate half of firebug as native. What developer would choose to use that when they’ve been using Firebug for years? I see no potential audience for such an effort and think it wouldn’t be a wise use of time.

I know you guys have put a lot of effort into Firebug and think you should continue. Many of Mozilla’s contributions have been some of the most valuable stuff that has gone in recently.

Has development with the Firebug team led to an impasse where you guys can’t collaborate on the same project anymore? Such a case would to the detriment of web developers, for sure. :/

I think it’s clear to see they both offer different ideas and having Mozilla work on something different so it’s not “all or nothing” (Firebug or nothing) will be valuable in the long run. As the inspector is going in a bit of a different direction simply implementing these features in Firebug would not necessarily be the right thing (scope or aims). Speculating of the collaboration halting is unfair given the different valuable reasons why both projects should exist.

I haven’t heard any designers lamenting over how hard Firebug is…
I still doubt that this different direction serves an audience.

I think it’s a great inclusion item because much like how we have no idea how many people have been able to turn to something as simple as “View Source” to solve a problem, we can’t even begin to see all the cases where the inspector would come in handy for web developers all along the spectrum (beginners -> pro).

I’d even go so far as to suggest to Colby that perhaps his sister might find herself using it someday. So many workers find themselves doing tasks in their day-to-day that take them into minor web development rabbit holes and a lot of times it means going into crusty, stale code that you know next to nothing about. To be able to inspect an element over scanning View Source will definitely be a time-saving win for those who hear about its inclusion and decide to try it out.