DevTools UI workweek - write-up

[Rob Campbell]

People of Firefox!

Paul Rouget has kindly written up a post about our work week in Toronto last week describing our direction for the next year or so and the design of our tools. Here is that post.

~ rob

Begin forwarded message:

From: Paul Rouget
Subject: DevTools UI workweek - write-up
Date: 19 January, 2012 17:15:08 AST

The problems: how to scale? we are getting more tools, we want to make sure they
all fit well together, and that a common behavior rules them all.

We have defined a couple of specifications for our devtools.
We have taken some UI decisions.
We need some abstract APIs that will let us "register" tools.

## Summary

We need to be more generic. 2 APIs will be developed to register NodeTools and PageTools.
Node Tools will live in the Inspector Sidebar.
Page Tools will live in their own sidebar/bottom bar, and will be un-dockable.
We are going to create "vertical tabs" on the right of the current sidebar.
The HTML Tree will go above the Inspector toolbar.
The Web Console will go below the Inspector toolbar.
The Inspector Toolbar is going to be updated to be less clunky.
The Infobar Bar will have an inspect button and a node menu.
This node menu will host the pseudo-class/element related features.
The gcli will live in the global toolbar.

More details below.

## Relevant bugs

APIs
Bug 717918 - Create API for registration of Developer Tools
Bug 707809 - Refactor creation of registered sidebar tools iframes in InspectorUI

Infobar
Bug 717919 - Add a Node Menu and a "remove node" menuitem to the infobar
Bug 717916 - Add an Inspect button to the infobar

Page Tools
Bug 717912 - Create Placeholders in browser.xul for Developer Tools Sidebars and Bottombars
Bug 717930 - Move the WebConsole to a bottombar, make it use the new registration mechanism
Bug 717944 - Docking and undocking mechanism for developer tools

Inspector
Bug 717929 - Move the buttons generated by the RegisterTool API inside the sidebar
Bug 717924 - Move the HTML tree view in the Page Inspector above the inspector toolbar

Bug 717915 - Implement a Global Developer Toolbar

## Specifications

Definitions:
Page Centric - Tools focused on a page (tab), Dockable in a sidebar or bottombar, or in a Window.
Node Centric - Tools focused on a selected node (DOM). Dockable in the sidebar of the Page Inspector.
Highlighter- a 2D or 3D visualization that lets you select or interact with content (nodes).
(new) Compact View- A tool can be displayed in a compact form:
A "folded" version of a page tool, that could fit in a toolbar.
Present the most important information of the tool

Tools:
Style Editor (Pagecentric Tool) (Default: bottombar)
Scratchpad (Pagecentric Tool) (Default: Window)
Web Console (Pagecentric Tool) (Compact View) (Default: bottombar)
Debugger (Pagecentric) (Default: Bottombar)
Network Timeline (Pagecentric) (Compact View) (Default: Bottombar)
Page Inspector (Pagecentric Tool, Host the Nodecentric Tools, sidebar + breadcrumbs + highlighter (2D/3D) + HTML Treeview)
CSS Rules View (Nodecentric)
Computed Styles View (Nodecentric)
Layout View (Nodecentric)
Font Inspector (Nodecentric)

Pagecentric Tools are reachable from the Web Developer menu, or a Global Toolbar:
Global Toolbar:
Command Line
Widgets (Compact Views)
Buttons

Diagrams with proper names of the different components of the tools are
available here:

Scratchpad: http://dl.dropbox.com/u/9927208/Scratchpad%20Diagram.png
Style Editor: http://dl.dropbox.com/u/9927208/Style%20Editor%20Diagram.png
Inspector : http://dl.dropbox.com/u/9927208/Inspector%20Diagram.png

## UI // How to scale

Node Centric Tools:

Node centric tools are hosted in the sidebar that comes with the Page Inpsector.
We can only show one tool at a time (but a tool can include another tool).

Mockup: http://dl.dropbox.com/u/129604/DevtoolsUI/paul-mockups/devtools-configurations/nodetools.png

Page Centric Tools:

A Page Centric tool will be able to be docked in a sidebar, a bottombar or
live in a window (up to the user). It will have a default position.
Each tool has its own sidebar/bottombar (not like the Node Centric Tools).

Mockups:
http://dl.dropbox.com/u/129604/DevtoolsUI/paul-mockups/devtools-configurations/pagetools.png
http://dl.dropbox.com/u/129604/DevtoolsUI/paul-mockups/devtools-configurations/morepagetools.png

## UI // Current Tools update

The HTML Tree Panel will be moved above the Page Inspector Toolbar.
http://dl.dropbox.com/u/129604/DevtoolsUI/paul-mockups/devtools-configurations/htmltree.png

The Page Inspector Toolbar will be re-organized. The inspector features (not
tools) will be move the the left (tilt, HTML panel).

