Revise Settings dialog according to new UX design

[tjcouch-sil]

User Story As a user, I want a more organized and intuitive settings interface, so that I can easily navigate, find, and manage settings for different extensions and projects.

Description

• [ ] Implement sidebar hierarchy - extension dropdown with each of that extension's settings groups under its dropdown
• [ ] Put all of the settings in one dialog (just UI side of this work)
• [ ] Add support for receiving a project id and only showing settings for that project id (see s/r webview, delivers different UI based on a boolean)
• [ ] Put all of one extension's setting groups on the same page in cards. Clicking a setting group in the sidebar would scroll to that group
• [ ] Use Switch instead of Checkbox
• Many other small adjustments and tweaks

Implementation idea See the S/R web view for an example of delivering different UI based on a boolean, we could do something similar for receiving a project id and only showing settings for that project id.

See the links below for UX design doc and mockup:

Platform Settings – FigJam

Combined Settings – v0 by Vercel

[tjcouch-sil]

Fill this issue out (or make multiple) when UX gives us their design to implement for epic 13

[tjcouch-sil]

Some notes from the UX presentation:

• Command to open settings needs to be able to accept argument for specific setting to show. Argument for focus mode
  • Do we need to be able to focus setting groups?
  • UX undecided: only one settings dialog, add back/forward buttons
• Extension dev adds buttons to web view toolbar - probably separate issue as not super closely related to settings. Probably fits more in the tab nav epic
• Potentially add way to show one setting component in a modal in app toolbar (dark mode combobox)
  • Sounds like UX hasn't quite decided on this either, so maybe wait on implementing. UX can probably let us know what they think
• Focus mode in settings dialog

[Sebastian-ubs]

We just had sprint meeting and managed to clarify on the following:

• ux is not thinking about which settings to implement first, as dev will be doing this already*
• ux will think about the overall settings hierarchy again (which entries should appear there in which order) + other small adjustments: https://github.com/paranext/ux/issues/152
• ux will timebox a design for settings search or filtering: https://github.com/paranext/ux/issues/149
• ux may continue to think about a user settings menu on the toolbar or postpone it: https://github.com/paranext/ux/issues/109
• tab nav content and tab nav menu are out of scope for this and part of https://github.com/paranext/roadmap/issues/15
• "focus mode" is not a priority
• command menu (global search) is not a priority
• showing one setting in a modal is not a priority
• designing components for specific settings is not a priority
• matching pt9 settings with potential new names is not a priority

*ux wants to be included into how to name these settings

[tjcouch-sil]

Issues to write (@jolierabideau will write them up. Thanks!):

• Revise Settings dialog according to new UX design
  • Implement sidebar hierarchy - extension dropdown with each of that extension's setting groups under its dropdown
  • Put all the project settings in with the settings and make it all one dialog
    • Add support for receiving a project id and only showing settings for that project id
  • Put all of one extension's setting groups on the same page in cards. Clicking a setting group in the sidebar would scroll to that group
  • Use Switch instead of checkbox for booleans
  • Many other smaller adjustments and tweaks
• Add Language dropdown to settings
  • Investigate possible language dropdown someone in SIL has already made
  • Make sure you can select multiple languages and type your own language code in
  • Shadcn combobox is probably a good start if SIL doesn't have a fitting one
  • Add this component to the settings as a special case for the specific settings that handle language? Look at the data type and use this if the setting default value is an array of strings that includes the string 'en'...?
• Add ability to specify a specific setting when opening settings dialog
  • Add parameter to open settings dialog and open project settings dialog commands that is a setting key. When the settings dialog opens, navigate to that key.
• Sync user settings so a user's settings follow them around between computers
  • Create a settings server for storing settings or use the Paratext Registry's existing means
    • There are concerns this may strain the Paratext Registry. How should we go about investigating such concerns and making this decison?
  • Add something to the settings schema to indicate whether the setting should be synced

Defer

• Organizing existing settings - core and UX probably need to talk about what we want extensions to be able to do as the design seems to include organizational capabilities that are not possible right now such as mingling settings between extensions. This has not been settled and will need to wait til another time
• Particular new settings and special components for settings - particular settings can hopefully wait til we implement them, and components probably should wait til extensions can provide components to edit settings
• Settings search - not settled
• Toolbar quick-access settings - not settled/priority
• Focus mode - not priority
• Command palette - not settings / not priority
• Web view tab nav buttons from extensions - not settings / not priority

UX team, please let us know when these not settled things are settled. We can work out where to put them.

Regarding priorities, would you like to create new issues and put them on future epics where they are appropriate priorities? Or want to wait until you have finished designs to figure out what you want to do?

Important links:

Platform Settings – FigJam

Combined Settings – v0 by Vercel

[Sebastian-ubs]

