Yamyam: 1版をインポートしました

2018-06-28T21:23:44Z

1版をインポートしました

2017年12月9日 (土) 16:59にwiki>Lijenstinaによる

2017-12-09T16:59:59Z

新規ページ

=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.
----
{{clr}}
[[File:Addon_ui_layout_experiment_overview.jpg|thumb|900px|left|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]]
{{clr}}

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.

{{clr}}
[[File:Addon_ui_layout_experiment_no_options_available.jpg|thumb|900px|left|Current state Feedback]]
{{clr}}

----

===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.

{{clr}}
[[File:Addon_ui_layout_experiment_scroll_issue.jpg|thumb|800px|left|Example of the issue related to 4) only one region available]]
{{clr}}

----

===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.

{{clr}}
[[File:Addon_ui_layout_experiment_page_navigation.jpg|thumb|800px|left|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]]
{{clr}}

----

===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.

← 古い版	2018年6月28日 (木) 21:23時点における版
(相違点なし)

利用者:Lijenstina/AddonUIExperiment - 版の履歴

Yamyam: 1版 をインポートしました

2017年12月9日 (土) 16:59にwiki>Lijenstinaによる

Yamyam: 1版をインポートしました