This project is archived. Its data is read-only.
Future of UX for settings / configurations
Here's my look on what the endgame for UX should be for **LibreWolf** to continue our goals of being security / privacy concerned by default and opt-in for anything else, while still keep user-friendliness :) My perspective is coming from my wide use-cases for browser: - Privacy concerned casual use - Web-development, which implies i have to sometimes easy and fast reset some things which are breaking css / js / requests etc - I still take perspective of more casual users seriously, there are a lot of common themes by users switching from Firefox or whatever else, which are not clear from the go so far **DISCLAIMER**: I have never inspected Firefox / LibreWolf source before and don't have a lot of time right now, just have some assumptions about what is probably possible... So don't beat me too hard on technical aspects if they are insane, let's think big together and try to make it happen one day one way or another! ____________ There are plenty of ways we can go which was tried before by other browser, like: 1. Extend `about:config` 2. Create custom welcome screen with possible experience-breaking options like **GNU IceCat** I believe it's all good ideas, but both have major flaws, however i got better one! Here's core plan: 1. We need to create separate page in settings, using existing Firefox front-end infrastructure (looks like custom xml + css or [webcomponents](https://briangrinstead.com/blog/firefox-webcomponents/) which fire up .js execution of settings parameters?) `about:preferences#librewolf` 2. This is very important part where we need to decide how exactly to break settings, as first sketch i'd do: - **General** - Plugins auto-update - Password save - **Content**: - WebGL - DRM - **CSS** - List of **ALL** even slightly possible CSS breaking default settings - **JavaScript** - List of **ALL** even slightly possible JavaScript breaking default settings 3. This page consists of two types of components / elements 1. **Category** component - Checkbox which is master switch for ALL child entries for category - Name - Description EXTREMELY short and on point one, only if it's **absolutely** necessary (for example **General** category - you'll get why later) - Restore defaults (should appear only if defaults were changed to work like indicator) 2. **Settings item** - Checkbox - Name - Description which should include: 1. Description itself, clear and nice human readable 2. Perhaps list all config options which would be triggered (but that may be overkill) _________ By default descriptions should be hidden, there are variants of how we can technically do that: - Collapse aka "More information" arrow from Firefox browser privacy component (Standard / Strict / Custom) - Learn more (hyperlink to LibreWolf docs with appropriate anchor #id) the only downside is that you won't see description when offline - Initially i though about just nice and lean ? icon inside circle, when pressing it would open a dialog window, but there are no such premade element in Firefox settings it seems - Restore defaults (should appear only if defaults were changed to work like indicator) 4. Behavior of **Settings item** behind the scene, let's for example look at **Content** -> **DRM**: 1. When you enable **DRM** it should effectively enable ALL related settings at once (15 at the moment) 2. There should be alert that it can't be enabled at all until **General** - **Plugins auto updates** won't be enabled, alert style is something like Privacy - Custom of Firefox: ![image](/uploads/7379441c37463769ec66b3c5b9cd052c/image.png) 3. That is probably most important point, i believe that **ALL** settings on `about:preferences#librewolf` page for **Category** and **Settings item** components should have it's single dedicated entry in `about:config`, like: `defaultPref("librewolf.content.enabled", false);` `defaultPref("librewolf.content.drm.enabled", false);`<br> So, for example switching `drm.enabled` would auto-trigger those actual 15 settings at once if enabled via settings or `user.js`<br> So it would be super-easy to change such umbrella privacy / experience breaking setting only in one place, regardless of what **LibeWolf** and especially **Firefox** future changes could be!<br> Also this solves very easy configuration in `user.js` from the actual user perspective. 5. I believe that we need to have database of settings in one place, generated from something like JSON (hence i support [this initiative](https://gitlab.com/librewolf-community/settings/-/issues/16)) by script while build and populated to all other places: - Settings is `about:preferences#librewolf` - `about:config` - `librewolf.cfg` / `policies.json` - Website docs and database entry would be something like: - category - action(s) / variable(s) **key** and **value** - description (if any) - default value - For website docs: All actual Firefox options that will be triggered / affected / changed __________ # Philosophy https://gitlab.com/librewolf-community/settings/-/issues/27#note_609620903 __________ # Layout - Bird's eye view https://gitlab.com/librewolf-community/settings/-/issues/27#note_606958904 __________ # Layout - Full description https://gitlab.com/librewolf-community/settings/-/issues/27#note_620771041 __________ # Description dialog example (ideal, but hard to do) https://gitlab.com/librewolf-community/settings/-/issues/27#note_616145117 __________ # Future for tabs containers (forget for current work!) By now your head maybe exploded already, hold to your chair now... 6. Here's most powerful feature if implemented along with all what had been said before will be game-changer! Check layout at plan's **2 point**, imagine that right after **General** category and it's items, and between the other **Categories** there is a **Containers tabs** dropdown: - by default Should have value of **Global** and write dedicated `librewolf.` settings to `prefs.js` and read from `user.js` if there is one - Other values of dropdown are mirror of current **Container tabs** for example **Work** and would write it's dedicated tab settings to `prefs_work.js` and read from `user_work.js` if there is one - As you could guess, if you choose **Work** in such dropdown - it will show current values of all **Categories** below, which are effectively overrides on top of dropdown **Global** settings values for each of your container scenario - If user deletes some **Container tab** `prefs_work.js` and `user_work.js` files should be deleted (well maybe not user, i'd personally probably do that, but maybe it's not nice, whatever we choose) This is super powerful, just imagine that you want to use extra-powerfull privacy for your browser, but for work you want to have isolated tabs with let's say...Figma, codepen with enabled WebGL or disabled a lot of privacy settings related to css / js to unbreak stuff, so you can actually use Figma without spilling profiling to other tabs!!! :scream: P.S. Even if all the stuff before **Container tab** last step will be implemented - it's already huge step forward!
issue