Page MenuHome

Redesign User Preferences
Open, NormalPublic

Tokens
"100" token, awarded by Zino."Love" token, awarded by antoniov."Love" token, awarded by jonathanl."Love" token, awarded by jendrzych."Like" token, awarded by xrg."Love" token, awarded by rawalanche."Love" token, awarded by 0o00o0oo."Love" token, awarded by razgriz286."100" token, awarded by billreynish."Like" token, awarded by duarteframos.
Assigned To
None
Authored By

Description

Motivation

There are two main reasons why the User Preferences need an overhaul:

  • Outdated/aging design

    When the current User Preferences design was created, there were much less options than there are now. As more were added, the User Preferences became a pretty polluted place. Finding options in it became increasingly harder and by now it's just not pleasant to work with.
  • New concepts don't fit into current design

    2.8x introduces new concepts that require new kinds of settings. One being workspaces, which users can set up to their liking and store in a custom configuration. This configuration is separate from the user preference configuration (userpref.blend vs. workspaces.blend) so their setup should not happen in the regular User Preferences. Another new concept was splitting system settings apart from User Preferences. The system settings would be purely for the current work station and its devices (GPU usage, monitor configuration, pen/touch tablet options, etc.)

    Diagram by @Ton Roosendaal (ton) from here.

Proposed Design

I'd propose a design that is similar to how many applications, websites and operating-systems (or desktop environments) do it:

Notable suggestions are:

  • Rename the User Preferences window to "Settings".

    The window would now show more than just user preferences, so it should be renamed accordingly.
  • Increase size of Settings window.

    The current size of the User Preferences limits us too much in space. We end up cramming together options quite a bit, even though some more whitespace would increase readability.
  • Have two levels of grouping, first the "category" (User Preferences, Workspaces, System), then the settings-"group" (Interface, Add-ons, Theme, Devices, etc.). Of course "category" and "group" are tentative names.
  • Add a search button to search for settings.

Note that the mock-up shows changes to the theme-system as well. These are not part of this proposal. Changes like that can be checked on separately as we go more into details.

Rationale

A design similar to the one proposed, should bring multiple benefits:

  • Allows having a central place for user preferences, plus the new workspace and system settings.
  • Options can be placed in a more structured and readable way.
  • The design is more extensible in that new categories or groups can be added as needed. Old one was too static (as in, we tried to fit everything into the few existing categories).
  • The term "Settings" is often used in other applications and should therefore be easier to find for novice or occasional users.
  • Many applications and websites use a similar design. That should make it easy to learn for both new and existing users.
  • A search button should hugely increase usability of the Settings window, as it's not untypical to search a very specific option.

Workload

