Consistent settings screens

[turt2live]

Several issues reference different problems with the current state of affairs in relation to settings. Some screens are instant, some require a button press, and some look completely different from the others. The relevant issues are:

• We should consider using toggles instead of checkboxes to represent direct manipulation of boolean settings #5392
• Group avatar not saving immediately is inconsistent #5234
• Add obvious save button for renaming devices #5012
• Featuring rooms/users is not discoverable #5208
• tabbed settings interface #3243
• and others my github-foo isn't finding at the moment

I've mocked up a quick (and very dirty) interface for user settings here: https://jsfiddle.net/turt2live/tL3fsw47/11/

It's intended to be a full-page layout, where the sidebar shown takes the place of the room list, and the right sidebar is hidden while in settings. The mockup isn't complete, but should give a general idea of what is going on; if it doesn't, please let me know and I'll work on a better mockup.

Room settings would follow a similar layout. I'd imagine the categories would look something like this:

• Details
  • Avatar
  • Name
  • Topic
• Features (this needs a better name)
  • Default color
  • Groups
  • URL previews for room members
• Security
  • Who can join
  • History settings
  • Power levels
  • e2e checkbox
• Aliases
  • Local and remote aliases
  • List in directory
• Members
  • Some kind of filterable table thing that shows banned, invited, joined, and kicked members.
• Your Settings
  • Don't send to unverified devices
  • URL previews
  • Room color
  • Tag
• About
  • Room ID
  • Creator
  • Room version (if/when that lands)

Group settings would also follow this layout, but in a slightly different manner. The communities icon could bring you to a similar looking page where the communities you're in are on the left and the homepage is on the right (members on the far right). When you click edit, you'd be brought to a settings page where the far right side disappears and the left sidebar has the first item being a back button and the categories listed below it. The categories could be:

• Details
  • Avatar
  • Name
  • Short description
  • Long description
• Rooms
• Users
  • Same filterable table thing from room settings
• Access/SEcurity
  • Who can join
  • Power level syncing
  • etc
• Your Settings
  • Publish to my profile

For most settings the changes would be instantaneous. The exceptions would be anything that has some sort of risk involved (such as the display name/avatar area or password changes). The risky areas should be surrounded by a border to indicate that the settings are grouped to the save button (as is the case with the avatar stuff in the mockup).

Thoughts?

[turt2live]

@lampholder and @ara4n - I'm particularly interested in your feedback. If this sounds reasonable, I'll be happy to add it to my list after granular settings and the few other PRs I have open are complete.

Edit: I'm also willing to make a quick and dirty version within Riot if my fiddle isn't clear

[uhoreg]

also related: #3243 (your mockup is basically what I was thinking of for that issue)

Personally, I would call it "Display" instead of "Personalization" (and I guess "personalization" would be "personalisation" in en_GB?) Also, I would add a "Privacy" tab that would contain the "Don't send typing notifications" and "Opt out of analytics" options (and eventually "Don't send read receipts").

[pafcu]

Would it be possible to have all the settings on the same "page" but allow jumping to the relevant section via the sidebar? This would allow scrolling through all the settings, rather than having to do a lot of clicking. This is especially useful the first time, if you want to see what settings actually exist. I think scrolling is something that fits very well into a web UI (most pages require scrolling, so users are familiar with this), as opposed to traditional apps where you usually do have separate pages/tabs when you have a lot of settings.

[pafcu]

Also, personally I think risky settings should also apply immediately, but only after confirming via a dialog that explains why it is risky, and what you should take into consideration when applying the setting, and whether it is possible to undo.

[lampholder]

I'm super excited that this is getting some enthusiastic attention - I'm very keen for us to address the... suboptimal situation we find ourselves in as regards riot web settings 😁

Before I join in on the specifics of this, I'm going to splurge a summary of my current thoughts on this topic 😀

Since we've been wrestling with settings for groups (with the modest goal of simply trying not to make the whole settings picture materially worse) I've been considering our general settings woes through a number of lenses:

Conceptual "types" of settings:

• The concept of "properties" - settings associated with an entity that:
  • only priviledged users can change
  • affect everybody's experience of that entity (e.g. public/private, invite only, power levels, name/description)
• The concept of "preferences" - settings associated with an entity that:
  • anyone can change
  • affect just the changer's experience of that entity (e.g. room colour, tag)
• The concept of "default preferences" - "properties" that can be overridden by anyone

Persistance modes

• Direct manipulation (changes persisted immediately - no save button)
• vs
• Delayed persistance (changes persisted by clicking a save button; multiple orthogonal changes persisted atomically)

General UX considerations

• Check box vs toggle
• How to design a direct manipulation textbox/area that doesn't persist onblur (and doesn't surprise anyone by persisting their half-written description changes, etc).