Thanks TJ.

I have a question regarding:

mingling settings between extensions

I've not seen or intended this. Can you give an example? Imho there are only separate pages like "my crazy extension", "custom toolbar buttons extension" and under project maybe things like "project plan", "checks configuration", "Emoji Reactions".

The only mingling I could think of is we have not thought through if extensions should be able to add sections to "display" and "behavior" or only below those. Maybe "scroll with other apps" is something that would come from an extension?? Also we have not been clear about where bcv settings would end up. Or is "highlight current verse" an extension setting of the bundled editor extension and so needs to go elsewhere?

What is missing in the current design (only in case we want to make those configurable) is

• a central place for keyboard shortcuts that includes extensions

  For the small adjustments, search and toolbar we will let you know as soon as possible (probably in this order).

---

Yes for the "not a priority" things we should create tasks (where not yet done) and move them to a new or existing settings epic. let's decide this in the next roadmap meeting.

[tjcouch-sil]

@Sebastian-ubs Essentially there are three levels of hierarchy possible right now:

1. Extension/Core Name
2. Extension/Core Setting Group
3. Extension/Core Setting

Anything under one of these items in the hierarchy must necessarily be owned by the same extension/core. So core and extension settings cannot intermingle in any way; they are all completely separated from one another.

The same goes for project settings.

Regarding normal settings, there are some somewhat reasonable equivalents in the v0 preview. You can kinda think of it as the following:

1. Extension/Core Name: "General"
2. Extension/Core Setting Group: Display (behavior, internet, my crazy extension, and custom toolbar buttons extension are all also setting groups of this same "general" extension/core name, but I'm not going to focus on them in item 3)
3. Extension/Core Setting: Interface Language, Theme, Scroll with other apps, Highlight current verse

The problem is that "General" has stuff in it that looks like it would be contributed by core and by extensions. If "General" is the label we put for Core Name, then every setting group and setting under it must be contributed by core and not by an extension. So then you could have another top-level hierarchical item called "My crazy extension" that would have a setting group in it that would have settings in it.

Project settings are a bit trickier. It looks like you also have three levels of hierarchy in project settings, but you display them differently:

1. Extension/Core Name: "Project Properties" (other examples are "Project Plan", "User permissions")
2. Extension/Core Setting Group: General (Books, Associations, Notes, Advanced are the others, but I won't focus on them in item 3)
3. Extension/Core Setting: Full Name, Short Name, Copyright, Language, Versification, Type of Project, Based on, Registration

These levels show up differently. All the item 2s for each item 1 are shown all at the same time on the same page. But the item 2s are not shown in the sidebar.

I used my best interpretive skills here and decided to write the UI revision instructions as basically the following for now:

1. Show extension/core names in sidebar and at top of the page (only show one extension/core in the page at a time)
2. Show extension/core setting groups in sidebar under the appropriate extension/core names and show them all in the page. When you click a setting group in the sidebar, scroll to that group in the page
3. Show all extension/core settings for each group in a card in that group

We can discuss and adjust the display of this hierarchical structure as desired. Larger organizational changes will take more planning and adjustment.

[merchako]

Having not talked to @Sebastian-ubs and @allisonparkk , I believe Checkbox vs Switch isn't an intentional design detail at this point. It's just what v0's AI came up with.

[Sebastian-ubs]

Hi @tjcouch-sil, as we are working on smaller style adjustments, the current (in progress) version is this: https://b_lyq3fteaicn.v0.build/ Maybe that helps with a clearer understanding. IMHO "General" is NOT supposed to be a name, but the place where all not-project-related settings will end up in.

I have added a drawing with questions to the FigJam. Feel free to comment here or there

The content is not final: wording of names, groups and settings and where to put which in is not yet decided. Alignment of setting labels (on top or right aligned in front of the setting) in the v0 is not final.

[Sebastian-ubs]

[Sebastian-ubs]

by the way: did you know you could install the v0 directly into a project (ideally into platform-bible-react)? After clicking the "v0" button, there is a "Add to codebase" button. Of course this code needs to be adapted (split into components, data moved out), but can save some time.

You might however want to wait until we finished

• https://github.com/paranext/ux/issues/152 and maybe even
• https://github.com/paranext/ux/issues/149

[Sebastian-ubs]

TJs reply (in my words):

Settings of core and each extension are put into a single container “name” each and merged together into one flat array.

This name only virtually exists as a back reference to the extension that added a settings group. 

Currently a group has no unique identifier, there can be similarly named groups in each extension / core. 

TODO: Decide as ux if we can use this or if the data structure has to change.

https://www.figma.com/board/WnpfPfYdiTX9GvLBX8YbTb/Platform-Settings?node-id=393-1647&t=BAco3Z5w3WKzbd2L-4