Common Settings Page Layout

[lansingthomas]

Purpose of request:
Luka has been working on updating the common settings page -- this is a draft layout we developed together last week to put his work all together.

The purpose of the layout is to look consistent and professional... and just be better :)

I am aware of a few other open issues related to this:
#2351
#2296

We have been looking at those, and though this post is mostly for Luka -- @aadcg @jmercouris @aartaka, if you have ideas about the common settings page -- speak up.

Describe your proposed change:

1. section organization
2. a descriptive column on the right side to guide users as they select settings
3. some re-writes & edits to existing descriptive text
4. a layout pattern for the whole page
5. radios and checkboxes for some common settings

Why do you believe this to be an improvement?
We will be adding more things to this page as time goes on. So today we are creating some places for those new things to exist, and clarifying /fixing what already exists on the page.

Additional context/User story:
Luka and I talked about 4 other sections for this page: Privacy/Security Settings, Text/Code Editing Settings, System Settings, Search Settings

These sections are a bit more involved so let's not worry about them (yet... but soon we will).

Screenshots/Mock ups:

common settings light theme layout

common settings dark theme layout

common settings spacing guide

common settings color guide

NOTE: issue #3134 (recently assigned to @aartaka ) involves creating similar checkboxes. Let's try to make them match.
: D

---

Thanks Luka!

Pre-Build Checklist:

• Discussion has occurred.
• One or more developers have signed off on this change.
• One or more user researchers have signed off on this change.

[aadcg]

All good with respect of aesthetics.

One very important technical requirement is that users needs to understand how a certain parameter is set. For instance, if the user sets the keyscheme to vi, then it needs to be visible from common-settings. In other words, the state of auto-config.lisp must propagate to common-settings.

[hgluka]

Yes, we've been thinking of a good way to show the "current state" of a setting.
Is your idea to show the relevant part of the auto-config file in common-settings? I haven't considered that, but it could be a good solution.
Otherwise, we could show the current value (which is kind of obvious for browser slots, less so for buffer slots). The only catch is that it will require a restart to update the value, until #3120 is finished.

[aadcg]

Well, I think that common-settings won't be doing its job properly if you can't see the state of the config it covers. If you have a "button" that sets a parameter, you need to have a reliable indicator as well.

[aartaka]

An alternative simpler solution would be to make it all a form and add a "Save" button in the end. This way, we allow one to change their mind when configuring Nyxt and only save/apply the final state of the config, instead of adding lots of intermediate ones.

[hgluka]

@aadcg I agree. The radio buttons and checkboxes are pretty good indicators on their own. We just need something like that for the other settings as well. We already put that in the spec for default-modes, but the other buttons need it as well.

@aartaka's suggestion is interesting. I'm not sure if it's a direct solution for the issue, but it might help. Still, some settings lend themselves very well to a prompt-buffer with an appropriate source. Set new buffer URL can be similar to set-url and Set default modes can be similar to toggle-modes, for example. As long as we don't lose that, I'm all for using forms. It would be good to avoid writing to file each time the user clicks a radio button.

[aadcg]

Re-iterating for the sake of clarity: if a parameter's default is tomato and the user as sets it to potato, then the next time they go to common-setting they need a UI indication that it's set to potato. In short, a graphical config facility needs to both set and get parameters. An indication of the default value would be a plus too.

[lansingthomas]

One very important technical requirement is that users needs to understand how a certain parameter is set. For instance, if the user sets the keyscheme to vi, then it needs to be visible from common-settings. In other words, the state of auto-config.lisp must propagate to common-settings.

@aadcg
I totally agree with this requirement, I think we all do. -- my thinking is that the Radio / Checkbox satisfies it nicely for the first few sections.

Then we have a feild to show active modes for the New Buffer Settings section

[lansingthomas]

Plaintext for copypasta:

Note that some settings may require restarting Nyxt to take effect.

The default keybinding scheme is always present, and CUA bindings will be familiar to many users.

For individual buffers - keyschemes can be toggled with the (toggle-modes) command.

For a persistent keyscheme each time you start Nyxt - make a selection here.

Themes for the browser interface, panel buffers, and internal Nyxt pages like manual, bindings, and common settings.

Select Default Web to view webpages as they are designed.

Select Darkened Web to have Nyxt darken arbitrary webpages you visit, by default.

To darken an individual webpage, use the command (dark-mode).

Incremental changes advised.

Choose your homepage. By default your homepage is set to the internal Nyxt page (nyxt:new)

