[Discussion] Towards better settings (and per-channel settings)

[astorije]

Lots of issues, PRs, discussions and disagreements have an impact on settings. In this fork alone, I can mention https://github.com/thelounge/lounge/pull/57, https://github.com/thelounge/lounge/pull/70, https://github.com/thelounge/lounge/pull/28, https://github.com/thelounge/lounge/pull/49, https://github.com/thelounge/lounge/issues/80, https://github.com/thelounge/lounge/issues/44, https://github.com/thelounge/lounge/pull/70, ... and we are only 2-week old!

This is only going to get worse as we improve theme management (or create theme management for that matter) and add packages, who will have their own settings, potentially affect existing settings, ...

Before we start adding dozens of settings to the current setting page, we need to discuss the long-term goals.

I have been building a mockup of the settings page slightly revisited. I propose we discuss its style, content, interactions, underlying structure, usability, ... (but the CSS/HTML is gross, this is just a mockup :P) I will update the mockups as the discussion evolves.

One very important aspect is to keep user-friendliness as we evolve, or we will end up being a cluttered application as most IRC clients are. Defaults should be sensitively chosen to enhance the experience of any new user (of The Lounge or IRC altogether). Considering a private instance of The Lounge can be maintained by one administrator and used by many users, it's not crazy to think The Lounge may be used to introduce new folks to the IRC world :-) Also, not everything should be a setting ("Better settings" does not mean "more and more settings" :p). Any UI-specific choice should ideally be the responsibility of a theme author, and may be overridden using custom styling. However, advanced and very advanced users should be able to find happiness here too. When it comes to styling, a custom style field should give them the ability to make changes to a very fine-grained extent. We might want to be able to do the same thing for the settings overall: if all interactive elements for settings (checkbox, inputs, ...) match to an underlying data structure, some settings might be so advanced that they should be edited in a text field directly (like the custom styling, but for settings themselves). This might be an impractical idea after discussion, but focusing on keeping the UI slick and simple is key here.

Also, everything that appears on the settings page, apart from the profile section obviously, is device-specific. Therefore, everything should be stored in the localStorage and not be synced with the server. We could argue that some settings should be synced on the server and some should not, but that would lead to confusing settings and very difficult specificities to handle. I propose we start like this and improve with server sync later. Doing the other way around would prevent users to have different settings on different clients altogether, while this way allows for more freedom.

As packages will arise, they will come with their own settings. Packages should not mess with other packages' settings, so we might want to namespace/prefix them. For example:

general:
  showMode: true
  ...
emoticons:
  enabled: true
  ...

As core features move to separate (but officially supported / part of the GitHub org) packages, they need to fallback to their old name (example: general.notificationsEnabled -> notifications.enabled) to not affect existing users. We need to decide if we want to allow packages to have their settings entries spread across the settings tabs or under a Settings button for each package.

That's all I got for now. It's rather long already, but praise my stupidity for having lost all my notes right before opening this issue! I hope that you'll like my mockups and that we can peacefully discuss to reach consensus :-)

Example

[xPaw]

We need to decide if we want to allow packages to have their settings entries spread across the settings tabs or under a Settings button for each package.

Have a "settings" button next the disable package button, which will open a separate tab for said package's settings.

Also looking at your mockup, I'm not sure if displaying all networks/channels for chan specific settings like you did is a good way of doing it, It's gonna be noisy when you have many channels, but you're duplicating the sidebar.

[astorije]

Have a "settings" button next the disable package button, which will open a separate tab for said package's settings.

Yes, that's one of the options, but the problem of this is that integration between packages and main project is heavily affected. For example, if we manage to split things about notifications into packages, then it will be awkward to use. Offering both could be a solution though: by default, all package settings go into a package settings page as you described, but package author can escalate some settings to the other pages.

Also looking at your mockup, I'm not sure if displaying all networks/channels for chan specific settings like you did is a good way of doing it, It's gonna be noisy when you have many channels, but you're duplicating the sidebar.

Point taken. I'll improve the mockup to take this into account, will ping when done :-)

[MaxLeiter]

Just a note: I think there should be an 'apply' button for the custom CSS; clicking out of the settings menu/page isn't very intuitive.

[MaxLeiter]

Bringing this back a bit - I really think we should have multiple setting pages/tabs in the end; one for UI/visuals (custom CSS, selectors for font size, themes, etc).

Maybe another one for custom keybindings, another for behavior, one for your account, etc. Similar to IRCCloud, I guess. Eventually, plugins could add their own tabs

[AlMcKinlay]

Alright, I think I want to bring this back up, as we are definitely getting to the point where our settings page is getting too big to just be 1 page.

Regarding how we structure the settings page, I think the mockup embedded in the issue (the dropbox link is dead, is it the same as the embedded image) is a good starting point. I'm not sure how I feel about having the General being a heading that has multiple within it that is collapsed by default, I think it might be better to have it expanded by default. But other than that I quite like it.

