Hey Patrick, I wanted to get your input on whether or not this might be a good candidate to consider using mult-column layout over grid (see Part 1 patch) to improve on the responsiveness of the modal and variable number of devices.

I think it's perfectly valid to use css grid here. It allows for responsiveness just as well, if not better, than css mulicol.
In order to improve the responsiveness of the modal, I think we should add a few media-query breakpoints to drop down to 2 and then 1 column, as space reduces.

A proposal:

1000px:

phone phone custom
tablet laptop tv

600px

phone phone
tablet laptop
tv custom

< 600px

phone
phone
tablet
laptop
tv
custom

Using grid-template-areas for this would be awesome! You could just use these name right there in the .device-modal-content rule (and redefine the areas in the media queries), and then just use grid-area in the different .device-type-phones, .device-type-custom, etc. rules.

At the same time, it might help making the modal itself. It has a 800px max-width, which is fine to avoid it looking weird on extra large screens. But then it has a 60% width (60% of the browser window's width) which makes it look really tiny when the window becomes small. I would increase this 90%. It won't change anything in most situations (because of the max-width), so the original design is preserved. But it'll look way better below 800px.

I think we might want to land Part 1 after the merge since the release candidate will be made this immediate Monday.

(In reply to Gabriel [:gl] (ΦωΦ) from comment #8)

I think we might want to land Part 1 after the merge since the release candidate will be made this immediate Monday.

This sounds good to me. Landing after merge will give us more time to test the new design and device editing.

Try server link: https://treeherder.mozilla.org/#/jobs?repo=try&revision=cfa373d9fc8c0364a444c79a2f94e2eacd63cb32

https://hg.mozilla.org/mozilla-central/rev/fbdd97d8e41d

Quick note: since one patch landed here and the bug wasn't marked as "leave-open", it got marked as RESOLVED/FIXED in 68.
However part 2 patch hasn't landed.

It's a good idea to use the "leave-open" keyword when we expect to be landing patches at different times, so bugs don't get closed in between.
It's however sometimes a bit dangerous because it sometimes happen that we land 1 part, but never anything else, and the bug never gets marked as closed because of that.
In this particular case, part 2 seems ready, so it might be ok to mark this bug as re-open and land the part 2.
But I think it might be just as easy to file a new one just for the device editing capability, and move the patch there (as we do that, we should also make sure this new bug blocks bug rdm-ux and bug 1493094 as this one does).

Micah: do you want to do that?

Patrick: Let's create a new bug for part 2 and land it there.

Comment on attachment 9048655 [details]
Part 2: Add ability to edit devices

Revision D22180 was moved to bug 1536808. Setting attachment 9048655 [details] to obsolete.

Just want to make sure what I need for 68 vs. 69. For 68, only the UI update, correct?

(In reply to Irene Smith from comment #17)

Just want to make sure what I need for 68 vs. 69. For 68, only the UI update, correct?

Hi Irene, for this specific bug yes this is only a UI update. But we also added the ability to edit devices in bug 1536808.

I have created new images for the UI and updated the text to match on Responsive Design Mode

Please review and let me k now if I missed anything!

Hi Irene, I apologize for the delay in reviewing this. It looks good to me! Thank you for working on this :)

One suggestion: it would be nice if the article can also have a section detailing the ability to edit custom devices. You can do this by hovering over a custom device in the settings modal and clicking the pencil icon that appears beside it. This will be showing a form similar to adding a device, except for editing.

Thanks for the suggestion. I will add a sentence or two and an image to show editing an existing custom device.