|Status note||Shifting gears. Breaking this into two separate features with different priorities and moving the UX design piece off to the near future.|
|Product manager||Kevin Dangoor|
|Directly Responsible Individual||Kevin Dangoor|
|UX lead||Stephen Horlander|
|Product marketing lead||`|
Stage 1: Definition
1. Feature overview
The "Infobar" is part of the Page Inspector and appears around the highlighted element on the page. The first iteration of the Infobar provided the tag name, ID and classes for the element. This improvement to the Infobar adds features to allow the user to make common changes to the element quickly.
The most important part of this feature is the ability to set pseudo-classes for use in inspecting styles. For example, CSS styles that are applied on "hover" will naturally go away when you switch to the Page Inspector, because you're no longer hovering over the page element you're trying to examine. This feature adds to the infobar a mechanism for making "hover" and other pseudo-classes sticky while you're using the tools.
Toggling classes and setting IDs on page elements are also useful styling features that fit naturally into the infobar.
2. Users & use cases
Anyone doing web design uses this feature.
Examine Hover Styles
It's common to set styles that appear only on hover, so the user needs a way to dig into those styles, see how they're being applied and possibly tweak them using the editing capabilities of other parts of the tools suite.
See the effect of a class
When tracking down styling issues, especially on elements with multiple classes applied to them, it can be useful to visually see the effect that a given class is having on an element. A convenient mechanism for toggling a class on an element is a good way to accomplish this.
Set an ID on an element
Stage 2: Design
5. Functional specification
Selected in the Page Inspector
Pseudo-classes can be toggled in the page inspector so that they can apply to any element-oriented tool (F1).
The user can toggle any of these four common pseudo-classes (F2):
Those are the four pseudo-classes supported by the most popular developer tools. There are other pseudo-classes that we should try to support as well (F6):
Many of these can be set in a "sticky" way by the user in the UI of their application. However, it would be more convenient as they're reviewing the styling for an element if they can just "pretend" to have checked the checkbox, for example.
The tag name (F9) and ID (F10) can be edited.
A command line command can also toggle pseudo-classes on the selected element (F3). There should also be command line commands for toggling classes (F7) and setting the ID (F8).
One open question to acknowledge: when there's a separate tools window we may need a separate UI for doing this same thing from within the tools window.
Pseudo-classes stay set until the page inspector is closed (F4). All pseudo-classes are reset to their original values when the tools are closed. This will also require some thought for the interaction with a separate tools window.
Lifetime of Other Changes
Toggled classes and changed/added IDs remain in place after the tools are closed (F9).
Support in Other Tools
6. User experience design
Stephen Horlander offered the suggestion of putting a + at the end of the highlighter Infobar, and Paul Rouget had the suggestions of the click behavior on existing Infobar elements.
- double-clicking the tag name or ID switches the label to a text box for editing.
- classes and pseudo-classes can be toggled by clicking on them in the Infobar. If the user switches to another page element and then back after turning off a class, that class will be gone from the Infobar.
- Clicking the + displays a text field with placeholder text along the lines of :pseudo, #id, or .class.
- If the user types :, it would the field would contain ":active, focus, hover, visited, ..." with all of the text but the ":" selected.
- ":a", ":h", etc. should autocomplete to the supported pseudo-classes
- if the user starts the field with anything but "#", "." or ":" the field should turn red (or otherwise show the error state)
- if the user types "#" and the node has an ID, the existing ID should be placed in the field, preselected with the cursor after the #
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||`|
Team status notes