A better (faster) way to define borders?

#1

Let’s say I want to add a border-bottom to a box. As of right now, when I go to the styles tab, I click the “Individual sides” button in order to edit individual edges. This automatically gives the element 4 borders. So at the very least I have to click on each of the 3 borders that I don’t want, and then set all of those width values to zero. I feel like there could be a faster way to do this.

Also, as a side concern, what’s the reason behind giving each border-side its own row in the border panel? I think it would be more intuitive if there was a representative interactive box. But I’m sure you guys have thought this through, as you usually do.

#2

Hey @ldubya,

Agree that the border control needs work. Building on the issues that you mentioned, here’s what I think are the problems:

  1. The behavior when toggling between “all sides” and “individual sides” isn’t clear. What gets carried over, what gets removed?

  2. Initial toggle from “all sides” to “individual sides” fills in each individual border value, which is tedious to unset.

  3. Each side has a row, which makes the control really tall, isn’t necessary, and is tough to parse at a glance.

Did I miss any? There’s nothing too technically difficult in this list, we just have to make some design decisions. I’ve punted on this, but I’m happy to work it out together and then implement.

In terms of #3, I think there are some examples for how we could condense the control. Webflow’s control for this is decent:

image

Another option is something like this mockup from Davide Pisauri:

Neither of these allow you to style multiple sides at one time. (e.g. “Make the top and bottom 4px solid red”) Do you think that’s necessary, or is doing one at a time good enough?

In terms of #2, is preserving values (color, stroke width, stroke style) between the modes (all sides or individual sides) necessary? If no values are carried across, that makes things conceptually a little easier.

If values should be carried across, which side should we pick to define “all sides?” Right now we pick the top, but there’s really no reason that side is any more important than any other.

My suspicion is that carrying values between the modes probably isn’t a common use case. What do you think?

#3

Is this a use case for letting us have variables that can be set once and then assigned and modified as needed?

Would be great if I can just tell subform “I want this box called Box_A to inherit these characteristics defined in variable X”. So if X says the top and right borders are 4px solid red, Box_A now picks up these characteristics. And then as X is changed, the boxes redraw. Would be useful in larger projects where you want to use a set color palette and then you decide to change a color and have to go around clicking on everything that had that previous color and manually update. And same with border widths, etc. And Box_A would only inherit the characteristics that are unset in Box_A, so that inherited characteristics can also be manually overwritten.

I wouldn’t expect values to be preserved correctly. Either out of mistrust, or from not having the confidence that I know the mechanism the tool uses to preserve values. So I would end up checking everything just to be sure anyways. Not sure if it would save much time.

#4

Variables are definitely an intriguing proposition, but we’re not quite ready to work on those yet. :wink:

For the purposes of getting a better border control in the near term, I think I was more concerned about speed of input: if the top and bottom are both 2px solid red borders, should you be able to select both “top” and “bottom” and input that information one time, instead clicking on each and setting individually?

Is this a common enough use case that it would save a lot of time?

That would definitely simplify the control. Any thoughts on what defaults you’d like to see? No border until you set one? Would you want the defaults to be different for the “all sides” mode, vs. the “individual sides” mode?

#5

Can’t think of a better way to suffieicntly address this. But it would really be all in the implementation.

Yeah I think it would be great if we could shift-select each item we want to modify and then just type.

But I also think it would be a major time-saver if I could copy-and-paste the border styles onto another element.

Being able to edit a single definition and it applies to everything that’s inheriting it would be my favorite choice. For fonts, colors, borders, etc. Things that designers try to keep consistent across the board and would like to edit quickly and see the changes quickly to fiddle around. Instant feedback is such a great thing to have. It’s very demotivational when you want to see what a font change or color change, etc, would feel like, but have to click through a bunch of elements to see the change.

#6

I would use caution with how this “copy/paste style” functionality could work. What you are describing here sounds more like what “components” and “classes” are used for in Subform, which is explicitly saying: “I want to use this component/class style on multiple components throughout my document so that any changes I make to this component/style is propagated in all instances where this component/style is applied”.

Although the ability to copy/paste a style is a quick and useful way of applying a look and feel to multiple components in the discovery phase of the design process, I believe it should be limited to only applying that style without linking it to every component.

#7

Just an update on this topic: we added some changes to the border control in Subform release 3743.

I may write up a more detailed post on the design decisions behind this control, but the tl;dr on it:

  • Eliminates toggling between “all sides” and “individual sides,” so it’s not confusing what values get carried over and which don’t
  • Individual sides or “all sides” can be toggled with a checkbox, so defaults (e.g. 1px solid black) don’t apply when you just want to specify a single side
  • Control is much more compact and easier to parse at a glance

Give it a spin and let us know what you think.

#8

As I state in my post,

Anyways, I don’t think forcing people into using classes when they just want to do something fast is the right move. Speed is the goal. Sometimes components and classes enable that. Especially when you need to make sweeping adjustments that are tedious to change on individual elements. Sometimes being able to simply copy and paste without having to sidetrack into constructing a component as a glorified scaffold enables that. Any decent designer can make their own decisions as to when they need to create a component and when copying and pasting will suffice. I’d even argue that extraneous components add clutter, when one utility of components is to declutter. Especially since the components in subform are not nested.

#9

I agree with you that having a “copy/paste style” feature would be a great idea as a quick way to apply the same styling to multiple UI elements at once. Are you saying that this “copy/paste” feature would be a “shortcut” to creating a class/component? I would also agree with that idea. I guess where I’m confused is the part where you say:

That sounds like what components and classes do.

#10

Since this product is a work in progress and is in flux, as part of this discussion I have given lots of different preferences about things. Some of my preferences may already exist, or they may not exist. But I still think it’s important to list what those preferences are, because when something is in flux, in addition to the possibility of new things being added, there’s also the possibility of old things being removed.

As for the reason why I didn’t outright say classes… When something new is being created I prefer to avoid using names, and instead use descriptions. Would rather describe desired functionality than give a name. Leaves more to the imagination. Just my philosophy.

I don’t necessarily want classes. I want what I described. Classes do fit that bill, and I’d probably be okay with them if they were determined to be the solution to the problem. But who knows, maybe there’s an even better way that fits the bill. If it turns out that there is something else that will also achieve the desired effect, but in some other way shape or form is better for Subform, then awesome.