This page describes on-going development effort for a new feature in Firebug. Nothing described on this page is deployed yet. Your comments welcome.
- 1 User Experience: Roles
- 1.1 Users
- 1.2 Testers
- 1.3 Designers
- 1.4 Developers
User Experience: Roles
Of course in many cases the same person may be doing eg the design and testing
Users may install Swarms in one of these ways:
- Swarm Tools Menu Item: Firefox > Tools > Swarms
- Swarm firebug button: Firebug > Firebug Menu Icon > Swarms
- Firebug update info page
- Swarm based Firefox extension
Swarm Firefox Tools Menu Item
User picks Firefox > Tools > Swarms. A new Web page opens listing available Swarms. User selects a swarm by clicking on a link, resulting in a new Web page listing the extensions of that Swarm and the testing results. The User may select paid extensions and donate-please extensions. User clicks 'install', optionally pays, and all extensions are downloaded, verified, and installed. (For FF 3.6 reload is needed next).
This use case is expected to be uncommon, but we need it for bootstrap.
Swarm Firebug Button.
User picks Firebug > Firebug Menu Icon > Swarms. The implementation is the Swarm Firefox Tools Menu Item.
Not essential, nice to have.
Firebug Update Info Page
User updates Firebug. The (future) Firebug update page is launched, with links to release notes, documentation, pledge campaign, and swarm list. User picks swarm link and the UX is as for Tools Menu Item.
This should be the primary path for 1.6.
Swarm Based Firefox Extension
User picks a Firefox addon from addons.mozilla.org or other site. The add-on is just the swarm installer wired to launch a particular swarm definition page and auto-install.
This will eventually be the primary path, but until Firebug can install without restart, this path will be clunky: install, restart, install, restart.
The User UX is implemented in the swarm Firefox extension. All of the paths are variations that lead to the swarm-list page. The swarm extension listens for clicks on the links in this page and any pages loaded from it. When it detects a swarm definition page, the install buttons are activated and invoke swarm install.
The swarm extension can be loaded independent of Firebug and thus bootstrap the install of Firebug along with all the other extensions. The Swarm-based Firefox extension implementation simply invokes itself after install; the Firebug update-info page, Firefox menu item, and Firebug button versions open the swarm-list page under supervision of the extension.
The swarm extension is generic and ideally will not depend on Firebug. Its just a multi-extension installer using an HTML page for its specification.
You can try the current version by linking fbug\extensions\swarm\branches\swarm1.5\ into your profile/extensions. (In SVN Chromebug you can use Extension panel button Add Link for this).
Testers install Swarm extension, Firebug, and FBTest (how?). In the FBTest window they select the testShell (where?). In the testShell they use file-pickers (TODO) to set up the test:
- swarm definition: pick local file or URL?
- test list: URL (defaults to the latest Firebug list), (TODO allow added tests)
- output template (defaults to a basic template).
- output file name (defaults to profile-dir/firebug/template-name.html)
The results of these picks are stored as defaults for the next run (TODO)
Testers then pick "Certified Testing" > "AutoRun"(TODO) or "Install", "Test", "Export". If the results are satisfactory, the tester uploads the output file. Else the tester reports problems somehow.
The testing features layer on the swarm extension and FBTest. The testShell is just a web page running in the FBTest window and instrumented by the swarm-install functions. The shell, swarm definition, and output template all rely on specific HTML class or id values which need to be documented (TODO).
Designers work on the swarm declaration and output template pages. These are standard Web pages with magical class and id values known to the swarm extension.
This page informs users about the individual extensions in the swarm. The user needs to get an overview from the page and have the option to dig deeper for more information. Generally the page should resemble a list of cool features implemented by individual contributors; the fact that these features are implemented by extensions is a not-very-important detail for average users.
This is the page seen by users when the select a swarm to install. The page has two
iframe elements, one Swarm Definition and one Test Results, populated by
data: URLs created during the testing. The Swarm Definition is just the Swarm Declaration, modified by the swarm test and exported as data-url encoded HTML. The modifications include (TODO). The Test results are plain text.
At least until we have some experience, the style information should be self-contained in the Swarm Declaration page. The style of both pages here can be modified, but the UI must allow the user to see the test results easily.
Developers creating Firebug extensions will operate like testers but they will typically use the 'pre-test' workflow rather than 'certified testing'. Often the extensions listed in the swarm definition will be file links rather than downloads. It won't make sense to export the test result in this case. The setup will work with Chromebug running.
Developers working on swarm tools can read on.
Overlays browser.xul, firebug's browserOverlay.xul, and testConsole.xul. Adds buttons to launch swarm-list and watch the operations on that page (TODO).
- separate swarm-install from swarm-test
- make swarm-install self contained (no FBL).
The swarm-test code is essentially a new implementation of outer wrapper of FBTest.
The chrome around FBTest is now minimal. Inside is a
browser element called "taskBrowser". It gets loaded with a 'shell', which is a Web page containing a 'workflow' header and iframe elements. The workflow header lists workflows, each workflow has a list of buttons. Each button works on one or more iframe element. The buttons and iframe elements are connected with magical class names.
When the tester selects a workflow, the corresponding list of buttons is activated and they selectively hide/show iframe elements according to the UI needs. When the test clicks on steps in the workflow, the operation uses the iframe info, for example, reading the test case list and writing results into the result frame. When a step completes the next step is activated.
Each workflow has "auto-run" button (TODO) to run all successful steps in succession; the selected workflow is pre-selected based on the previous selection (TODO); command line option allows autorun of a workflow (TODO).
The workflow steps (buttons) are defined by extending
Swarm.WorkflowStep and implementing the methods in that object. The methods are documented in
workflow.js. Examples include
The workflows are defined in
swarmWorkflows.html as lists of HTML buttons with magical class names.