[Bf-interface] Workflow workshop, agenda topics and preparations

Jonathan Williamson jonathan at cgcookie.com
Fri Nov 25 04:54:10 CET 2016


Whoops, my previous email sent too soon. Here’s the full message.

Hey all!

What with my unplanned absence, I thought I’d write up a few of my thoughts (and hopes) for focus during the workflow sprint. I have three main topics that I’d love to see explored:
Tool Workflow as it relates to utilizing tools from hotkeys, menus, and toolbars
Universal (simplified) keymap with an emphasis on selection + transformation that leaves room for customization
Make Modals truly non-blocking or else remove them entirely

To expand on each of these...

Tool Workflow:
The key challenge I see is the disconnect between operators when they’re activated from a hotkey versus from a menu or toolbar. This impacts modal operators more than anything. It’s particularly problematic for mouse-location-driven operators, such as Scale, Translate, Rotate etc. Most of these operators are applicable to most all objects and modes, including Edit/Object, meshes and curves, F-Curves and Nodes, etc. 

Aside from making the interaction of the operators problematic, it also results in many of these operators being effectively useless when activated from the Toolbar. It’s even worse if you’re trying to work on a tablet-pc.

My hope is we can re-examine the Selection > Action paradigm and find a way to blend this with the inverse, maintaining the incredibly fast usage that Blender is known for (with hotkeys) while also providing a more devise-agnostic and beginner-friendly workflow from non-hotkey activations of operators. 

An operators usefulness, or interaction should not vary based on how you choose to activate it.


Universal keymap: 
The current keymap, while incredibly powerful and great for veteran users, is awfully difficult to learn, cumbersome to customize, and past a point (that point being G,S,R,E,M) it stops following any kind of sensible pattern.

My goal (as has been discussed extensively in T37417) is to introduce a simplified, more universally consistent keymap that leaves plenty of room for customization. This simplified keymap is something I’ve been working on for a while and absolutely plan to have done for 2.8.

The specifics of the keymap are irrelevant to the workshop, though.

For the the workshop, the parts that I’m interested in seeing discussed are these:
Better hotkey conflict detection and resolution
Ability to set custom hotkeys via RMB for any operator or settings list (e.g. shading, PET, sculpting brushes, selection modes). The latter of which requires Python to do at present.
A user should not be so hindered in their ability to set a new hotkey.

Non-Modal and Non-Blocking
This paradigm was an original goal of the Blender 2.5 project and I’d venture to say it’s one of the least consistent areas for tools right now. There are many tools (particularly modeling and selection tools) that are both modal and blocking. For example:
Circle and Box select are both modal and completely block all events. From a end-user perspective why can’t we navigate we navigate in modal selections?! Why can’t I select during the Knife modal, nothing is greyed out? The same goes for Python modals.
These are not easy problems but they’re absolutely solvable. 

A tool should not block the user from doing something else unless there’s a very good reason.

There’s no reason to block navigation during Circle/Box select, other than that MMB is used for navigation and de-selection (see topic 2). Also, when considering the Selection > Action paradigm, the fact that many modal tools, like Knife, completely ignore selections by default is in complete contradiction of the paradigm. 


------


As a final thought: what can we remove? What’s no longer needed, redundant, or otherwise poorly implemented that’s not doing anyone any good? It’s always easy to add new features, tools, and settings, but it’s hard to remove things. We can’t simply add, add, add, or else we’ll continue to introduce more complexity, more corner cases, and more areas of failure.

One thing we can remove is all the UI theme options! 

Cheers! I’m still bummed I’m not there to enjoy the fun and exchange of ideas.


-- 
Jonathan Williamson

On November 24, 2016 at 9:19:25 PM, Jonathan Williamson (jonathan at cgcookie.com) wrote:

Hey all!

What with my unplanned absence, I thought I’d write up a few of my key thoughts (and hopes) for focus during the workflow sprint. I have three main topics that I’d love to see explored:

Tool Workflow as it relates to utilizing tools from hotkeys, menus, and toolbars
Universal (simplified) keymap with an emphasis on selection + transformation that leaves room for customization


As a final thought: what can we remove? What’s no longer needed, redundant, or otherwise poorly implemented that’s not doing anyone any good?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-interface/attachments/20161124/e16c738c/attachment.htm 


More information about the Bf-interface mailing list