1493444 - Create an HTML mockup for the internal configuration user interface

Status: RESOLVED FIXED

(Toolkit :: Preferences, enhancement, P1)

Description

[:Paolo Amadini]

We will use an HTML mockup, accessible on the web, to prototype and design the interaction and the look and feel of the new internal configuration user interface.

Comment 1

[Matthias :Kammueller]

the mock-up may be found at:
https://kammueller.github.io/new-config/index.html

Repository: https://github.com/kammueller/new-config

Comment 2

[Matthias :Kammueller]

TODO: add a toggle-button for boolean values

Comment 3

[:Paolo Amadini]

Great job on the mockup, Matthias! We'll continue to iterate on it like we did in the past weeks, but we're at the point where we have a clear guide we can use. Also thanks to Amy for the first pass design review.

Can you post one or more screenshots on this bug for future reference? Before doing that, I suggest you pull some examples of actual representative preference names and values to the mockup, maybe using Vincent's patch from bug 1497637 to see those at a glance.

Also, let's document the research you did on grid versus table layout, and lists versus table markup. You found that grid layout and list markup has good baseline characteristics and solve a problem you had with table, so it'd be great if you can explain the problem you had and the different solutions you ruled out.

Comment 4

[Matthias :Kammueller]

Okay, so we have the basic layout, which divides into three areas.
On the left hand side we have a navigation, which filters after components (= the part before the first dot). There are two special filters: "Everything" which resets the filter and "Favourites" which only displays preferences [prefs] marked as favourite [fav].

On the top we have a sticky container which does not scroll out of view, containing the Search field (with options), the table header and the option to add a pref. The latter can be expanded by clicking the heading.

The table itself has five columns: The first is used to mark prefs as fav / demark them. This is also used if a pref is locked. Should a favourite pref be locked, the fav-status will be locked as well. Following is a text-field to change the value and a save button. For boolean-values the save button is replaces by a button reading "toggle". The last column features a reset button which is only enabled for modified values, which are also highlighted with bold font. If there is no default-value for this pref available, the reset-button is replaced by a delete button.

Should you enter an unvalid type of value, you will be notified using HTML5-Form-Feedback. Same if you try to add a pref that already exists.

There's also a collapsed layout for screens smaller than 830px.

The whole page is styled according to the photon standard, except the Form-Feedback. Here I'm using the standard Firefox technology and I do not know how to design that.

Comment 5

[Matthias :Kammueller]

Attachment: The layout of the page

Comment 6

[Matthias :Kammueller]

Attachment: The Add-A-Pref Form including Feedback

Comment 7

[Matthias :Kammueller]

Attachment: The Collapsed Layout

Comment 8

[Matthias :Kammueller]

**a11y and grid **

I decided to use Grid to lay out the table since we want the table to take the available width of the screen, but the columns with the buttons should only be as wide as needed. Since we do not know how long translated "save" and "toggle" texts will be, we need some kind of responsiveness. Grid offers this out of the box, an alternative way would be to measure the width of save and toggle button using JavaScript and thus forcing the width on the column using JS. This however seems, to be, like a workaround.

To check whether grid is fast enough, I built a test with 2000 columns, using the same DOM structure as in my mock-up with the possibilty to change the width of the "auto" column by changing the text inside. On my systems the changes were adapted in no time. https://kammueller.github.io/new-config/grid-performance-test/

A problem of grid is the lacking support of a11y, because I needed to use display:contents to create logical rows in the markup. However, this is only supported for lists, so every row=pref is represented as a list of options.

To make the complete page accessible, I added some aria-labels and hope that this should do. I tested the page with the NVA screen reader.

Comment 9

[Matthias :Kammueller]

I still am in contact with Matt and Amy, we want to sort out some minor changes.
So a huge thanks for them for delivering their feedback!

Comment 10

[Matthias :Kammueller]

Attachment: Add-Preference-Modal.png

We updated the Add-A-Pref form to be a modal, which will be triggered by a button.
The design will be discussed in the next week's design meeting [as far as I understood ;-)]

Comment 11

[Tim Nguyen :ntim]

I like the mockups so far.

One thing though, I'm seeing a lot of new photon styling in the mockups. Can the toolkit/ common.css stylesheet be updated accordingly ? I'd rather not end up with about:config suddenly using its own custom styling... If you're interested in doing this work, there are some bugs filed under bug 1392389, feel free to file more if needed.

Comment 12

[Matthias :Kammueller]

Thank you very much =)
I contacted you on IRC with some questions

Comment 13

[:Paolo Amadini]

(In reply to Tim Nguyen :ntim (please use needinfo?) from comment #11)
> One thing though, I'm seeing a lot of new photon styling in the mockups.

Yes, this is something we already discussed during our meetings. It is to be expected that mockups are always well ahead of product, in particular for the visual design aspect, but also for the features they describe. Definitely not all of this will make its way into the final version, and, when implementing our Minimum Viable Product, we'll have to reference mostly the current Firefox code rather than the code in the mockup. For us, the mockup will mainly provide guidance so we can build a mental model of what we would like to achieve in the end. This also allowed us to touch upon topics like accessibility and performance.

If we update things like button styles, this will have to be done globally, and not just for this page, as part of the dependencies of bug 1392389. This will be out of scope for our project though.

Comment 14

[:Paolo Amadini]

(In reply to :Matthias Kammüller from comment #10)
> We updated the Add-A-Pref form to be a modal, which will be triggered by a
> button.

This new design is very unlikely to make its way into product, unless it turns out we'll need subdialogs for many different kinds of in-content pages in the future. This is mainly because our sub-dialog infrastructure for in-content pages is specific to the Preferences window, so it can't be reused anywhere else without a significant amount of work, and reimplementing something specific just for "about:config" would involve too much maintenance compared to the benefit.

In fact, after I reviewed our backlog today, I'm starting to believe that even the original design with an expandable section might be too much engineering cost, as we'll have to write code and tests for various validation scenarios, and it may miss our course deadline. I'll add a proposal for a lower cost minimum viable alternative to bug 1497727.

> The design will be discussed in the next week's design meeting [as far as I
> understood ;-)]

I've kept myself a little bit out of the loop here, which is intentional on my part to allow Matthias and the user experience team to work more closely together. However, I want to clarify that the original request we had was basically a half-an-hour conversation with a designer, and we'd subsequently come back with more questions after the engineering work to implement the design started. Iterative development of user experience can only happen effectively if we have something concrete from engineering to feed back into the loop, otherwise there is the risk of going too far ahead and past the point where refinements to the mockups are worth the time.

It seems that we had some designers assigned to this as a feature, which is great and very much appreciated, but also the effort has to be balanced with the amount of time that we'll spend writing the code, which is very small compared to other features. I'm not sure from the mention above if there are other discussions planned, I just want people to be aware that now we may need to scale back design and ramp up engineering.