Although there may be some challenges, I expect this redesign to be a nicely isolated task where we can do much good with rather little effort. Definitely a doable change for 2.8. Especially since it allows us making the workspace configuration more flexible & useful (we don't have a proper UI for that yet).

We may have to add special widgets for the category/group chooser, but a temporary solution using existing widgets would work too.

I wouldn't mind working on a prototype and transforming it into a ready-to-use state once the design is agreed on. A nice task for until we know how to continue with the topbar.

References

I did do some research before opening this, in fact the proposed solution is based on this KDE-settings mockup:

More mockups using this design here.

Other useful references:

Event Timeline

Julian Eisel (Severin) triaged this task as Normal priority.

In general, I don't have any major objections to the stuff proposed here.

Various random points (even though we're still just dealing with rough ideas here atm):

  • Renaming this thing to "Settings" is probably ok. Interestingly, quite a few apps seem to use various different terms here - e,g, a quick check here finds: "Options" (Firefox, MS Office), "Preferences" (MuseScore, Inkscape, Audacity), and "Settings" (MS Windows, Vivaldi, Krita (but only as a menu name; the actual entry is called "Configure Krita"))
  • "Paths" is often something that's very system-dependent AFAIK (e.g. stuff like tempfile directories, editor/viewer paths, etc.), so it probably should go under "SYSTEM"
  • The "Input" and "Addons" sections you've currently got under "USER PREFERENCES" is probably something that will still be a bit contentious (e.g. what exactly shows up there vs in the workspace specific modes?)
  • It would be great to make that space/editor/area be made up of multiple regions, instead of just a single one (as now), so that the navigation stuff is always visible. IIRC, we had a proposal once to use a real tab strip, but with this multi-level design.
  • For the search, it'd be great to have this implemented per user-pref instance, instead of being a semi-global thing. This applies to both the proposed search option, and also the addons search. This is something that has bugged me for a while, especially as it makes it pretty nasty trying to check on the keymaps for properties in several different areas
  • Another point to note about search is: How are we going to do it? We could just naively filter by property names, but what about things like the labels and layouts that are sometimes needed to make these things work? We can have this discussion later in the process, but it's just something to keep in mind
  • Perhaps I'm missing/forgetting something here, but how do we intend to handle big equipment-related pen/tablet vs mouse vs mixed configuration things with this UI? Like, where would I expect to go looking for those settings, since this sort of thing could have quite a big impact across the set of keymaps + addons installed (e.g. for a tablet, you might want a bunch of addons for easier access to certain functionality for instance). Is this something that falls under "User Preferences > Input" or "System > General" or do we even need a separate category to deal with this?

Various random points (even though we're still just dealing with rough ideas here atm):

  • Renaming this thing to "Settings" is probably ok. Interestingly, quite a few apps seem to use various different terms here - e,g, a quick check here finds: "Options" (Firefox, MS Office), "Preferences" (MuseScore, Inkscape, Audacity), and "Settings" (MS Windows, Vivaldi, Krita (but only as a menu name; the actual entry is called "Configure Krita"))

Yeah... always annoys me that there isn't a standard for this. When dealing with other apps I always search through the menus for an "Options", "Settings" or "Preferences" entry. I bet I'm not the only one. Not sure if I'd catch "User Preferences" if I didn't knew it was called this way.

  • "Paths" is often something that's very system-dependent AFAIK (e.g. stuff like tempfile directories, editor/viewer paths, etc.), so it probably should go under "SYSTEM"

Indeed, might make sense. For the future, it might also be nice to have a "Security" group for .py script autorun , sandboxing options etc.

  • The "Input" and "Addons" sections you've currently got under "USER PREFERENCES" is probably something that will still be a bit contentious (e.g. what exactly shows up there vs in the workspace specific modes?)

In my mind the workspace add-ons would be add-on overrides (to override enabled/disabled state and add-on settings). Same with the keymap btw. The mock-up should probably say "Add-on Overrides" in the workspace category.
Note that the groups visible in the mock-up are not meant to be part of the proposal, just some reasonable placeholders to show the point.

  • It would be great to make that space/editor/area be made up of multiple regions, instead of just a single one (as now), so that the navigation stuff is always visible. IIRC, we had a proposal once to use a real tab strip, but with this multi-level design.

What exactly do you mean with the navigation stuff? The category/group buttons? I actually thought of this as a separate region too (esp. since it might need separate scrolling).

  • For the search, it'd be great to have this implemented per user-pref instance, instead of being a semi-global thing. This applies to both the proposed search option, and also the addons search. This is something that has bugged me for a while, especially as it makes it pretty nasty trying to check on the keymaps for properties in several different areas

Huh, interesting. Never faced this, but I also only use one UserPref instance usually. Will keep that in mind.
(Testing this, the keymap editor seems to do this just fine.)

  • Another point to note about search is: How are we going to do it? We could just naively filter by property names, but what about things like the labels and layouts that are sometimes needed to make these things work? We can have this discussion later in the process, but it's just something to keep in mind

Yup, how exactly it's going to work is something we need to look into once basic settings UI design is agreed on. Think the search can be implemented in .py, so we can easily test multiple versions.

  • Perhaps I'm missing/forgetting something here, but how do we intend to handle big equipment-related pen/tablet vs mouse vs mixed configuration things with this UI? Like, where would I expect to go looking for those settings, since this sort of thing could have quite a big impact across the set of keymaps + addons installed (e.g. for a tablet, you might want a bunch of addons for easier access to certain functionality for instance). Is this something that falls under "User Preferences > Input" or "System > General" or do we even need a separate category to deal with this?

In the mock-up I added a "Devices" group as part of the system settings (also for things like HMDs). That might already work fine. I think it would additionally be wise to split the "Input" tab into "Keyboard" and "Mouse", just for better structuring. If needed we can also add "Pen Tablet", "3D Mouse" and such.
Now, if you want to enable an add-on based on a specific device - shouldn't the add-on handle this somehow? Either in the poll-callback or in its settings. I guess these would be add-ons specifically for a device type (tablet, 3D mouse, ...) anyway.

Implementing a data independent scrollable box (scroll_box or similar) would be a good start. UI list are a bit difficult to use as they need data defined first and a counter for tracking the active state.
Having a box widget that makes all UI children entries being accessible with scrollbars (vertically and horizontally) could help a lot with organization and saving space. Behaving like a region in a box. :)

Could this be a good time to propose a NEW SPLASH screen? to better simplify the first user enounter with the software?

@Julian Eisel (Severin) Right. That sounds reasonable.

What exactly do you mean with the navigation stuff? The category/group buttons?

Yep, that sidebar :)

I think it would additionally be wise to split the "Input" tab into "Keyboard" and "Mouse"

Hmm... I'm not so sure that it really makes sense to do that - at least not right now. Maybe for global settings like rotate/scrollwheel behaviour vs general hotkeys it might be ok, but I have doubts about whether it'd really be beneficial splitting out stuff like Selection Operators/3D Cursor/GPencil etc. actions on mouse clicks from hotkey invoked stuff. Especially since it's possible to still create conflicts by setting a normal key as a modifier for a mouse-action when that same key may be used elsewhere.

@Vuk Gardašević (lijenstina) You're basically just describing the "View2D" system :P While we haven't actually tested using one View2D nested inside another one (i.e. they are currently only inline-attached to all ARegions), IIRC, there isn't actually stopping you from being able to use one like that. On that note, maybe I need to give this a go ;)

@David (activemotionpictures) That's a separate issue. I'm not sure if it's currently on our todolist or not

This generally seems fine to me. I think the breadcrumbs at the top are unnecessary, it doesn't look like the nesting would need to be very deep.

If you go ahead with this, I suggest to implement it incrementally into blender2.8, don't make a big branch where you try to do everything. But rather finish it step by step, for example:

  • Create two regions with navigations tabs on the left.
  • Start breaking up categories and reorganizing buttons into them.
  • Add two levels of navigation.
  • Make category widgets look nicer.
  • Improve button layouts for each category.
  • Implement search.

Could this be a good time to propose a NEW SPLASH screen? to better simplify the first user enounter with the software?

I'd love to see work on this (in fact, I already did some research), however I'm afraid it's much more complicated than this settings UI redesign. For example the new splash screen should contain a quick setup for special devices (3D mice, pen tablets, multi-touch screens, etc), we don't really know how to integrate such settings nicely yet. There are quite a few loose ends like this.

I'm familiar with what you proposed in other discussions, it's definitely a good start. I'd propose to make it a multi-page splash screen though, see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Splash_Screen.

You're more than welcome to create a proposal, just saying that this task is more tangible and that I'd like to focus on it first.


I think it would additionally be wise to split the "Input" tab into "Keyboard" and "Mouse"

Hmm... I'm not so sure that it really makes sense to do that - at least not right now. Maybe for global settings like rotate/scrollwheel behaviour vs general hotkeys it might be ok, but I have doubts about whether it'd really be beneficial splitting out stuff like Selection Operators/3D Cursor/GPencil etc. actions on mouse clicks from hotkey invoked stuff. Especially since it's possible to still create conflicts by setting a normal key as a modifier for a mouse-action when that same key may be used elsewhere.

Correction: There should definitely still be a group for the keymap-editing, maybe call it "Shortcuts/Key-map" or so. What I wanted to say is that we should have one group just for keymap-editing, and separate groups for device specific options. That way we can keep the individual groups uncluttered & rather focused.


This generally seems fine to me. I think the breadcrumbs at the top are unnecessary, it doesn't look like the nesting would need to be very deep.

Think this is useful when the navigation region is hidden, or as a general hint. But indeed, it's a bit redundant.

If you go ahead with this, I suggest to implement it incrementally into blender2.8, don't make a big branch where you try to do everything.

Definitely +1. Actually wanted to do something like this, what I said about creating a prototype first may have been a bit misleading.

I think I'll actually go ahead and start working on this in the blender2.8 branch, just like @Brecht Van Lommel (brecht) suggested. There don't seem to be any bigger objections against the proposed changes :)