The infobar will come with a "inspect" button, and a "node menu" that will let
the user delete the node, select a pseudo-element and activate a pseudo-class.
http://dl.dropbox.com/u/129604/DevtoolsUI/paul-mockups/infobarv2.png

The global command line will live in the Global toolbar. Mockups:
http://dl.dropbox.com/u/9927208/command-line-ideas/Command-Line-Mockup-Option-01-B.jpg
http://dl.dropbox.com/u/9927208/command-line-ideas/Command-Line-Mockup-Option-01-A.jpg
http://dl.dropbox.com/u/9927208/command-line-ideas/Command-Line-Mockup-Option-02-A.jpg
http://dl.dropbox.com/u/9927208/command-line-ideas/Command-Line-Mockup-Option-02-B.jpg

The WebConsole will be moved bellow the Page Inspector Toolbar (because it's a
page centric tool).

-- Paul

[Kevin Dangoor]

Thanks for the notes!

I think this direction is good overall, and I'm looking forward to playing
with it. The ability to choose the views you want to use at any point is
nice, and being able to put those views in separate windows is good when
you're trying to have more space in your browser window or more space for
the tool.

The way that Firebug and Chrome handle popping out all of the tools into a
single window has two benefits:

1. that window can be moved to a secondary monitor, moving all tools in one
go to that other monitor
2. a container for tools that are not tied to the browser content you have
on screen (useful for tools targeting browser chrome or tools targeting a
remote device)

These two cases are not important *right now*, but I think we don't want to
do anything that would prevent us from having a separate tools window at
some point. I'll also note the downside of that approach is the somewhat
overwhelming tools window you get since everything is always visible.

Thanks for all of the work in hammering out these details!

> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>



--
Kevin Dangoor

work: http://mozilla.com/
email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com

[Rob Campbell]

On 2012-01-23, at 08:38 , Kevin Dangoor wrote:

> Thanks for the notes!
>
> I think this direction is good overall, and I'm looking forward to playing with it. The ability to choose the views you want to use at any point is nice, and being able to put those views in separate windows is good when you're trying to have more space in your browser window or more space for the tool.

Yeah, that's the idea, anyway. Because the tools are split along tasks, that gives us some additional options for grouping and extracting them from the main browser window.

> The way that Firebug and Chrome handle popping out all of the tools into a single window has two benefits:
>
> 1. that window can be moved to a secondary monitor, moving all tools in one go to that other monitor
> 2. a container for tools that are not tied to the browser content you have on screen (useful for tools targeting browser chrome or tools targeting a remote device)

I think it'll make a lot of sense to try to have as much logical grouping among the different tools as we can. The Page Inspector for example has a sidebar, html view, toolbar with breadcrumbs, and soon, an additional layout information box. When detached, I think these should all live in a single window rather than being able to pop out individual panels.

> These two cases are not important right now, but I think we don't want to do anything that would prevent us from having a separate tools window at some point. I'll also note the downside of that approach is the somewhat overwhelming tools window you get since everything is always visible.

You always have all of the tools visible and taking up space, whether that's a tabstrip or additional cognitive overhead. Why is this debugger here when all I care about is a console and a page inspector?

> Thanks for all of the work in hammering out these details!

It's a work in progress. :)

~ rob

> blog: http://www.BlueSkyOnMars.com

[Kevin Dangoor]

re-adding (d-a-f)

On Mon, Jan 23, 2012 at 8:45 AM, Rob Campbell <rcam...@mozilla.com> wrote:

>
> On 2012-01-23, at 08:38 , Kevin Dangoor wrote:
>
> Thanks for the notes!
>
> I think this direction is good overall, and I'm looking forward to playing
> with it. The ability to choose the views you want to use at any point is
> nice, and being able to put those views in separate windows is good when
> you're trying to have more space in your browser window or more space for
> the tool.
>
>
> Yeah, that's the idea, anyway. Because the tools are split along tasks,
> that gives us some additional options for grouping and extracting them from
> the main browser window.
>
> The way that Firebug and Chrome handle popping out all of the tools into a
> single window has two benefits:
>
> 1. that window can be moved to a secondary monitor, moving all tools in
> one go to that other monitor
> 2. a container for tools that are not tied to the browser content you have
> on screen (useful for tools targeting browser chrome or tools targeting a
> remote device)
>
>
> I think it'll make a lot of sense to try to have as much logical grouping
> among the different tools as we can. The Page Inspector for example has a
> sidebar, html view, toolbar with breadcrumbs, and soon, an additional
> layout information box. When detached, I think these should all live in a
> single window rather than being able to pop out individual panels.
>

Yes, I think that could work well as a way to get the benefit of a single
window without all of the excess baggage.


>
> These two cases are not important *right now*, but I think we don't want

> email: kdan...@mozilla.com <k...@blazingthings.com>
> blog: http://www.BlueSkyOnMars.com

>
>
>


--
Kevin Dangoor

work: http://mozilla.com/

email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com