Redesign settings page & Add doc links

[florian-h05]

Closes #1935.

• Moves transformations to a new list for visual separaration, as it is only second class configuration.
• Renames System Services to System Settings.
• Add Add-on Settings, which opens the same settings page as the add-on store, i.e. provides log, service config and persistence config (if persistence service). Add-ons that only provide log settings are considered advanced and hidden by default.
• Consolidate the add-on store and the newly added add-on settings into a single place (refactoring included).
• Add doc links to Things, Items, pages, rules, scenes & scripts list pages.
• Make some system settings advanced.
• Use a third column for large screens.

[florian-h05]

[relativeci]

Job #1119: Bundle Size — 15.76MiB (~+0.01%).

2340ba3(current) vs 1976fd0 main#1118(baseline)

⚠️ Bundle contains 16 duplicate packages

Metrics (2 changes)

	Current Job #1119	Baseline Job #1118
Initial JS	1.67MiB(+0.02%)	1.67MiB
Initial CSS	608.89KiB	608.89KiB
Cache Invalidation	93.95%	93.94%
Chunks	219	219
Assets	689	689
Modules	1700	1700
Duplicate Modules	90	90
Duplicate Code	1.95%	1.95%
Packages	138	138
Duplicate Packages	15	15

Total size by type (2 changes)

	Current Job #1119	Baseline Job #1118
CSS	859.49KiB	859.49KiB
Fonts	526.1KiB	526.1KiB
HTML	1.23KiB	1.23KiB
IMG	140.74KiB	140.74KiB
JS	9.25MiB (~+0.01%)	9.25MiB
Media	295.6KiB	295.6KiB
Other	4.73MiB (~+0.01%)	4.73MiB

---

View job #1119 report View main branch activity

[florian-h05]

@ghys Please let me know what you think.

[ghys]

Many thanks @florian-h05 for giving this a shot! It's pretty much what I imagined. I very much like the reintroduction of direct links to the add-on settings which makes more sense from a UX perspective than having to find them again in the add-on store and then finding and clicking on that little gears icon. Seeing that screenshot lead to more thoughts and ideas:

• the 2-tier configuration section is great, but maybe it's premature when the only entry in the 2nd part is "Transformations" which is therefore kind of lonely in there atm - not necessarily a huge problem though
• about this "Transformations" entries, the icon I chose for these in the add-on store and its predecessor was function from the f7 icons (the "f(x)" one) which is maybe more representative than the one here? Also the description - "Manage transformations" - is a bit dull and could use some more creativity with a short sentence in the same spirit as the ones above it. Not offering suggestions at this stage, just saying.
• There are more and more system settings added over time and also your screenshot only has 4 add-on settings entries, which I'd say would be rather below average. The right column would inevitably grow much taller than the left one which doesn't change much.
• Maybe it's time to introduce a "show advanced" checkbox on this screen as on config sheets and some other places. For instance "Transformations" would be considered advanced and shown only when that box is checked; some system settings would also qualify for sure (at least "JSON Storage", "3rd-party Json add-on service", "Network Settings", and maybe "Charts" would be considered advanced given their current options). Eventually individual add-on settings would be considered advanced if they wouldn't offer any configuration properties nor persistence configuration but only log level settings (probably hard to figure out in a performant way).

I don't think we have to rush this, we can discuss this and schedule it for the next milestone or the one after. I've learned from other experiences that too many big changes in critical parts of an UI as we adjust and make up our minds can lead to confusion and frustration.

[florian-h05]

I had a few thoughts about your comment:

the 2-tier configuration section is great, but maybe it's premature when the only entry in the 2nd part is "Transformations" which is therefore kind of lonely in there atm - not necessarily a huge problem though

I understand what you mean, but when openHAB 4.1 is released hopefully transformations aren't that lonely anymore, because we have a page to manage the semantic tags in place.

Regarding transformations:
I like the function icon more, I've updated it together with the description. Not so easy to come up with something short, but still meaningful.

There are more and more system settings added over time and also your screenshot only has 4 add-on settings entries, which I'd say would be rather below average. The right column would inevitably grow much taller than the left one which doesn't change much.

