Enhancement: Left-aligned Checkbox for Card Component

[r-watkins]

Description

Proposing that the selectable card component's checkbox either be left aligned or have the options to change the alignment to the left when it makes sense for the developer to do so.

Acceptance Criteria

• Make card component's checkbox either be left aligned or expose a property to change the alignment to the left

Relevant Info

I am referencing the card design here with the selectable option: https://esri.github.io/calcite-components/?path=/story/components-card--simple

And the Tile Select Group: https://esri.github.io/calcite-components/?path=/story/components-tiles-tile-select-group--light

Example Use Case

Traditionally we see checkboxes as left-aligned and I've come across an instance of a developer adopting the right-aligned patter in a list with a select all option which may be anti-pattern enough to confuse users.

I can't really find any examples that says this is wrong in anyway but I wonder if it is worth a second consideration in an effort to create a consistent look and feel.

As a example of the left-alignment patterns that exist already in our products we have the content list from ArcGIS Online:

And the selectable Tile from Calcite Components:

[driskull]

For consistency, i'd prefer to just choose one and not have it configurable.

[macandcheese]

Let’s go w left aligned cc @bstifle -

@r-watkins can you also add the issue for using a calcite tooltip so it’s more noticeable than the native label on hover ? Thanks!

[julio8a]

Agreed, for visibility left alignment works best.

[TheBlueDog]

In terms of information hierarchy, I feel having it on the left in the common card use gives it too much importance. My preference would be to keep it on the right. The use in the selectable tile component creates a really odd left margin.

My vote would be keep it on the right, or allow the consumers to switch it based on the context of the app.

[TheBlueDog]

I might not mind them on the left as long as they looked like Online does.

[bstifle]

good point @TheBlueDog

Maybe we could drop the opacity of the white fill a bit, in the checkbox

[bstifle]

hmmm, but with busier backgrounds the drop in opacity is a little rough

[bstifle]

that being said. i dont think it's fair to just keep it to one side. i think making it configurable is more inline with how Tile handles the selection side, which allows for start and end placements

[TheBlueDog]

In that last example having it on the left looks like a mistake. Definitely competes with having any sort of icon there.

[bstifle]

@TheBlueDog it can exist without the icon as well, had to account for both

[TheBlueDog]

@bstifle Yeah. Those examples look much more purposeful. I think this makes a good argument for letting the consumers configure which side its on.

[bstifle]

100% my argument. I dont see why we cant have both ✨

[driskull]

It just seems like having two different designs for the same UI will lead to inconsistency. The whole point of calcite components is for design consistency. I think we should choose whether the checkbox goes on the left or the right.

If we are going to let them choose we should have some guidelines on when to use which and not to use both designs in the same app for UI consistency.

[bstifle]

Agreed about consistency. But we also have a lot of flexibility, which allows for inconsistencies. Alerts for example, can have and icon, or not. Can be dismissible, or auto-dismiss. We can have icons at the start of a button, or at the end, or both.

like you said, i think good documentation + freedom in placement is the stronger case.

[driskull]

I think in those cases its more about adding or removing functionality. In this example it just seems like a design preference.

[bstifle]

buttons start or end is not about functionality. neither is rounded or square buttons.

[bstifle]

if we are going to leave things to design preference, I prefer the checkbox on the right. seems better for the hierarchy.

[driskull]

If we do give the choice, we just gotta document good guidelines. We should have them for things like square vs rounded buttons too.

[bstifle]

Agreed and agreed

[TheBlueDog]

@driskull Problem is with being overly strict is that there are so many ArcGIS applications, we can't really know every context. Provide some documentation on what Calcite's "preferred" use is, but let the designers and developers make the choice for the app.

[macandcheese]

Candidly it seems like nothing other than visual preference (of which I don’t really have one).

It does seem like unnecessary design fragmentation that will lead to a less cohesive experience across ArcGIS apps.

If one had a different meaning, function, etc. having two seems more justifiable, IMO.

[driskull]

I feel the same way but it seems like there are some strong opinions on having it customizable. :)

[jul11557]

In case you guys want a product perspective: yes, we prefer customizable! :D We're about to implement this component as currently designed, and if you swap the position of the check we will have to revisit this component to see if the new placement still works. This seems like a minor level of customization...it doesn't seem like the checkbox position would cause any major inconsistency. (Also agree with @bstifle if we're talking design opinion, I much prefer it on the right.. it's less intrusive and creates the focus on the content of the card.)

[driskull]

IMO its a design decision that the calcite design team should be making and not leaving up to each team to decide. It seems a bit of a cop out to do that.

If we are going to do it, we should have some sort of a property to toggle based on whether the primary goal is the card's content or the checkbox. That way there is some meaning to having it right/left and not just a design preference.

[julio8a]

Thanks for chiming in all. This is a small level of detail, and I don't see a big enough use case(s) for adding the left/right option or moving it to the left. There is an impact on hierarchy and a level of subjectivity/preference on the placement.

Since just moving it will cause visual disruption on the current implementation and there isn't a strong enough use case or benefit for having the options, we will leave it as is for now.

We do want to create flexibility in the components to meet different product needs. I appreciate the discussion and I encourage the dialog for how we can continue to improve our system, make it more flexible while maintaining its integrity and consistency. Will leave this thread open until the end of the week if there are any more thoughts on this topic.