利用者:Lijenstina/AddonUIExperiment

Add-on UI layout Experiment / proof of concept

The current Add-ons UI layout, while conceptually simple has some limitations. Exploring the available add-ons shipped with Blender is not as straightforward. The dependence on the active filtering which doesn't offer feedback about what is available or currently hidden can be confusing. The list (in the current developer list is over 200 and in the release is over a 100) can be too long to be comprehended in it's totality can be an obstacle to exploration for the new user.

From some videos of tutorials on the Internet when an add-on is needed for a specific workflow, the authors rarely do expand the add-on itself to reveal the information and possible preferences. After the 2.79 release there was a series of task on the bug tracker related to moving the default locations of the add-on panels in the 3D View Toolbar region which implies that users didn't expand the activated add-on to reveal it's preferences.

With that in mind this concept tries to address those issues, however there are some limitations of the current API that prevent the possible workflow completely. Those would be mentioned bellow.

---

Proposal Overview 1) Information about filtering 2) Page Navigation option 3) Support Level icons association 4) Add-on list with the current expanded add-on 5) The Information / Preferences region

This concept comes from two principles:

1) Information immediacy - Separation of the add-on enabling / disabling and listing on one side; the information and add-on properties on the other region

2) Current State - More feedback / options related to filtering and add-on states

Information immediacy - Clicking on an add-on will show it's information without requiring any additional action of the user (like clicking in the arrow on the left). The whole add-on box can be clicked exposing the information on the right. Directly enabling the add-on will do the same with the addition of revealing the preferences. After some experimenting with allowing all expanded add-ons to be displayed in the information region, the conclusion was that it was too cumbersome to deal with - as it introduces complexity to the user without any clear advantage (scrolling or enabling add-on is not any faster, the information feedback is buried under the possible long list). As a consequence only one expanded add-on should be allowed at the given time. That way it is always clear which add-on information is currently explored.

Current State - Provide feedback about the filtering options. The number of currently displayed add-ons compared to the all available is always displayed. If filtering is set in a specific way so the there is no add-ons shown - give some information about it. The support level Enumproperty has appropriate icons associated with the entries. As the filtering has a compound effect, Support Level + Search + Category it's easy to end up with an empty list that can be confusing to the user. Relatively simple information strings will point the user to change filtering options.

Current state Feedback

---

Limitations

Since this is a python only mock-up it relies on the current functionality provided by the API. Noticeable issues are:

1) The operator text is always aligned to the center

2) Only one color (red) is available for feedback on the state (using the alert Layout call). Only operators can have that state (layout.box cannot be colored - a minor issue, nevertheless could be useful in certain cases depending on the needed output)

3) The Enumproperty with the ENUM_FLAG option cannot display icons without conflicting with it's functionality

4) The User Preferences editor has only one region - and all the UI elements are defined header-less Panels. They are displayed only top to bottom - which means that everything is under one scroll bar including the tab switcher. That defeats the purpose of information display on the right as it will be still on the top while the list is scrolled down

5) The default size of the user preferences is relatively small. A slight increase in the size would make navigation more easy. As the default screen size goes towards the at least 1920 x 1080 as a standard that could be addressed in the future.

Example of the issue related to 4) only one region available

---

Scrolling / Page Navigation

Even if the issue of one region available for the Preferences' entries is solved (look bellow for some possible conceptual / API considerations), the issue of long lists still remains. To make exploration of add-ons easier this concept introduces an optional Page Navigation. When active, page navigation limits the displayed entries to a number defined with the page size. That allows the user to fit the list into one screen and sift through pages without scrolling. The initial concept had the Page Navigation as an overriding filter - disabling all the other filtering options and exposing all the available add-ons, but after some consideration, now it works with all of them. If the number of items is less than the defined page size it just works as the current system. If deemed useful, an option of disabling other filtering options can be added to allow exploration of all add-ons available without depending on the active filters' state. As the new user doesn't really know what categories / support levels really mean. However that could be easily added later on, albeit on the expense of complicating things a bit further.

Page navigation Overview. In this case on the top left the user defined the Page size to be 21 entries, and currently is on the page 7

---

Some API considerations

Apart from addressing the issues in the Limitations section, this proposal would benefit from introduction of two another regions in the User preferences editor.

1) The switcher on top would include the current Enum preset. Optionally it could be used to display notifications about some Add-ons functionality and other User preferences sections. For instance, when an theme was saved and modified, when there are unsaved changes. It should generally be fixed in size and always on top.

2) Introduction of a new vertical region (splitting the window in half or other sizes if necessary). That would allow for the add-on UI to work correctly - independently from the length of the add-ons list. On the other side, that would imply a refactor of the Preferences UI elsewhere.

While adding some additional work (what options should go into a specific tab) that also could open some possibilities: showing some help information for the selected option, thumbnails/ color presets for the themes look, separation of the settings into categories like advanced / basic, introduction of a category switcher all across the board etc. Still that is something that should be explored depending on the design and available developer time.

An another useful feature would be exposing the possibility to jump on top of a region (scroll reset) when needed to allow the Information region not to be a subject of scrolled away position and hidden content. (something that happens in the TOOL_PROPS region in the 3D view when a previous operator UNDO has a lot of settings and the current active one doesn't). Possibility of locking the relative widths of the areas or setting the width through script could be beneficial, catering to different needs of specific User Preferences sections.