[Inspector - Rule View] Adding a property to a rule

[nchevobbe]

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!

[nchevobbe]

note that both Safari and Chrome have the same behavior and no explicit UI for this

[luc4leone]

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.

[luc4leone]

@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)

[fvsch]

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?

[fvsch]

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.

[nchevobbe]

we'd have to check if that's enough when you have disabled property at the bottom, so it still stands out

[SebastianZ]

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

[nt1m]

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 :)

[luc4leone]

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?

[luc4leone]

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.

[luc4leone]

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?

[nt1m]

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.

[fvsch]

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: 10px to 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.

[luc4leone]

@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.

[luc4leone]

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?

1.

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?

[luc4leone]

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."

[fvsch]

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 {

}

[fvsch]

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.

[luc4leone]

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.

[luc4leone]

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

[violasong]

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

[digitarald]

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.

[violasong]

Example with + between the lines. The horizontal alignment is a little trickier here when lines widths don't match

[luc4leone]

Example of + between the lines on the left.

[nchevobbe]

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

[digitarald]

Both work for me. We probably want to see it in action to tweak further.

[luc4leone]

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?

[digitarald]

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.

[violasong]

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.

[luc4leone]

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

[violasong]

This prototype is awesome - thank you @luc4leone! I love how it invites interaction.

I see that this prototype requires clicking on the + to add. I had actually been thinking you could still click anywhere. I.e. the + would just be a visual indicator/placeholder, not a button. I think if we lighten it up a bit to #b1b1b3 that would help with this.

It seems best to keep the old click behavior as I feel people will be used to that flexibility.

One other thought was that the + wouldn't show up if you hover over the text/checkbox.

[violasong]

Couple more ideas for putting the indicator between lines

• + with shorter dotted line so it doesn't get mistaken with the hover underline
• + with short gradient line
• + with arrow head

[luc4leone]

@violasong iteration 2: https://luc4leone.github.io/firefox-ux-issue106/anywhere.html

• [x] the + would just be a visual indicator/placeholder, not a button. I think if we lighten it up a bit to #b1b1b3
• [x] I had actually been thinking you could still click anywhere
• [x] the + wouldn't show up if you hover over the text/checkbox

[luc4leone]

interesting ideas @violasong, can’t choose, I like them all. But I choose in-between lines compared to on the line :)

[violasong]

Thanks Luca for the new prototype and your thoughts on this!

Some folks mentioned that the indicator at the end of the line seemed a bit confusing, but I'm going to spread it around and see what others think.

We might want to preserve the existing behavior where clicking anywhere outside the input hides the input.

I saw you removed the indicator on checkbox hover - it would be great to remove it on text hover as well.

If you have extra time, I'd love to see a prototype of "+ between lines with shorter dotted line," with new hover decoration for the text of just a background color of #EEF9FF (so that it doesn't clash with the indicator)

[luc4leone]

Sure Victoria, I ll work on a new iteration next weekend, when back from vacation. I think I understood what you asked. I like it the way we are going forward, step by step, investigating possibilities.

[violasong]

Thanks Luca! Enjoy your vacation :D!

[luc4leone]

Victoria here's a new iteration to address your two observations:

• [x] "We might want to preserve the existing behavior where clicking anywhere outside the input hides the input."
• [x] "I saw you removed the indicator on checkbox hover - it would be great to remove it on text hover as well."

Then I addressed:

• [x] "+ between lines with shorter dotted line"

I did an iteration with background color change on mouse over as you suggested, but I'd like to show you also an iteration without background color change, because it doesn't seem to clash – what do you think?

[luc4leone]

Victoria, playing with the proto, I realized that once an input is visible, on mouse over the + indicator shows. I think it should not, since a click would just hide the input. Do you agree? Will work on an iteration to show you what I mean.

[violasong]

Thank you Luca, this is great! I see what you mean about keeping the dotted underline - it's not as bad as I thought. I think I slightly prefer the color change because I'm hoping we standardize on it for hovering over things that will highlight something in the page (though the design of it probably needs to be a bit higher contrast than it is currently).

Victoria, playing with the proto, I realized that once an input is visible, on mouse over the + indicator shows. I think it should not, since a click would just hide the input. Do you agree? Will work on an iteration to show you what I mean.

Agreed, I had this thought as well.

Mind if I tweet your next prototype on @FirefoxDevTools and include your twitter handle? It would say something like:

Feedback wanted: We want to allow adding CSS properties anywhere in a rule, and show a subtle indicator for it on hover. Here's a prototype by @luc4leone. How does the indicator feel? (link)

[luc4leone]

I think I slightly prefer the color change because I'm hoping we standardize on it for hovering..

right, understood

it probably needs to be a bit higher contrast than it is currently)