I'll follow up with some more thoughts relating to the proposal (probably now after lunch)

[pafcu]

It might make sense to check how these things are handled in e.g. Windows, KDE, Gnome, macOS, iOS, Android, ...

[lampholder]

Certainly for iOS and Android we (should) be following the established patterns for those platforms.

For web, I think it's wise to take inspiration from well-built and familiar systems, but also to be aware that the web defines its own grammar, too.

Desktop is a pain in the ass :D Since it's just web, wrapped, it's always going to feel a bit clunky I think (though I'd be interested to hear other perspectives on that - do regular electron app users generally (not just Riot) lament the app's web origins or do they accept them as part of the package?

[lampholder]

Responding to the fiddle:

I really like the structure :) I also agree with @pafcu's point about the value of all the settings being on the same page - it feels like one could tractably have @turt2live's tabs (esp in their current top-left position) both:

• fast-scrolling you to the relevent place in a larger list, and
• updating-as-you-scroll to indicate where you are in said list

For most settings the changes would be instantaneous.

This is aligned with our desire for direct manipulation - at the moment I think the dropdowns and the checkboxes don't feel like they're doing any direct manipulation to me. Potential suggestions:

• replace checkboxes with toggles and dropdowns with sliders
  • pros: more closely aligned with direct manipulation paradigms
  • cons: perhaps more closely aligned with mobile UX/things you touch with fingers
• reinforce clicks "actually doing something" by having a spinner spin and resolve into a "success" icon

Regarding the naming and grouping of settings, I feel like it's important for users to have a clear mental model about:

• which changes affect things globally (like room settings),
• which changes affect their own experience of riot/matrix globally (email, msisdn, password, room tags, etc.), and
• which changes affect their own experience of riot on that specific client instance (room color, some notifications, etc).

What do other people think?

[pafcu]

I agree about toggles. Sliders IMHO imply an ordered relationship and can replace dropdowns and radiobuttons in situations like "Low - Medium - High" and "Off - On - Noisy", but not "Red - Green - Blue".

I think text boxes and can also be persisted on blur almost always. For passwords I would actually recommend a "Change password" button that pops open a dialog asking for the current password and the new password twice.

For emails and phone numbers you can add a small "Please confirm your email/phone number. Cancel / Resend" beneath the field to indicate that the setting has been persisted (but not yet confirmed). Cancel and Resend would be links to that when clicked perfom said actions (Cancel would simply invalidate the confirmation link in case it has already been sent out). There can be a small delay (e.g 10s) before actually sending the confirmation, which would allow the user to cancel before actually sending if they notice a typo immediately.

I don't see a problem with persisting e.g. display names and aliases on blur. Again, you can have a small delay of a few seconds before the change is actually sent over the network, so that a user can correct any typo they notice immediately without spamming rooms with lots of name changes.

[turt2live]

The idea of a scrolling page would be possible, although it has some harder problems to solve. For instance, if someone is on a taller monitor (like myself), they may see multiple sections at once, and clicking the tab would appear to do nothing. It's fairly common on some documentation sites where the table of contents doesn't match what you're looking at because of the content being too small.

