ux
ux copied to clipboard
firefox-devtools
[Inspector - Rule View] Adding a property to a rule
In the rule view, it's a common operation to add a new property to an existing rule. But that's something you have to know is possible, as there is no hints in the UI this can be done.
A new property can be added by clicking anywhere in the rule block, except on existing properties, location and selector.
This can be confusing, especially for people who are not used to those tools.
We could think of a way to make this more explicit.
A proposal would be to add a + button next to the closing curly bracket.
Since there's room, we could even go for a text button (Add property).
If we feel like this would be visually too heavy, we could only show the button when hovering the rule block.
Let's discuss!
note that both Safari and Chrome have the same behavior and no explicit UI for this
note that both Safari and Chrome have the same behavior and no explicit UI for this
right, but I think that what you explained
But that's something you have to know is possible, as there is no hints in the UI this can be done.
is true, and makes the UI less easy to learn than if there's a hint, as you proposed.
@nchevobbe visual summary of the options you proposed:
OPTION 1: + button
OPTION 2: Add property button
both can be enabled just on :hover as you wrote. Did I understand it right?
Another option I was thinking of is to do it the same as "Watch expressions" or "XHR Breakpoints" panes, where there's just text (a placeholder into a input with no outline)
The above sketches were done just to investigate the options visually, no focus on style (if needed I can redo them with the right style, if I have access to the Dev Tools style guide)
Tried the last approach without the curly braces to save some space:
Might be a bit verbose to have this or a button on each rule. Maybe keep the curly brackets but transform the } to Add property… on hover?
Related: missing a click target higher up in the rule block triggers the "new property" input mode and can be confusing, see e.g. bug 1600365.
we'd have to check if that's enough when you have disabled property at the bottom, so it still stands out
One thing I want to note is that Chrome allows you to add a property anywhere within a rule. This allows to overwrite properties right within a rule without having to replace the existing ones. It is also handy when you have a longhand property but want to define a shorthand one which gets overwritten by it.
This functionality might be out of scope for this issue, though it should be something to keep in mind when designing a visible UI for adding properties. So to save some space and allowing to add the aforementioned functionality in the future, I think an icon should be used. To make the action clear, there could additionally be a tooltip shown saying "Add new property by clicking" or something like that.
Sebastian
Safari's older rule editing UI was more editor like, where you could insert your caret anywhere, as opposed to separating property and value in separate editors. Each whole rule was an editor by itself. It worked pretty well IMO, and made it pretty obvious that you could add a new property by creating a new line. I guess they switched to a more conventional UI more recently for the sake of familiarity, but that doesn't mean that we can't take ideas from this :)
Might be a bit verbose to have this or a button on each rule. Maybe keep the curly brackets but transform the } to Add property… on hover?
@fvsch what if we display it on hover and to address what @SebastianZ wrote:
One thing I want to note is that Chrome allows you to add a property anywhere within a rule. This allows to overwrite properties right within a rule without having to replace the existing ones. It is also handy when you have a longhand property but want to define a shorthand one which gets overwritten by it.
we add a + for each property? Then when we click on + we display the new input element.
I think the functionality described by Sebastian, might be interesting for the user. Added benefit: we get the input appear close to where we clicked.
This way we also address the "missing target" problem bug 1600365 because when we miss the checkbox we never trigger adding the new input element.
We might add the + on the left, at the beginning of the property, where we have a straight edge, but it seems more natural on the right, where we mimic the creation of a new line.
Safari's older rule editing UI was more editor like, where you could insert your caret anywhere, as opposed to separating property and value in separate editors.
interesting @nt1m, I'd like very much to see it in action, any idea how can I do it?
The above idea seems in agreement with what is now the interaction (hovering over elements reveals visual hints to possible actions)...
...once we make the checkboxes on the left to display on hover one at the time.
I was thinking that it would be great to bring some of the freedom one has manipulating CSS rules in the Style Editor, to the Inspector. The Style Editor is "magical": no need to learn anything, it works like a standard text editor, and I see the effect on the page as soon as I type. The Inspector is different; I have to learn the "rules of editing" ;-)
This thread is about giving the user a hint about adding a property to a rule. @nchevobbe @fvsch you came up with some excellent ideas. Each idea, as intuitive for the user as it might be, move the Inspector editing interaction experience away from the Style Editor, adding a bit more rule, a bit more "learning." OK, in this case we are just trying to reveal a rule that's already there, but I guess you get the sense of what I mean.
What about if we try to do the opposite? What about if we try to bring some "editing freedom" to the Inspector? I have been experimenting a bit with document.designMode = 'on'; and el.contentEditable = 'true', and it seems to me something can be done maybe. What do you think?
interesting @nt1m, I'd like very much to see it in action, any idea how can I do it?
I think Safari 11 or 12 have this UI, unfortunately I only have Safari 13. Not sure how you can downgrade to test though.
we add a
+for each property?
Would love to see more stress cases for that idea.
I'm worried that in narrow columns or with properties which contain long values (e.g. grid-template-rows or anything with calc(), var(), etc.) it would be impractical to have an invisible element take up roughly 20px of space on each line. If the value pushes that button to the right edge, would it wrap to the next line and create an empty line? Would we wrap the value instead?
What about if we try to bring some "editing freedom" to the Inspector?
I like the idea, and making each rule a code editing instance (e.g. using CodeMirror, which DevTools is already using in a bunch of places) could be interesting. I'm afraid it wouldn't be compatible with a lot of features we have, which bring value to users:
- The enable/disable checkboxes: you need one per declaration, but how do you display it if the user writes
property1: value1; property2: value2;in a single line? Do you disable both declarations instead? - "Swatches" and other buttons that show the color picker, transform editor, shape editor, easing editing, etc.: not sure how easy it would be to embed in CodeMirror. VS Code (which uses Monaco for its editor) has color swatches, but in practice when editing code they often "lag" at the wrong place in the code for up to 1-2 seconds. If we end up hitting the same issues as VS Code did, that won't be much of a UX improvement.
- Shorthand expansion: we can expand a shorthand like
padding: 10pxto show all the values it sets for the longhand properties (padding-top, etc.). Would we just remove that feature? Make it non-editable and possibly outside of the editor (in an information tooltip)?
once we make the checkboxes on the left to display on hover one at the time.
I don't think we want to do that. If we hide then until that specific row is hovered, it would slow down users since they wouldn't see their target before hovering the target itself or its row. Ideally we wouldn't hide checkboxes ever, but it helps reduce visual clutter for when users are trying to scan the whole Rules tab, so hiding by default and revealing when hovering a specific rule (which is a large-ish box) is a decent compromise.
@nt1m I forgot I have an old macbook air, with Safari 11 installed (I checked a few min ago). Now I see what you mean by
Safari's older rule editing UI was more editor like, where you could insert your caret anywhere, as opposed to separating property and value in separate editors. Each whole rule was an editor by itself. It worked pretty well IMO, and made it pretty obvious that you could add a new property by creating a new line.
and I agree, it's more editor like, and once you feel you're in an editor you don't have to learn how to add a new line.
If the value pushes that button to the right edge, would it wrap to the next line and create an empty line? Would we wrap the value instead?
Did I understand the investigation you'd like to do @fvsch? You'd like to see something else or different?
If I got it right, I think you have a point when we have a narrow column. The case 2 above doesn't seem to work well. Would it be a workable solution to make the + button disappear on click?
I'm afraid it wouldn't be compatible with a lot of features we have, which bring value to users
I didn't consider these details @fvsch, let me think about them. Thanks for the comment Florens, insightful and challenging ;) It would be great to make the rules editing more "familiar", more editor-like, but of course without giving up "features... which bring value to users."
Not fond of any layout shift on hover. We have a lot more interactions in a rule than just "add a new declaration", so we shouldn't distract users away from those other interactions if possible.
I like the Editor mode, but I wonder if it should be a modal option, with a button or a right-click action to drop into Editor mode. A bit like what we have in the markup view, were you can edit text nodes, attributes, element names, add attributes etc. in the normal mode, and drop to an "Edit as HTML" mode too.
Not a perfect solution because it's less discoverable and users have to manually switch modes, but it could still work, especially if we use it by default when adding a new rule (the "+" button in the toolbar). A new rule could be an editor with this content:
.generated-selector {
}
In "normal" mode, I still like the idea of being able to add a declaration anywhere in the rule and not just at the end of the rule. Rather than using a "+" button, I wonder if we could show a border or line between rows on hover, where a property input would be added on click:
We'd have to figure out the hitboxes carefully, so that it only shows when hovering the empty space at the right of values, or the last line (on or at the right of the }).
This could add some of the affordance we're missing right now.
I wonder if it should be a modal option...
going modal seems a great idea to me. We keep the best of the two worlds with the cost you mentioned. Once in "Edit as CSS" mode, just to name it after his markup brother, one would need to get out of it to see the changes as in "Edit as HTML"? I am asking because direct text manipulation aside, the other big thing about editor-like UI (e.g. Safari 11) is the immediate visual feedback you get when you change a value. Helping the user learn the editor-like mode by making it the default mode when adding a new rule through the plus button is also a good thing.
I wonder if we could show a border or line between rows on hover, where a property input would be added on click
just an iteration
Sorry to get to this thread so late. I really like where these ideas are going!
And I'm glad Sebastian mentioned the feature of adding a property anywhere within a rule. As a parity issue, this might be more important than the original issue :).
With the current design, the dotted line might clash a bit with the dotted underline on hovering properties/values (however we might want to change the latter). Maybe we could just do the subtle + sign, not as a button but an indicator.
cc: @digitarald @martinbalfanz
Maybe a mix of @luc4leone's line and @violasong's +, when the plus is aligned between the lines? Subtle is important, as this will show up for a lot of hovering on the rules pane.
Example with + between the lines. The horizontal alignment is a little trickier here when lines widths don't match
Great to see this move ahead!
The + by itself is pretty light and might be hard to miss. We can probably put it in a solid circle
Both work for me. We probably want to see it in action to tweak further.
We probably want to see it in action
is there a bug open @digitarald ? by "seeing it in action" you mean that right, coding it?
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1652802 for the code, in case the community wants to help to ship this faster.
Yep, will be great to see it in action!
This good-first-bug is just for the indicator, and not for adding anywhere in the rule. So we would start with just an indicator in the last row. For the first pass, I'd err on the side of something subtle as to not distract those who are used to all the non-indicating UIs.
This would be consistent with my previous proposal. It's little awkward when stuck to just the last row, but would be safe enough.
I kind of expect to see the plus sign here, but it would be too weird to be outside of the brace.
Braceless: Not sure about this — since it looks less like CSS it would be a bit less newcomer-friendly. Would require more investigation.
I am not sure this is enough for a "see it in action" https://luc4leone.github.io/firefox-ux-issue106/index.html @digitarald
I tried to implement @violasong proposal. Some notes:
- I can quickly iterate, just ask me ;-)
- I didn't implement the "insert a new property, with the auto-suggest", because I was not sure this part of the overall functionality is what we are trying to get a feel for
- I wanted to implement a vertical splitter, to adjust the width of the text and see how this breaks the lines and where the + goes, but I thought we can easily do this by opening a dev tool to the right of the page and then play with its width