To be clear, by working directly in blender2.8 I meant committing safe/simpler changes directly and more complicated ones can still go through code review. I rather not have more half-finished stuff in blender2.8, but if each individual step is committed in a finished state that's fine.

You're basically just describing the "View2D" system :P While we haven't actually tested using one View2D nested inside another one (i.e. they are currently only inline-attached to all ARegions), IIRC, there isn't actually stopping you from being able to use one like that. On that note, maybe I need to give this a go ;)

Yes, that would be really helpful:)

Awesome! Sorry I didn't have time to look into this before, was busy with the Code Quest.

I agree with pretty much everything mentioned here. I would even add to the "Outdated/aging design" rationale that the current design is legacy from Blender 2.27! (2.26 and previous all settings were together in a flat layout). A quick look just for history purposes:

To sum up:

  • User Preferences -> Settings
  • Sidebar with independent scroll
  • Sidebar sections split in categories

For categories that have many subcategories, we can (in the future) look into nested sidebar navigation. See "Devices" in the video below.

Most settings could be ported as-is for the time being. And later re-design those that already have a sidebar + search, like add-ons.

This is how the current GNOME settings look like, much better than the previous approach:

Still has issues though:

  • Settings should be sorted from general to specific.
    • The first item on the list here is WiFi, which on a Desktop computer usually is off, showing the "?" icon makes it look like there's something wrong.
  • Title of the section (like "Devices") could go back to the Devices list, not a problem if we have breadcrumbs
  • When searching, GNOME shows the WiFi settings (first item on the settings list), it should show the content of the first/most relevant search result