Toggles also make sense to me. I forgot to mention it, but the idea would be to replace all checkboxes with toggles in the mockup. Sliders feel a bit questionable to me, but may turn out to be better than a dropdown (I'd have to try it to form an opinion).

Spinners give the app a bit of a sluggish feel. Instead, maybe something like this would work? https://jsfiddle.net/turt2live/uzgfovsg/ (with appropriate css and care, of course).

The names of the categories definitely need some work.

I'd rather keep the display name and avatar behind an explicit button. Saving on blue gives too much opportunity for accidental changes leaving the avenue open for embarrassed users. The phone and email verification is a bit messy as is, and a resend button could certainly help. Phone and email could also be moved out of the risky box, as they are somewhat less dangerous (you have to confirm your email before it takes effect).

Delaying the email notification doesn't make much sense to me. Chances are people won't typo their email too often, and sending it to the wrong address isn't the end of the world. Having the confirmation land in the inbox as soon as possible so they can return to Riot is more desirable in my opinion.

[pafcu]

and clicking the tab would appear to do nothing.

I feel like good responsive design would be to not show the menu at all in that case?

as they are somewhat less dangerous

I disagree. People typo their emails often (especially people who don't use them that much and barely even know theirs) and if you put in someone else's email they can now reset your password, right?

[t3chguy]

@pafcu not until you verify it

[turt2live]

Getting rid of the menu wouldn't make much sense to me, as the page would be back to what it is currently (a pile of settings). I was going to use the Stripe API as an example, but they seemed to have made the whole experience better: https://stripe.com/docs/api

Emails require verification before they are useful.

[pafcu]

@t3chguy But you verify the email address by clicking the link in the email, right? So I actually typo my email, the recipient clicks the link, and bam, now they can reset my password. Or am I missing something?

[pafcu]

@turt2live IMHO the current mess is due to the lack of clear sections and headings, not the number of settings.

[t3chguy]

I'm hoping you have to be logged in on the machine you click the link on for it to actually work

[t3chguy]

but thinking about it, since its a link to the IS, probably works without it

[turt2live]

The cancel button would allow you to invalidate a pending confirmation. The security of such options is almost certainly out of scope for the time being and covered by other issues (hopefully).

[lampholder]

I wish github let you react to individual paragraphs of people's statements :P If it did, I'd have put a 👍 next to most of what everyone has said here :)

Sliders IMHO imply an ordered relationship and can replace dropdowns and radiobuttons in situations like "Low - Medium - High", but not "Red - Green - Blue".

Yes - we should only use them when there's a hierarchy. Notifications (off, on, "noisy") would work. Not for... language :P

Spinners give the app a bit of a sluggish feel. Instead, maybe something like this would work? https://jsfiddle.net/turt2live/uzgfovsg/ (with appropriate css and care, of course).

Agreed 100%.

General onblur thoughts

When we were discussing textbox/area saving on blur previously I mocked up a UX that would highlight unpersisted text changes and give people an opportunity to persist/undo:

This would probably need to be combined with something that alerts you to any unpersisted changes on leaving the page (which is a bit grim) but protects against the half written display name/half composed group description problem.

[pafcu]

I'm still not a huge fan of the explicit saving stuff. When creating e.g. a new room, you end up clicking save a lot: Name. Save. Topic. Save. Avatar. Save.

[turt2live]

That's why I'd group the name and avatar at least, so that's one button. The topic could be argued on either side: part of the name/avatar or on it's own (I'd probably just group it).

[uhoreg]

While we're talking about revamping the settings screen... one other thing to consider would be adding some sort of help text.

[lampholder]

I'm still not a huge fan of the explicit saving stuff. When creating e.g. a new room, you end up clicking save a lot: Name. Save. Topic. Save. Avatar. Save.

I hadn't considered that - I wasn't thinking we'd need an explicit save for avatar, though, since an avatar change is already an atomic change - I'm thinking of text inputs as a special case because it's likely that people will want not want to commit a text field mid edit.

[lampholder]

While we're talking about revamping the settings screen... one other thing to consider would be adding some sort of help text.

I'd be a huge fan of our introducing some microcopy - I might have a go and see what that looks like.

[pafcu]

I wasn't thinking we'd need an explicit save for avatar

I think @turt2live wants to avoid you accidentally selecting the wrong file in the file selection dialog, and sending your embarrasing vacation picture for the whole world to see. There definitely should be a way to preview your avatar before setting it.

edit:

However, rather than having an explicit save button on the setting page, I'd have it like now, but after choosing a file, show a dialog that allows you to crop the image. The image could also be shown in various sizes here, so the user sees how well it works as a tiny icon, and not just a large photo. This makes it possible to avoid having an explicit save button on the settings page, and allows for additional functionality to be added easily without cluttering the settings page.

I'm thinking of text inputs as a special case because it's likely that people will want not want to commit a text field mid edit.

Sure, but how common is it that people unfocus something in the middle of editing (by clicking somewhere else on the page, switching to e.g. a different browser tab should of course be ignored)? Simple misclicks can be avoided by having a small delay before actually sending over the network. It's not a huge issue, it just seems inconsistent that everything else is updated instantly except one type of UI widget.

It's not super important though, so I'll just stop spamming my view now :-)

[lampholder]

I think @turt2live wants to avoid you accidentally selecting the wrong file in the file selection dialog, and sending you your embarrasing vacation picture for the whole world to see. There definitely should be a way to preview your avatar before setting it.

Agreed - it would be worth having a reusable component that could do this for pasting/uploading images in messages, too.

Sure, but how common is it that people unfocus something in the middle of editing

There's a chance I'm just overthinking this :) Save-on-blur might be most annoying for group long description, which could be quite... long (and hence is more likely for people to switch out midway through). We can of course trial the text input special case and see how it feels to use.

I'll just stop spamming my view now :-)

Personally I've found all the input on this thread super useful - thank you to all involved 😁

[turt2live]

The other reason I want to put a button to save the avatar is to prevent the repetitive uploading people do. I often see people upload an avatar 2-3 times before settling with something. Some people also get out of the settings screen and apologize to the room for the spam they didn't realize was happening.