For system settings, it is difficult to decide whether they are advanced or not, and I don't want to hardcode a list - I'd prefer to show them all.
For addons, I found a easy way to determine whether the add-on provides settings, just check the list of installed add-ons against the list of non-system services. (That works by checking if there is any non-system service whose configDescriptionURI's second part (the servcie name) equals the add-on id). If the add-on is a persistence add-on, it also is not considered advanced.

Now looks like this:

Note that I chose to add a list button "Show Advanced" (and also "Hide Advanced") because IMHO this is more intuitive than placing the "Show advanced" checkbox in the upper right corner.

[ghys]

Thanks! I think it looks great, I have a couple little more nitpicks obviously:

• I would replace the "Show Advanced" label for add-ons to "Show All" and actually remove the button to collapse again. "Show Advanced" is not quite right because it could be interpreted as a hierarchy between the add-ons themselves, some being less important than others. It's a pattern you can come across on iOS where you have a filtered list (for instance, recently accessed) and have a way to show it unfiltered if you need, and it will render as collapsed again when the page is recreated anyway. Bonus points if the list is sorted so that when you hit "Show All" the entries are not reordered, but the new ones are just appended to the list.

• I'm not too sure the descriptions added with the last commit are really necessary, especially when the list is empty, you'll have both that and the "empty state placeholder" which will not fit well on a phone screen (I specifically made sure of that) and offer redundant information.

  

  Maybe a button to the documentation could be added to those instead, like here?

  

[ghys]

It's a pattern you can come across on iOS where you have a filtered list (for instance, recently accessed) and have a way to show it unfiltered if you need

Incidentally this is something which should be beneficial in other places, for instance the sessions list in the "profile" page, as illustrated on https://demo.openhab.org/profile/
Here the list takes ages to render when maybe the 20/50/100 most recent sessions could be displayed by default with a "Show All" button to show the rest.

[lsiepel]

ddons, I found a easy way to determine whether the add-on provides settings, just check the list of installed add-ons against the list of non-system services. (That works by checking if there is any non-system service whose configDescriptionURI's second part (the servcie name) equals the add-on id). If the add-on is a persistence add-on, it also is not considered advanced.

The current two column layout is ideal for 1024px, but has some limitations. Hiding visual items behind a 'show all' tab would be great and necessaire for the smaller viewports. Many of us have screens with a much higher resolution.
I would suggest make it more repsonseive by adding a third column (for the addons) for viewports with min 1440px and only show the 'Show all' for the smaller viewports that have two column layout.

A quick copy/paste paint mock:

[ghys]

That's a fair remark, however the settings screen has been carefully designed with a 1280px screen width in mind (kind of the middle point), also considering you can use the developer sidebar at this resolution and above, so it had to fit just right:

Adding columns could be done but the developer sidebar reduces the available width without adjusting the viewport size, so all of this has to be taken into account.

Hiding visual items behind a 'show all' tab would be great and necessaire for the smaller viewports.

This is also influenced by the fact that not all add-ons have settings to configure, some would just be log level settings, that's why they're behind a "show all" filter, as they don't have anything specific to configure.

Also in your mockup I would move the add-on store items to the middle column. This drives me to another completely different idea: we could have a consolidated "add-ons" section presenting the installed add-on settings, then a single "add-on store" link to add more.

[florian-h05]

I would replace the "Show Advanced" label for add-ons to "Show All" and actually remove the button to collapse again. "Show Advanced" is not quite right because it could be interpreted as a hierarchy between the add-ons themselves, some being less important than others.

Agreed, and already commited.

I'm not too sure the descriptions added with the last commit are really necessary, especially when the list is empty, you'll have both that and the "empty state placeholder" which will not fit well on a phone screen (I specifically made sure of that) and offer redundant information.

Good point. I have added documentation buttons to the "empty state placeholders", but I wanted to keep a simple way to open the docs right from the UI, so I extended those "x Items" lines to "x Items - Open documentation".

Regarding the number of columns and ordering, I will have a look once I have the time.

[jimtng]

This drives me to another completely different idea: we could have a consolidated "add-ons" section presenting the installed add-on settings, then a single "add-on store" link to add more.

I love this idea, similar to how browser extensions are managed. It also gives us a place to see all the addons that are currently installed, and that it would load much more quickly.

[florian-h05]

I have consolidated the add-on store and the add-on settings into a single block (even refactored them to their own component), introduced advanced system settings (hard-coded inside the UI) and added a third column for large screens.

On a smaller screen:

On a larger screen (note that I have chosen a good brakepoint to use the developer sidebar the same time):

[florian-h05]

This last design might satisfy everybody's needs/be a good compromise! :) I'll test it ASAP.

FYI, I have just fixed a style issues, that was caused by the use of CSS visbility instead of v-if (took me a while to find the right v-if condition).

Another option, maybe, and it's just me playing with ideas, would be to have the add-on store out of the settings section altogether, and have its own entry in the left menu perhaps between Settings and Developer Tools, like this (only a mockup):

Good idea, I like that and so I implemented it.

[lsiepel]

This last design might satisfy everybody's needs/be a good compromise! :) I'll test it ASAP.

FYI, I have just fixed a style issues, that was caused by the use of CSS visbility instead of v-if (took me a while to find the right v-if condition).

Another option, maybe, and it's just me playing with ideas, would be to have the add-on store out of the settings section altogether, and have its own entry in the left menu perhaps between Settings and Developer Tools, like this (only a mockup):

Good idea, I like that and so I implemented it.

Just a suggestion, maybe ‘copy’ instead of move it. I like both place to ‘enter the store’

[ghys]

I think it looks pretty neat now 😍!

Just a suggestion, maybe ‘copy’ instead of move it. I like both place to ‘enter the store’

Fair point, might be a simple button like "Install More Add-ons" instead of the prominent item in the attempt above, but I actually like this current design and the separation of concerns of sorts. This separation is all more important if, in the future, when some sort of RBAC is implemented and/or OAuth2 scopes are implemented, we might allow certain users access to the settings, but not to the store.

One other technicality would be to move the add-on store pages to simply /addons instead of /settings/addons (as the developer tools are simply under /developer) to further segregate the 3 administration sections. Maybe the 4 tabs of the store (Bindings, Automation, UI, Other) could have sublinks on the left-side bar when the add-on store is the current section, like the other sections do. I do however think we can merge this as it is and eventually work on that later.

Thanks very much @florian-h05!

[ghys]

A minor detail I just noticed too late (it wouldn't have been blocking): in that left side menu the top-level entries' icons (Settings, Developer Tools, About) are "filled" and the sub-levels are "hollow", so in this case the icon should have been e.g. f7:bag_fill instead of f7:bag; again just a minor design quirk but it contributes to the consistency 😎

[florian-h05]

Agreed that it should be changed for visual consistency, so here it is: #2053.

[wborn]

You could also argue that this fixes a bug and it should be backported to 4.0.x. 😉

[florian-h05]

@wborn I have actually also though if this should be backported to 4.0.x, because it greatly improved UX and some users did not find the add-on settings in the store.

@ghys WDYT? I don‘t want to backport my own PR without your approval.

EDIT: Of course we need to fix #2049 before backporting it.

[ghys]

Please do (when it all works), I think you can make these decisions on your own :)