[Bf-taskforce25] New tools mockups

William Reynish william at reynish.com
Sat Apr 25 11:14:58 CEST 2009


Ah, what a discussion!

This really goes to show that this is a hot topic, and that it's an  
important hurdle to overcome.

There are, it seems, some misunderstandings that I'll need to clear  
up. Perhaps some IRC discussion might be good too, which is more  
direct, and is less likely to provoke confusion and misunderstanding.


On 24 Apr, 2009, at 7:29 PM, Martin Poirier wrote:

> That would be shit when using the API (either internally or from  
> Python). You'd have to set the toolsettings, call the operator, then  
> restore to what it previously was (unless you want to piss off users).

Well, I'm talking about the user interface level here, not Python  
scripting. In 2.4x, PET is not a property (as far as the user is  
concerned) of any tool, but rather a global setting that changes the  
behaviour of most tools. In 2.4x, you can't even enable or disable PET  
during a transform.

In the tools UI, there's no need to present this twice, both in the 3d  
View header and in the tool settings themselves, so that's why I  
consider it redundant.

On 24 Apr, 2009, at 7:34 PM, Jason van Gumster wrote:

> I'm not completely opposed to the concept of Select->Act->Tweak, but  
> it
> does add an additional step to the flow because you have to confirm
> after tweaking.

No, you don't! If anything, the Select->Act->Tweak workflow needs  
fewer clicks because if the user is content with the default tool  
settings, he/she does not even need to interact with it.


On 24 Apr, 2009, at 7:34 PM, Jason van Gumster wrote:

> And I certainly don't want to rely on holding down a
> key and applying on key-up... especially if that's the more common
> use-case. In the case of extrusion, the current moving mouse method is
> faster (and more likely to be used) than the tap method you propose...
> but the tap method has the quicker access.

Sticky keys are one solution. But if anything, it does require less  
user input. Consider the current workflow for extruding in 2.4x:

1: Tap e
2: Chose extrusion type
3: Move mouse
4: Click to confirm

With sticky keys:

1: Hold e
2: Drag mouse

If the user desires a different extrusion type, that can be tweaked  
later, but most of the time, it's just a simple swift stroke of  
holding e and moving the mouse.


On 24 Apr, 2009, at 7:19 PM, Martin Poirier wrote:

>
> As much as the press and hold sounds good in theory, having to hold  
> an additional key on top of Ctrl (and perhaps Shift) when doing  
> precise movements just seems foolish. What if you want to extrude  
> along an axis? Press X (or Y or Z) while holding down E?
>
> No way.
> ...
> All in theory, but trying holding down G (or S, or E, or ...) and  
> then press Shift-O to switch between PET falloff modes, all the  
> while keeping one hand on the mouse (or tablet).
>
> Also, while it throws transform numerical input out the windows (try  
> typing values while holding down another key), you can now type in  
> the operator param buttons instead, if you don't mind doing  
> something that worked very fast before in twice the time (if not  
> more).
>
> Martin


Well, this confuses me. I thought one of the points of 2.5 was exactly  
to get rid of the very modal workflow that most tools in 2.4x employ.  
You are absolutely right in your skepticism, were the tools going to  
otherwise continue to work like they used to.

Your main issue is with these modal operations, such as pressing all  
kinds of keys that apply only when you are inside a tool mode. Most of  
these things, like snapping, PET etc. are really more global settings  
that can affect any tool, and shouldn't have to be applied while a  
tool is in use. I'd advocate getting rid of these modal settings that  
only apply when you are in a tool mode, but that's not the same as we  
shouldn't have these settings, or quick ways to access them. The  
difference is simply that they become global properties instead of  
local to that tool, and workflow speed won't suffer. Consider this  
proposal:

*	Blender 2.5 will have a global constraining system where things can  
be constrained to axes, normal direction, surface etc etc.
*	These settings have shortcuts for fast interaction (could be the x,  
y and z keys for constraining to these axes)
*	This means that the constraint axes can be set both before, during  
or after a tool is in use.

The result is that you can keep using tools as before, where you tap a  
key, set a constraint axis and confirm, but this is no longer the only  
possible workflow. You can also set the constraint axis first, and  
then start using a tool.

Besides, the whole point of sticky keys is that they are sticky! This  
means you can still just tap a key, like before, and then start using  
that tool.

One of the big issues has to do with enabling tools from menus and  
tool lists. Many tools are very dependent on mouse starting position,  
and therefore aren't 100% compatible with choosing a tool from a menu.  
One solution is to have tools be 'active', rather than totally  
blocking, meaning that the user can use any part of the app while  
using a tool, and can start the actual transformation from any part of  
the screen, even if a tool has been enabled on, say, the left side.

I consider the tools design to be the biggest design challenge left of  
2.5, and one that hasn't been explored fully yet. Hope to continue a  
healthy discussion here and on IRC.

Cheers,

-William









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090425/20324d16/attachment-0001.htm 


More information about the Bf-taskforce25 mailing list