[Bf-taskforce25] New tools mockups

Wed May 6 22:05:32 CEST 2009

Been thinking an alternative for tools workflow that could mix the benefits

of both, fast-modal (actual) and flexible-non-modal (sel/act/tweak), and
since there have been pointed out some inconvenients with sticky keys,
tried to make the workflow use the same key (and type of pressing) for
both (I believe is similar to what Michael Fox has described before):
http://img512.imageshack.us/img512/333/toolsworkflow.png

Since some people dislike manipulators, the workflow includes them just
as optional..

For those who like them, I was trying to find a way to make them
customizable, not only in shape but in structure and functionality, giving the
users the ability to build their own tools. And came up with a method that
may work (not sure how much technically viable it is) and maybe could be
extended to other parts of the UI. This method is a WIP:

Video of the mockup:
http://www.vimeo.com/4494829

Some descriptive images:
http://img515.imageshack.us/img515/1377/uirigging.png

The .Blend rig used in the video:
http://www.4shared.com/file/103377534/719e6df8/extrude_rig_example.html
(To have that LMB-Drag feeling of manipulators set Left Mouse and
Drag Immediately in the Preferences editor).

All widgets in there work using LMB-Drag action.

________________________________
From: Martin Poirier <theeth at yahoo.com>
To: The Blender 2.5 TaskForce <bf-taskforce25 at blender.org>
Sent: Saturday, April 25, 2009 2:16:50 PM
Subject: Re: [Bf-taskforce25] New tools mockups

--- On Sat, 4/25/09, William Reynish <william at reynish.com> wrote:

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

Quite.

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

If they aren't present in the tool options (last operator options), how do you differentiate between tweaking the result of the last operator and changing a setting before using the tool another time (obviously NOT wanting to affect the result of the last operator)?

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

That's a misrepresentation.

- There's no reason that a new workflow in 2.5 has to keep extrusion type a blocking step.
- Releasing a key (the missing 3rd step with sticky keys) has comparable mechanical complexity to clicking a mouse button. In both case, the three steps are comparable in speed (not so if a mouse button had to be held down though).

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

Actually, my skepticism is caused by a (perhaps unjustified) feeling that a lot of people see non-modality has the "be all, end all" of UI design and are willing to sacrifice the good bits of the current design on the altar of purity of form.

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

Making them impracticable to use because you have to hold down another key at the same is synonymous to getting rid of them (the ways to tweak the options while the tool is running).

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

Aside from constraint axis, this is already how it works (with perhaps the exception of PET size, which, while global, is not accessible outside the operator). So saying that they shouldn't have to be applicable only while the tool is running is perfectly understandable. Actually, a good portion of them began as tool options with later added in-transform hooks to modify them during the operation (transform orientations, pet falloff, ...).

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

That's not quite what your earlier proposal was though.

"""
Press and hold: extrudes out the selection and lets the user position the extrusion using the mouse. Letting go of the e key applies the tool, but the tool settings can still be tweaked afterwards.
Tap: performs the extrude, but applies no translation. This can be numerically tweaked using the tool tweak settings, along with steps and other tool settings.
"""

Is what you are suggesting now that both "tap and confirm" and "press and release" are just different way to invoke the interactive mouse driven 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.

For that issue, it's important to make a distinction between tools that use mouse motion (most transform without snapping) and tools that use absolution mouse position (transform with snapping and some others, knife, loop cut, rip).

In the first case, it could be perfectly possible to make the cursor invisible during the operation (removing the screen limits), accumulating delta motions for the operator, while in the second, the problem is absent entirely.

In transform's case, the pointer could become visible when Ctrl is pressed with Snapping option turned on.

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

Could you give a detailed explanation of how that would work, from a user point of view?

The only way I can imagine is to have something like manipulators.

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

Indeed.

Please note that I'm not trying to be confrontational on purpose, but someone has to raise those issues. We can't just rush into the UI flavour du jour while ignoring all of what made past interfaces work faster or slower (not just talking about Blender here).

Martin

      __________________________________________________________________
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
_______________________________________________
Bf-taskforce25 mailing list
Bf-taskforce25 at blender.org
http://lists.blender.org/mailman/listinfo/bf-taskforce25

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090506/fc79b0ec/attachment.htm 