[Bf-taskforce25] Updated TODO's

[joe]

I think we're going to need to implement several of these ideas, to
evaluate them.  I'd suggest the following ones be prototyped:

* 2d dragging: precision is increased or decreased based on mouse y

* Base precision on the initial click: Precision is based on where you
first click, perhaps graphically shown by lines or something on the
slider, I dunno.

* Precision is based on mouse acceleration.  This sounds potentially
cool, though it might also be too finicky to work.

This way we can know which ideas work, and which do not.  I can see
problems with all three of them myself; 2d dragging is rather
un-obvious and seems iffy to me, the second option might take too much
thinking of where to first click, and the third I imagine would either
work great or be very annoying :)  On the other hand, who knows, maybe
all three work.

Joe

On Mon, Aug 17, 2009 at 12:07 PM, joe<joeedh at gmail.com> wrote:
> This is an interesting idea.  Though it suffers from the non-obvious
> problems it seems all potential solutions do :-/
>
> Joe
>
> On Fri, Aug 14, 2009 at 11:14 AM, Sean Olson<shatter98 at hotmail.com> wrote:
>> I remember reading a proposal either on this mailing list or on BA regarding
>> this.  Just thought I would bring the idea back up because I thought it had
>> some merit.
>>
>> The precision of the slider could be based on the initial click on the
>> slider bar.   The slider bar would be divided into thirds or quadrants.
>> Lets say thirds for the purpose of this example.  If they click the center
>> third of the bar and then drag, the precision would be very tight,
>> incrementing or decrementing by 1, if they click the left or right side of
>> the bar and then slide, then the precision would follow more of the
>> exponential curve.     You could even devide up the bar into more quadrants
>> to have more varied speeds of control.   I think it could work, quickly and
>> be very easy, but the big downside is the same as your vertical mouse
>> movement solution - it is not very transparent to users, and we would have
>> to somehow make UI to explain the functionality.
>>
>> ICQ at 11133295 AIM at shatterstar98 MSN Messenger at shatter98 at hotmail.com
>> Yahoo Y! at the_7th_samuri
>>
>>
>>
>>> From: william at reynish.com
>>> To: bf-taskforce25 at blender.org
>>> Date: Fri, 14 Aug 2009 18:42:27 +0200
>>> Subject: Re: [Bf-taskforce25] Updated TODO's
>>>
>>> Hi All.
>>>
>>> After discussion with Joe on IRC we agreed on using the 2D dragging
>>> approach, where moving the cursor horizontally linearly increases/
>>> decreases the value. Moving the cursor vertically increases/decreases
>>> the sensitivity.
>>>
>>> Cheers,
>>>
>>> -W
>>>
>>>
>>> On 14 Aug, 2009, at 5:31 PM, joe wrote:
>>>
>>> > I disagree. As I said before, I think it's something that can be
>>> > solved. And there's plenty of situations where you need it, where a
>>> > linear step would be even more unusable.
>>> >
>>> > Joe
>>> >
>>> > On Fri, Aug 14, 2009 at 7:35 AM, William
>>> > Reynish<william at reynish.com> wrote:
>>> >> Well, the exponential nature makes them unpredictable to use. Who
>>> >> says
>>> >> you want less precision the further away you are from the original
>>> >> number? This assumption makes dialing in numbers with any accuracy
>>> >> really hard, even impossible. This is especially obvious with
>>> >> translations. Drag a transform location field, and you'll see your
>>> >> object move along slowly, until suddenly it shoots along into the
>>> >> distance.
>>> >>
>>> >> There are a few other possibilities though:
>>> >>
>>> >> 1. Use speed of movement to determine accuracy
>>> >>
>>> >> 2. Use vertical height to determine accuracy
>>> >>
>>> >> These are more predictable by users, because the user input is then
>>> >> constant, and doesn't randomly change over time, causing
>>> >> unpredictable
>>> >> results.
>>> >>
>>> >> First option is also not a 1:1 mapping of movement, bit it's more
>>> >> predictable than having things shoot off exponentially.
>>> >>
>>> >> The second option (suggested by Aligorith in IRC) could work quite
>>> >> well. The idea is that the further up, vertically or the screen, the
>>> >> cursor is, the higher increments the number increases/decreases, and
>>> >> visa versa. But for it to be obvious to the user we'd probably need
>>> >> to
>>> >> add some sort of visual indication. The downside is that you'd have
>>> >> to
>>> >> pay more attention to the direction of your mouse gestures.
>>> >>
>>> >>
>>> >>
>>> >> -W
>>> >>
>>> >>
>>> >> On 14 Aug, 2009, at 3:12 PM, joe wrote:
>>> >>
>>> >>> Numbuts originally were linear; this was really annoying, IMHO. I
>>> >>> think it's be a mistake to revert to that behavior (I find the
>>> >>> exponential version much easier); instead we should make the
>>> >>> exponential more usable; e.g., have it decrease when you move back
>>> >>> to
>>> >>> the original position, maybe have a fixed exponential range (so
>>> >>> after
>>> >>> a certain point it's no longer exponential) etc.
>>> >>>
>>> >>> Joe
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>
>> ________________________________
>> Windows Live™: Keep your life in sync. Check it out.
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
>