in case let me know, it's a 2 sec change

Mind if I tweet your next prototype on @FirefoxDevTools and include your twitter handle?

👍

[violasong]

Okay :) if you don't mind, let's try adding border-bottom: 1px solid hsl(210.9, 100%, 86.3%) (or something similar)

Also, would you mind changing the overall font size to .85em; (or whatever matches the default font size in DevTools?)

[luc4leone]

Victoria here's a new iteration. These are the changes:

• [x] when an input is visible, the --+ indicator will not be visible on mouse over li elements
• [x] added border-bottom: 1px solid hsl(210.9, 100%, 86.3%) to text on mouse over
• [x] "font size to 0.85em"

I improved some other minor details (e.g. the input focus blue outline that disappeared in part when hovering on the li element).

Ready for more changes ;-)

[violasong]

Feedback request - tweeted!

A few folks pointed out the --+ looks like minus next to the plus, which I realize is indeed confusing.

Nice mockup from Paul Rumkin with full-width line similar to previous ideas. I'm not sure we need the circle on the end but I like the general idea.

Here's an iteration from me - full line of lighter color:

Someone did mention that the indicator seemed like a tiny button that had to be hit, which is concerning. I'll ask more directly about this for a future feedback round.

Good polish thoughts from @fvsch

• when hovering the first line after the opening brace -> indicator above first declaration
• when hovering the last line after the closing brace -> indicator below the last declaration

A bonus thought I had about the hover target: Anything inside this blue overlay should not trigger the add indicator. The text hover boxes can be a little 'greedy' since there's so much room for the add hover box.

[rumkin]

@violasong Thanks for mentioning. The circle here is a drag-n-drop target indicator for inter-element space, which as I think is well-known. But it could be replaced with a vertical dash. Without the ending element the line looks orphaned and inaccurate IMO.

[luc4leone]

when hovering the first line after the opening brace -> indicator above first declaration when hovering the last line after the closing brace -> indicator below the last declaration

Insightful observations.

A bonus thought I had about the hover target: Anything inside this blue overlay should not trigger the add indicator.

When playing with the proto, I had this "unconscious" feeling that something was not right when seeing the add indicator appearing and disappearing when hovering horizontally over a property line: your thought clarify my feeling and, I think, solve the issue Victoria. I'll work on the next iteration. It will take a bit longer than usual, since I need to rebase and fix a patch about the editor line-wrap option.

It's great to get feedback from people!

[violasong]

When playing with the proto, I had this "unconscious" feeling that something was not right when seeing the add indicator appearing and disappearing when hovering horizontally over a property line: your thought clarify my feeling and, I think, solve the issue Victoria. I'll work on the next iteration. It will take a bit longer than usual, since I need to rebase and fix a patch about the editor line-wrap option.

Sounds good :D

Another suggestion received: Leave out the +, so basically going back to Florens' Mar 2 mockup but with the solid light gray line. Maybe that could be enough! Seems like it could feel a bit lacking when the line is at the top or bottom.

[luc4leone]

Victoria this iteration addresses your observation:

"Anything inside this blue overlay should not trigger the add indicator"

and @fvsch

• when hovering the first line after the opening brace -> indicator above first declaration
• when hovering the last line after the closing brace -> indicator below the last declaration

//

Another iteration where we can see Florens idea on the indicator without + in action.

//

After the tweet feedback I was wondering about the meaning we are trying to convey. Some people seem to be confused by the plus indicator. With the --+ we are both trying to hint to "where" (here, between properties) and "what" (add). I think you get where I am going with this, since you already draw it:

So we are trying to convey two things at once. An arrow seems like a common and effective sign to help people get the "where". Along this line of reasoning I changed the --+ in a <--. But so the "add" part is missing. What about the cursor, I thought, what if we change it? Maybe this is a nonsense idea, but maybe it can lead to better ones. Here's the result of my thoughts. The cursor is custom, I could have used css cell value (which would not have been good semantics) or pointer... anyway, not super important for now I guess.

[violasong]

Awesome, thanks for these! Currently, I'm leaning towards the line only, whether dotted or not - just for the smallest hint of "here." I think the + cursor is more technically correct, and your reasoning is good, but I feel it's a bit too unfamiliar in practice. Going to CC some folks for more opinions :) @martinbalfanz @gabrielluong @tigleym

Note: I'll be out of office next week - will write more when I return.

[luc4leone]

I feel it's a bit too unfamiliar in practice.

I agree Victoria. To investigate a bit further I changed the cursor to a - on click event. Then the cursor changing from default to + to - to text... made me think of a videogame :D Anyway my feeling after playing with it, is that in the right context, with the right cursor, this "cursor state + indicator" combination might help communication.