Choose your starting point when launching Nyxt.

Specify default modes for all new buffers.

This list shows modes for all new buffers. To set modes for individual buffers, use the (toggle-modes) command, or a specific command like (toggle-no-script-mode).

[lansingthomas]

Let's avoid the Save Settings button if we possibly can.

IF we must do it, we can do it by section, with color changes to show states;

like this draft -

---

[lansingthomas]

#3178 might help some of our problems here.

[hgluka]

@lansingthomas How do we feel about being able to collapse/expand each section? We talked about doing that for some specific settings, but maybe it would work well for the whole page? We can use :nsection, like we do in the manual or tutorial.

It would look like this:

[lansingthomas]

[lansingthomas]

Yeeeeeeeeeeah, I think this layout is better than the previous (above).

1. compartmentalizes the sections (easier decision making for users)
2. rhymes with settings pages from many other applications (consistent with expectations)
3. accommodates more settings later on (as complexity increases)

side tabs:

---

what do you all think?

@aartaka

• Design 1 - one long page to paginate
• Design 2 - side tabs
• I don't care just pick something.

@hgluka

• Design 1 - one long page to paginate
• Design 2 - side tabs
• I don't care just pick something.

@aadcg

• Design 1 - one long page to paginate
• Design 2 - side tabs
• I don't care just pick something.

@jmercouris

• Design 1 - one long page to paginate
• Design 2 - side tabs
• I don't care just pick something.

[lansingthomas]

How do we feel about being able to collapse/expand each section? We talked about doing that for some specific settings, but maybe it would work well for the whole page?

Luka and I spoke on video today, but I will post here in the spirit of transparency.

We decided NOT to do :nsection dropdowns -- it sort of hides things on a page where we want users to have a sense of complete understanding (like they can see ALL options). We also talked about how our dropdowns currently are not very good at communicating state. The triangles look pretty similar open and closed.

[lansingthomas]

colors for design 2

[aadcg]

@hgluka I think the easiest way to implement it would be to call headings-panel when common-settings is invoked. I think it's ok to list all settings in one page instead of showing the content of one heading and hiding the content of all others.

[aartaka]

Weaving into the headings-panel/side tags discussion: we kind of expose the heading search functionality in the manual, so why not expose it in settings too? That'll remove the need for table of contents or side tabs, and make all the interface closer to other ones (as @hgluka said).

---

Slightly off-topic: maybe we should make a status buffer button for headings panel/command? It's too useful to be unseen.

[aartaka]

Regarding the implementation (in part responding to @aadcg): I still dislike the intrusive single-letter bindings in the manual and the idea of forcing the panels seems too much to me, but still, I agree with the idea of making Nyxt productivity tools exposed and useful. So I'm on the side of re-using what we already have. That'll also simplify the layout.

[lansingthomas]

https://www.w3schools.com/howto/howto_js_vertical_tabs.asp

[aadcg]

@lansingthomas the question is not how to do it, but rather how to integrate it with existing facilities and practices. Let's focus on getting a prototype as soon as possible, and avoid getting distracted with minor issues that we can addressed later.

[hgluka]

I'm still leaning towards side-tabs of some kind. There's value in showing the user only one, relevant section.
We even have an open issue for paginating the manual in a similar way: #1541. The side-tab layout here would probably be simpler than a full-blown info-mode equivalent, but the philosophy is the same.

As far as the implementation goes, the headings panel was also my first idea, but it might be too cumbersome for this use case. It stays open even when you switch the main buffer, it shows all headings regardless of level, etc.

[jmercouris]

Yes, you'd have to modify the headings panel architecture to allow for "sticky" panels that are associated with buffers. This is outside of the scope.

Just program it all in HTML only. Do the side tabs design that Thomas has proposed.

[lansingthomas]

Update: Luka and Tom met today -- here are the actionable items.

@hgluka

• programmatically insert the f1-s documentation for the description column. For sections: {theme, dark mode, default zoom, default URL, restore-session}
• build the edit-user-files button
• add a checkbox item: default cookie policy slot | (in security section)
• build the side panel UI

@lansingthomas

• enlist some poor soul to review and re-write the f1-s documentation for {theme, dark mode, default zoom, default URL, restore-session}

[lansingthomas]

We also decided to allow special descriptions (written for the common settings page specifically, very human readable) for the other headings/subheadings:

1. Keybindings
2. modes
3. blocker mode
4. no script mode
5. reduce tracking modes