Saving after a delay on blur is worse to me than just saving when I misclick. Chances are if I'm not looking at the page (ie: googling something in another tab, cutting/pasting from another section of the UI, or flipping through a notebook) then I'll miss the saving animation. At least with immediate on blur, there's a chance my focus hasn't been lost yet, and I'd just be disappointed that my half-finished changes went out to a few hundred people in the room.

[pafcu]

then I'll miss the saving animation.

There is no reason you can't show something on blur, just because it takes a while to send it over the wire.

[ara4n]

+1 to putting a confirmation button on avatar uploads.

[ara4n]

I just discovered some long lost assets for settings screens, which provide a good template for consistent aesthetics for settings in general (although the actual content has moved on a bit since then):

Meanwhile, I'm not sure where @lampholder wrote up the IRL discussion he/me/@AmandineLP had yesterday, but the conclusion was that we should turn UserSettings into a multitab approach (with a vertical stack of tabs), as proposed by @turt2live. Rather than each tab being a separate component/view though I think we should have all the views on the page in a long list; each view being as high as the viewpoint, so you get the impression of using the tabs to jump down the list. This means that Cmd/Ctrl-F still works, without overloading the user with too much detail.

Finally, as a subsequent step, we can insert a SimpleUserSettings landing page (as proposed by @AmandineLP) which pulls out the most common settings whilst providing links to the tabs of the main UserSettings component as an even nicer refinement in future.

[turt2live]

Sounds like a plan! Unless someone beats me to it, I'll happily work on this in a post-granular settings world :)

[turt2live]

Link dump of various suggestions from the past. Nothing is concrete.

• https://docs.google.com/document/d/1CfyI8Oq0S0Wkcfkg5ukxzy1V2Pg97d8WFvBNXeQ8jD0/edit
• https://docs.google.com/document/d/1apqMz9rJUQgab5ZwcFfJFLBbLpHtjClK8i_qC0KmqR8/edit
• https://docs.google.com/spreadsheets/d/1zIk0Mt9N47pbnDYWJStSSv8qo7yyaz7ixSg5Cg2Mg1I/edit
• https://docs.google.com/document/d/1BGMSZrRl_61MFMn2JkKRsNlT6W6EYQaVkyB_qNZJt0U/edit (notifications - not directly related)
• https://docs.google.com/document/d/1Kn-mz2dDce9Cqc4oUTl5yJXGvmTlky1_KezuwUg58x0/edit (already implemented)
• Improved Settings order/grouping riot-meta#70

[ara4n]

Whilst we're gathering other source material together, here's more working from @lampholder (looking at classifying the existing UserSettings into "preferences" versus "properties" - i.e. per-user preferences versus shared properties common to multiple users:

[ara4n]

To conclude: it looks like we have alignment between @turt2live, @lampholder, @AmandineLP & me at least:

• To split the settings into multiple 'tabs' (presented as a stack on the left hand side of the page, position: fixed)
• Put all the settings themselves on one page, but with each section sized so its height is at least the height of the viewport, thus having the tabs act as anchor links into the page. This lets people ctrl-f to find settings if they so desire, whilst still presenting each section effectively as a separate page. It's analogous to a 'scrolling full screen' web design, a la https://alvarotrigo.com/fullPage.
• For the first tab to show simple settings, perhaps linking also to the other tabs. (An alternative might be to have a SimpleSettings landing page before you get to the advanced one with the tabs in future, but I think we should try it like this to start with)
• To use a 'direct manipulation' UI idiom everywhere. In other words, no global 'save' buttons on settings page; instead settings take effect immediately (showing a spinner to spell it out to the user). Text fields have a save/cancel button (similar to Tom's mockup). We could specialcase the combination text field of Name & Topic in RoomSettings to use a single save/cancel button if we're worried about having to click "save" too many times - although I'm hoping that even the visual existence of save/cancel button will encourage people to hit enter to save (especially if we animate the 'save' button to give feedback when that happens) and so avoid the feeling of having to constantly hit 'save'.

I'm not sure anyone has got hugely strong thoughts as to what setting goes into which section.

@lampholder's notes on the above are: https://docs.google.com/document/d/1CfyI8Oq0S0Wkcfkg5ukxzy1V2Pg97d8WFvBNXeQ8jD0/edit#

It sounds like @turt2live has the conn on making it happen (thank yoouuuuuuuuuu!)

[turt2live]

After some discussion in #riot, I'm starting to get some motivation for working on this again. Since this was last updated, the Great Relayering happened though, so I suspect the existing branches won't be an easy merge.

Either way, looks like a prime target for a weekend project.

[turt2live]

Ultimately this got fixed, and I'm intentionally pretending that group settings are a thing. When we fix groups, we'll fix the settings page.