Configuration based UI / UI customization

[mitchcapper]

Why write 1 word when 10,000 will do.

I think many products that serve many masters run into the problem of conflicting preferences especially around the UI. In addition, as mentioned in #87, new features added have the expectation of being maintained forever. Something too technically complex that is free initially isn't free in the long run. Finally, another problem new features cause is additional UI clutter (or discoverability).

There are different ways to handle this, some projects allow plugins, some add theming, but personally I am a bigger fan of config based UI. The downsides of plugin/theming for UI is the forever requirement for maintaining the plugin/theme API/formats or risk breaking existing plugins/ui where the author does not update. This can be true of any plugin based system, but given how much UI's can change and have different needs having a stable API can be tricky. Configuration based UI tweaking is less flexible in terms of true theme elements but when the biggest goal is just changing the pertinent functions/visible data it can easily rain supreme.

Benefits

Aside from the items mentioned above a settings UI could give users more control like:
- Rather than showing 18 different languages/formats the user can pick the ones they use to show up on the copy request as
- Control headers sort order (if at all)
- Visible columns in the view pane (a fun option could extend include/exclude headers for another option of having a header as a column rather than just pinned/not)
- Should formatting for html/xml/js occur? (Automatically / No / On Button)
- Truncation length for header values/bodys/etc.
- Multi-select for the view pane: Show Checkboxes, With control or shift hot key only, with a column checkbox to show checkboxes, disabled (current behavior)
- Features that could be completely turned on and off like the ability Include/Exclude specific headers, Mock support, automatic previewing, header documentation, context menus. Some of these are obviously already enabled and visible, but this would allow users who don't need them to reduce clutter.
- Horizontal rather than vertical split for View pane
- Order of cards displayed on the view page, I might want to have response opened but if I may want to see the response body so I can see that without scrolling when there are large numbers of headers

It can also serve to better denote certain features. Is this an experimental feature that might be removed? Is this an advanced feature most users likely don't want to be changing/using? These things can be documented in the release notes but plenty of people may not read those verse if it is documented at the setting itself.

It can also allow for off-by-default behavior where many new features are not enabled without turning that setting on. This can further help to reduce clutter at the cost of discoverability (most products can get around that by offering first launch experiences for new releases mentioning new major features that the user can then choose to enable if so desired).

Implementation based considerations

I think JSON/YAML can often serve as a good backend configuration store (and I would assume what the current settings may be stored in anyway with the cloud syncing). In terms of the ui this would involve a few things:
*) Expanding settings for all users, right now settings only show up for Pro. All users don't need cloud syncing but local data store would be a requirement.
*) Surface some options in the UI. This is talked about below.
*) Have an option to store settings through the local server rather than the browser. This is probably more controversial but it takes two seconds to edit a json/yaml file on disk or replace it (or launch using a different config). Doing so in browser isn't a huge deal (and is more in line with current behavior) a simple editor can be added to avoid the user having to always export the config, edit it, and re-import it (ie https://github.com/WebCoder49/code-input ). Given we already do some syntax highlighting likely code-input can work off that and its pretty compact (over adding a true code editor like vscode), here is an example for a plugin that also allows editing settings directly:

*) Support multiple settings, one user may use httptoolkit in very different ways depending on the task at hand, allowing the user to easily switch which settings are loaded is a plus
*) Support Adding or overriding select settings. The easiest way would be when importing settings to simply update the current settings with the values in the new settings file. If the user edits a config export to only have 4 settings in it, only those 4 would be overwritten. This would require a "defaults" option to be able to easily start with a clean slate. This would also allow segments of settings (say mocks) to be more easily shared. For array based options appending to the existing arrays rather than replacing outright this would allow easily importing multiple sets of rules if so desired without removing the current ones for example.
*) I would recommend storing all setting ID's in an enum to make it less error prone (and easier for finding references) when backend code is referencing the same setting in multiple places

UI Option Surfacing

I doubt users have much issue editing json/yaml to turn an option on or off but for more common/permanent options exposing a UI for them can speed things up and make it easier for users to test things out. While many settings could be defined. One can manually write and tie each UI option up (how it is largely done right now). The other option is to make the UI more generated. For any UI option you likely have a few things:
*) Display name
*) Option ID (likely similar to name but static, allows updating the UI without changing all backend references), this would be how any code would get the value of a UI option
*) Type: button, checkbox, textbox, file picker, number, combobox, list, etc
*) Description, optional
*) Category (Themes, API Settings, Connection Settings, etc)

I would recommend another option:
Display Style this would be something like:

• default (shows up like normal)
• Experimental (only shows up of the user enabled experimental options, aka features that may be cut at a later date or change dramatically)
• Advanced ( these are features here to stay but that mostly power users would need to tweak so to keep the settings UI less cluttered would require checking the advanced display box to show them)
• Hidden - does not show in the UI at all can only be edited from config, this can also apply to settings only edited through the primary area they are used. An example may be the columns shown, rather than some complex ordered list box in settings it could be done using a "..." menu in the main view pane (with potentially the option to drag column names left/right to re-order). Still gets saved to the same settings location but no UI in the main settings. This would also work for things like include/exclude headers like in Feat header include exclude context menu httptoolkit-ui#87 where point of use is a far better configuration point than a settings page.

The advantage of generated UI is new options have less overhead to surface to the user, the ability to change the settings layout / display en-mass is easier as it is mostly generated, and it separates the display logic from the values themselves. Downsides include the work of writing the initial UI generator (unless there is a 3rd party lib to use?) and the fact customization of a specific setting or set of settings may be hard. There are ways around the latter but still harder than just arranging static html to look exactly how one likes. This choice doesn't need to be made currently, for now all new settings could be purely at the json/yaml level with no UI and would likely please plenty of people.

---

Does this affect you too? Click below and add a 👍 to vote for this and help decide where HTTP Toolkit goes next, or go vote on the other most popular ideas so far.