Pretty excited about this! And can't wait to work on the simplified theme settings :)
Thanks @Julian Eisel (Severin) !

Brecht Van Lommel (brecht) renamed this task from Redesign User Preferences for 2.8x to Redesign User Preferences.Sep 28 2018, 4:45 PM

UI tweak:

  • Change name to Preferences
  • Added proper panels
  • Preferences works better like this when narrower
  • Search
  • Save Preferences moved to the side

We could make use of panels more places in Preferences, such as Themes, for example:

Made a (rough) implementation of the panel based layout for testing, which looks like this:

Patch for testing (Python only): P834

@Julian Eisel (Severin) Nice one. We could even add sub-panels here too, for things like the New F-Curve Defaults under Keyframing. This could be used to great effect many places.

As a test, I modified your Python file to do this:

@William Reynish (billreynish) suggested to go with the term "Preferences" rather than "Settings":

Hey, this is a nice improvement already. The only thing I would opine against is the name. 'Settings' is much more ambiguous than 'Preferences', especially in an app like Blender which includes many settings in the Properties Editor and lots of other places.

The name 'Preferences' serves as a much more unambiguous differentiation from other settings, than the name 'Settings'. Plus, Preferences is a general standard name for this kind of thing.

I agree with him, he makes a good point. So if nobody objects I'll change the term.

Agreed, let's change it to Preferences.

Here's a patch to add panels to all the areas of Preferences.

*Adds panels to Interface, Editing, Input, General and Files sections
*Split apart Input from keymap
*fixes the issue with the UI Scale widget glitching
*A few small tweaks

Looks like this:





This looks great. @Julian Eisel (Severin), I guess you can commit this to your branch and help reviewing it?

I think we should only commit this when it's in a finished state, since moving around items multiple times is annoying for users.

Some feedback from a quick test.

  • Python errors:
Traceback (most recent call last):
  File "/home/brecht/dev/build_linux/bin/2.80/scripts/startup/bl_ui/space_userpref.py", line 668, in poll
    return (userpref.active_section == 'SYSTEM_GENERAL')
NameError: name 'userpref' is not defined
  • Under Interface I think there should be a separate 3D Viewport panel, UI Scale, Line Width, Tooltips do not belong together with them.
  • For addons some buttons are duplicated at the top and in the header. IMO a button like "Install Addon" should bigger and have text, not be just a "+". The search box also deserves to be bigger.
  • Text and weight paint range options from System > General should probably move to Interface. OpenGL > Text options belong in the top level Text panel I think, these are about how users want things to look.
  • Region Overlap could move to Interface.
  • Cycles Compute Device panel has "Cycles Compute Device" twice.

@Brecht Van Lommel (brecht) Agreed on all points.

Re. the header, it was a bit of an experiment. We need to define the role of the header here. Currently, the placement of the Editor type selector is clumsy in the middle, and it’s also weird that it defaults to being on the bottom.

We could either hide the header and move everything into the panels, or maybe put the header at the top, and make it span the entire width to put the Editor type selector at the far left. Although it will still be mostly empty then. That was why I thought to try and move everything out of the header, so that we could simply hide it by default.