Checkboxes in images page got replaced by radio buttons

[bjornt]

Describe the bug On the images page, /MAAS/l/images, there are now radio buttons for the Ubuntu releases, rather than checkboxes, like it was in 3.0.

I remember we did this change in some previous cycle (can't remember if it was 2.9 or 3.0), but decided it wasn't the right solution, since it optimizes for the edge cases (different arches per series) instead of the common case (same arches across all series).

Was this an intentional change? If so, what has changed since the last time we did this?

maas-ui version bfdd8ce11b19f4834bb25538f7d6497154e12663

MAAS version bfdd8ce11b19f4834bb25538f7d6497154e12663

[anthonydillon]

Seems like this was introduced and questioned here: https://github.com/canonical-web-and-design/maas-ui/pull/2776#pullrequestreview-683487234

[Caleb-Ellis]

Hi @bjornt, my understanding was that the first time the radio buttons change was implemented it was reverted only because it was too close to release, not because the UX was wrong. So this was an intentional change as part of the React migration - to kill two birds with one stone.

Besides that I don't think the UX of the checkboxes is right. Before 20.04 there was no such thing as "unsupported architectures" so we didn't really need to care about specific release/arch combinations. Now that we do, the checkbox approach requires that what is checked doesn't necessarily translate to what shows in the image table/sent to the api, so we'd have to code in exceptions like in the legacy codebase (which I'd prefer to avoid replicating). I'll see if I can come up with a different approach that isn't messier to code and would still optimise for the common case.

Pinging @amylily1011 if you had any thoughts on this as well?

[bjornt]

On Mon, Aug 23, 2021 at 05:18:31PM -0700, Caleb Ellis wrote:

Hi @bjornt, my understanding was that the first time the radio buttons change was implemented it was reverted only because it was too close to release, not because the UX was wrong. So this was an intentional change as part of the React migration - to kill two birds with one stone.

Besides that I don't think the UX of the checkboxes is right. Before 20.04 there was no such thing as "unsupported architectures" so we didn't really need to care about specific release/arch combinations. Now that we do, the checkbox approach requires that what is checked doesn't necessarily translate to what shows in the image table/sent to the api, so we'd have to code in exceptions like in the legacy codebase (which I'd prefer to avoid replicating). I'll see if I can come up with a different approach that isn't messier to code and would still optimise for the common case.

It was too close to the release, but it was also unclear whether it's actually an improvement. Changing the UI is always disruptive to the user, so there should be a good reason for changing it. Especially since this UI looks very similar to the old one, but works completely differently.

Did we have any complaints on the existing UI? I'm not saying that it's a good UI, but it feels like we need to do a proper design with a spec, so that we can agree on what problem we actually are trying to solve here.

Do we have data on that people in general want to have different architectures available across the different series?

[amylily1011]

I don't have any data for this at the moment. I can try to dig deeper and check again, in case I miss anything. I don't have a problem with the UX if it correlates with logic in this selection. :)

On Tue, Aug 24, 2021 at 11:57 AM Björn Tillenius @.***> wrote:

On Mon, Aug 23, 2021 at 05:18:31PM -0700, Caleb Ellis wrote:

Hi @bjornt, my understanding was that the first time the radio buttons change was implemented it was reverted only because it was too close to release, not because the UX was wrong. So this was an intentional change as part of the React migration - to kill two birds with one stone.

Besides that I don't think the UX of the checkboxes is right. Before 20.04 there was no such thing as "unsupported architectures" so we didn't really need to care about specific release/arch combinations. Now that we do, the checkbox approach requires that what is checked doesn't necessarily translate to what shows in the image table/sent to the api, so we'd have to code in exceptions like in the legacy codebase (which I'd prefer to avoid replicating). I'll see if I can come up with a different approach that isn't messier to code and would still optimise for the common case.

It was too close to the release, but it was also unclear whether it's actually an improvement. Changing the UI is always disruptive to the user, so there should be a good reason for changing it. Especially since this UI looks very similar to the old one, but works completely differently.

Did we have any complaints on the existing UI? I'm not saying that it's a good UI, but it feels like we need to do a proper design with a spec, so that we can agree on what problem we actually are trying to solve here.

Do we have data on that people in general want to have different architectures available across the different series?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/maas-ui/issues/2994#issuecomment-904537107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMR3HWHOKG67R4H3ENYJSTT6N3IDANCNFSM5CUKLT6Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

-- Amy Pattanasethanon @.**) Lead UX Designer Canonical | Ubuntu* - MAAS | Web Team

---

MAAS-Design mailing list -- @. To unsubscribe send an email to @.

[Caleb-Ellis]

It was too close to the release, but it was also unclear whether it's actually an improvement. Changing the UI is always disruptive to the user, so there should be a good reason for changing it. Especially since this UI looks very similar to the old one, but works completely differently.

That's fair. I can see how the similarity could mess with users' expectations.

Did we have any complaints on the existing UI? I'm not saying that it's a good UI, but it feels like we need to do a proper design with a spec, so that we can agree on what problem we actually are trying to solve here.

My main complaint with the checkboxes is as I said above - with some architectures being unsupported we now have to care about specific release/arch combinations. It's an extra step of adding workarounds and validation to make sure incompatible combinations aren't represented in the UI, e.g. it's possible to check 20.04 LTS and i386 where we then have to explain to the user "oh you actually can't do that, ever". So then why make it possible to do that at all?

Having said that I think the radio buttons satisfying my own personal gripes with the checkboxes shouldn't be the only reason to make the change. I think you're right we should have a proper spec, which I imagine will be a larger redesign of the images page (that has more issues than just this). I'll make the change back to checkboxes and replicate what we have in 3.0 until then.

[Caleb-Ellis]

This is going to have to wait until next cycle as we're in crunch time to land LXD cluster support

[Caleb-Ellis]

The Images page needs UX work, maybe as part of the new layout. Moving to Icebox until we decide to build new changes.

[amylily1011]

+1, I think I will follow up on the New layout work next week. And send it in for peer review with the team.