[Bf-taskforce25] Modifier Layout Proposal

Sat Jun 6 23:36:00 CEST 2009

Hrm, I'm replying to myself a lot these days.  Maybe I should think
before sending...

> and being able to add more than one, each with
> different settings.

On second thought, this isn't so critical.  It would be a lot of work
to make this sort of functionality actually work.  And I think certain
modifiers having certain limitations (like "only one per stack") can
fit in with the user's mental model of how modifiers work.

But still, I really think the settings need to be moved into the
modifiers themselves.

--Nathan V

On Sat, Jun 6, 2009 at 2:21 PM, Nathan Vegdahl<cessen at cessen.com> wrote:
>>> In the stack, custom names are not visible.  I use
>>> custom names on modifiers and constraints all the
>>> time.
>> ....
>>
>> I didn't show it well in the proposal, but the idea is to be able to
>> click on the names of the modifiers and change them.
>
>   That wasn't what I meant.  I assumed that custom names were still
> there.  I was saying that they aren't visible in the stack because the
> stack in your proposal is rows of icons.
>
>   But I think it's a moot point now?  I think we mostly agree to
> stick with the current system.
>
> Matt Ebb:
>> I would definitely not like to have to click on individual modifiers
>> to see their settings. One of the advantages of Blender's modifier
>> stack over Max's for example is that you *can* see everything at a
>> glance.
>
>   This is also why I would like to see physics modifier's settings
> actually moved into their stack items.  As I said in an earlier email,
> if they're going to be modifiers, they should really truly be
> modifiers.  And that includes their settings being in the same place
> as other modifiers, and being able to add more than one, each with
> different settings.
>   It's a weird and confusing exception to have just these one kind of
> modifiers have their settings in a completely different part of the
> interface.
>
>   If that doesn't fit with how they work, then IMO they don't belong
> in the modifier stack at all.
>
> --Nathan V
>
> On Sat, Jun 6, 2009 at 1:30 AM, Eclectiel L<eclect25 at yahoo.com> wrote:
>>
>> I think there are no 'big' problems with the modifiers/constraints
>> workflow the way it is now.
>>
>>
>> This proposal had several intentions:
>>
>> - Attend what was previously discussed about including Physics
>> modifiers that would have many settings, needing more vertical
>> space, and could take other modifiers out of the screen, forcing
>> users to scroll, and not having the desired settings always visible.
>>
>> - Eliminating some buttons and widgets to avoid redundancies,
>> giving a cleaner aspect and reducing vertical space usage.
>>
>> - Show a drag and drop workflow. This kind of workflow may have
>> some advantages, like for instance adding several modifiers at
>> once, and allowing a cleaner interface since actions are done
>> with gestures (drag-drop) instead of using buttons/widgets. The
>> "Modifiers Row" is an alternative that makes these gestures
>> possible.
>> And any visual workflow, in my opinion, can be easily learned
>> through a video-tutorial.
>>
>>
>>
>>> I would definitely not like to have to click on individual
>>> modifiers to see their settings. One of the advantages
>>> of Blender's modifier stack over Max's for example is
>>> that you *can* see everything at a glance.
>> ....
>>
>> I like the "everything at a glance" style too. In the mockup is not
>> necessary to click on every modifier. The default behaviour is to
>> show all modifiers at once as they are assigned. And if users
>> decide, for instance, to see a Physics modifier alone so other
>> modifiers don't get in the way, they click on it, do what they
>> need, and then they show all the assigned modifiers again just
>> clicking the Modifiers Row.
>>
>>
>>
>>> My biggest concern is its heavy reliance on icons
>>> without corresponding text.
>>
>> I agree with that. I personally do ok with icons only, but many
>> people like the icons/text alternative. So it's necessary.
>>
>> For this, an alternative could be something like:
>> http://img10.imageshack.us/img10/9560/iconslistdropdowntext.png
>>
>>
>>
>>> In the stack, custom names are not visible.  I use
>>> custom names on modifiers and constraints all the
>>> time.
>> ....
>>
>> I didn't show it well in the proposal, but the idea is to be able to
>> click on the names of the modifiers and change them.
>>
>>
>> Again, I don't believe there is any deep problem with the actual
>> modifiers/constraints workflow, I just tried to add in the
>> direction of the points I mentioned above.
>>
>>
>> Cheers!
>>
>> Eclectiel.
>>
>>
>> ----- Original Message ----
>> From: Nathan Vegdahl <cessen at cessen.com>
>> To: The Blender 2.5 TaskForce <bf-taskforce25 at blender.org>
>> Sent: Friday, June 5, 2009 6:57:23 PM
>> Subject: Re: [Bf-taskforce25] Modifier Layout Proposal
>>
>> There's definitely some cool stuff in this mockup, but I have some
>> concerns with it as well.
>> My biggest concern is its heavy reliance on icons without
>> corresponding text.  For me this is two-fold:
>>
>> 1. It is not obvious at-a-glance which modifier is which.  In practice
>> people will only use a few of the modifiers most of the time, so when
>> they need to find one that they don't use as often (and thus don't
>> know the icon) they are forced to hover their mouse over each icon in
>> turn and wait for the tooltip in order to find what they're looking
>> for.  This is even worse for new users who don't have any of the icons
>> memorized.
>>
>> 2. In the stack, custom names are not visible.  I use custom names on
>> modifiers and constraints all the time to help organize and document
>> things, and IMO it is critical to be able to see them at-a-glance in
>> the stack.
>>
>> But having said that, I do think that having compact stack, and
>> selecting items in the stack to see their settings, is an excellent
>> idea.  But I'd rather have a vertical stack with text as well as
>> icons.  And I think in practice you would need extremely large stacks
>> for that to become a space issue.
>>
>> --Nathan V
>>
>> On Fri, Jun 5, 2009 at 5:00 AM, Eclectiel L<eclect25 at yahoo.com> wrote:
>>> Here is a mockup for Modifiers workflow that may also be valid for
>>> Constraints.
>>>
>>> Tried to make a drag-and-drop workflow, eliminate some redundancies, and
>>> seize
>>> as much vertical space as possible for crowded modifiers:
>>> http://img41.imageshack.us/img41/4234/modifiersconstraintswor.png
>>>
>>>
>>> Eclectiel.
>>>
>>> ________________________________
>>> From: Wahooney <wahooney at wahooney.net>
>>> To: The Blender 2.5 TaskForce <bf-taskforce25 at blender.org>
>>> Sent: Monday, May 25, 2009 4:20:11 PM
>>> Subject: [Bf-taskforce25] Modifier Layout Proposal
>>>
>>> Some ideas were kicked about on IRC about a few changes that could be made
>>> to the way the modifier panel works.
>>>
>>> = Keep modifier settings in the modifier panel =
>>>
>>> Thomas added the beginnings of the cloth settings tonight, and although it's
>>> looking cool so far it pointed out a fundamental flaw. You are adding the
>>> modifier in one panel in Blender and you're changing it's settings in
>>> another?! That is quite counter intuitive to a new user and most probably a
>>> break in workflow for experienced users (I'm somewhere in between those
>>> extremes and it's grinding my goat already ;) )
>>>
>>> = Compact the modifier stack =
>>>
>>> The modifier stack can be reduced in total size by quite a bit actually. If
>>> the stack were represented as a list it can take up far less space and it
>>> can allow for a helpful mechanic: The user selects a modifier from the list
>>> and only those settings are shown, saving space and reducing some clutter,
>>> but we can also leverage the current advantage of having multiple modifiers'
>>> settings visible by allowing the user to select multiple modifiers from the
>>> list. The visible modifier's settings can be drawn in the order that they
>>> appear in the stack and that selection can even be locked by the user and
>>> saved into the *NA (DNA,RNA I'm not sure which :P), so a user can set up
>>> their environment to modify a particular object in the way that they need
>>> for the given object, ie. A setup with consecutive SimpleMods and SubSurfs,
>>> chances are if a user were going to animate that object the SubSurfs
>>> probably won't be touched and their settings should probably be hidden.
>>>
>>> Note: I know that a stack item can be collapsed into a smaller size, but
>>> sometimes that's not small enough ;)
>>>
>>> The list that holds the items can also perhaps have drag 'n drop reordering
>>> (allowing the reordering buttons in the current modifier system to take the
>>> boot) and display the Show/Hide buttons for Render/Viewport/Editing/Cage
>>> that currently reside in the modifier settings.
>>>
>>> That's all from me for now.
>>>
>>> Keith.
>>>
>>>
>>> _______________________________________________
>>> Bf-taskforce25 mailing list
>>> Bf-taskforce25 at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>>
>>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
>>
>>
>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>