Now with the agreement that we will plan to have an "advanced" section, we have to think about how we want to do that. I think we can all agree that there are some settings that should be advanced settings (for example, #1176 and possibly custom css) and more that will come in the future, how do we want to hide them? I can think of 2 options:

1. Having an "advanced" tab at the side

This would not be the one I would choose, because it removes the nice structure that @astorije has already brought up for structuring the settings, and it either bundles all the advanced settings together (which may have nothing to do with each other) in 1 tab, or it means we have the same structure in another advanced expander, which just feels like far too much.

2. Having an "advanced" toggle

This would work kind-of in the style of VLC (but not quite), in that you have a view that is the normal settings, and when you toggle advanced, more setting become visible, but the structure stays the same. So for example, the "Themes" tab by default just has the Theme selector, but when you toggle advanced, the custom css and the username colours toggle become visible.

I would prefer this, as it keeps the structure of the settings, so that you don't have to context switch and figure out whether this would be considered an advanced setting, so is in the advanced tab, or would be a normal one, so would be in one of the normal tabs.

[AlMcKinlay]

On a similar point, there is also the subject to discuss of server settings.

We have discussed syncing the settings across clients, but it would also be good if we can figure out a way to have server settings on the client as well. An example is the prefetch. If prefetch is disabled, we can't enable the auto-expansion on the client without editing the server settings (and restarting). This feels less than ideal.

I understand that this does require some thoughts around who is able to edit these settings, which complicates it (off the top of my head, setting users as admin or users could work) but that's definitely overcomable.

[astorije]

All this sounds very reasonable. I very much prefer option 2 as well. Also, I believe General was not collapsed by default, but it does when going to another tab. Not sure anymore, that was so long ago (also it was a dumb HTML mockup, no js involved).

Let me revive the mock-up when I'm on laptop. About to board a couple planes right now, can't make any promises before tonight or so.

[AlMcKinlay]

That's cool, no rush, @astorije, but yeah if it's collapsed when you are in another tab, that sounds like a reasonable suggestion. We can certainly have a play around with different ideas.

[AlMcKinlay]

@astorije You got that mock-up anywhere? I'd quite like to get this done in advance of doing too much plugin work (because adding plugin settings will make this really messy without it).

[astorije]

Damn, I could swear I posted this, sorry! See it at: https://fishmonger-christopher-73101.netlify.com/

Note that it's a really gross, way outdated, not optimal (at all) "interactive" mockup and definitely not what I envision right now, i.e. 1.5 year after making them (damn!) 😅.

I am happy to make a temporary repo or whatever so we can build mockups together before jumping on implementation. Whaddaya think?

[AlMcKinlay]

It's not ideal, obviously, but I think it's the sort of thing I was thinking of. I'm so bad at mocking things up, it's probably easiest for me to just do it if I was planning on doing it, and seeing what people think. I'm ok with people saying "No, that's not what we want at all.".

[astorije]

@YaManicKill, I'd be glad to help on the mockup if you want.

That channel chooser sucks, it doesn't scale at all. I had another idea, much nicer, but never found time to mock it. I'll try to see if I can do that over the weekend, but I'll prioritize push notifications first or @xPaw will kill me :D

[testman42]

Thank you for prioritizing notifications. Is there maybe any progress regarding that?

[AlMcKinlay]

Thank you for prioritizing notifications. Is there maybe any progress regarding that?

@testman42 Do you mean push notifications? That was merged a while ago in #1124 and released in 2.5.0. It currently doesn't work on iOS, but works really well on most other operating systems/browsers.

[testman42]

@McInkay I noticed that, and I have them enabled.

I am actually more interested in the progress regarding #912. But since it was for some reason marked as duplicate of this issue, then I assume I should inquire here.

[AlMcKinlay]

Alright, that wasn't clear.

But generally, unless someone mentions it, it isn't being worked on. We'll hopefully get to channel/network settings sometime, but it's not the highest priority. We are always open to PRs if people want to write the code themselves.

It might be easier once #2636 is done as well, although we still need to sort out the server-side part of settings before that.

[igalic]

Per channel highlights

Feature Description

I'm in a number of tech related channels, in some of those, i would like to follow a specific subject. However, while adding freebsd as a global highlight would enable me to follow new developments i'm interested in in #cloud-init, it would make #bsdports unusable.

I would like to be able to set per-channel highlights.

[CronLad]

Curious if any of this is still being considered/worked on? My interest here lies in per-server/channel highlight settings instead of having to use a global highlight words or phrases across all servers.

[StayPirate]

Is there any updates? It would be nice to have per-channel notification settings.

[malwinmp]

Any updates on notifications overhaul? It needs more customization badly.