Re: [Traverso-devel] keymap.xml patch

[Remon]

Hi,

> > Heh, now I thought the cvs version has improved a lot compared to the
> > last release (0.30.0), but I agree that it's confusing that clicking on
> > 'buttons' and other objects doesn't do much !
>
> I agree that current cvs is way improved over 0.30 !  I think that one
> of the largest improvements is that in cvs, traverso is beginning to
> allow users to interact with objects using the mouse buttons.  Having
> the right button pop up a context menu is great.  And having the left
> button drag clips is great too.  It's exactly these kinds of recent
> improvements that I think should be expanded upon.  :)

Indeed!
One of the issues was that a lot of work had to be done to make things 
flexible and configurable purely by using the keymap file!
Only recently full mouse support has been added to the InputEngine, so it's 
mostly a matter about updating the keymap file to get more actions available 
for the mouse!

> So... in my day job, I work as a user interface designer, and some of
> the things we're constantly looking for are ways to help make
> applications just work the way people expect them to, as opposed to
> making the user fight the app, or adjust to the way the application
> wants them to work.  

Cool!
Are you subscribed by any chance to IxDA ? Just curious :)

Must be kinda hard job btw. Many people are used to the 'defacto' standard of 
using GUI's, whatever that means though.
Now, what me attracted in the first place to this program was the rather ease 
of use, not exactly what I expected, but things appeared to be logical.
Like arming a track was using the A key on a Track, and the track got armed. 
Next hitting the spacebar, and there you go, recording just by hitting 2 
keys ! Unknown for any 'linux audio recording program' before!! (and I'm not 
kidding)

What I continuously try to do is looking from it from a user point of view, 
what would I think the application would do when  I do something, but on the 
other hand, not getting distracted by the 'defacto' that is supposed to 
be 'good' but in fact hinders the workflow a lot.

So the question really is,  what is it that a user expect to happen, and is it 
a good thing to happen ?
I've said this before, I'm not a coder really, but a user, and I want it to 
work my way!
But my way could be totally different to what other users find working 'their 
way', so .....

> I also believe that a gui app that requires the 
> user to read a manual in order to even begin using it, will definitely
> push a lot of users away.

Yeah, you have a point there. The other side is that if you give the users a 
chance to start using the application _without_ requiring them to really 
start _understanding_ what the application is about....
I see it many times, people install very powerfull software, but give up 
soon "it doesn't do what I want it to do", but the real problem is, they 
don't have a clue what they are doing!
Like photo retouching, it's a complicated matter, not something you learn from 
clicking some buttons and menus, you need to study the matter ;-)

> I totally understand the desire to get people doing things "the right
> way" from the beginning, but I really feel that forcing users to do
> things the way you think is best, instead of just trying to do what
> the user wants, can only backfire on the project.  :(

Yes yes.... 
One of the problems is the background of the program, it started out way to 
much focused on the contextual interface, which, although very powerfull was 
not friendly to get started with.
I tried to solve this, and huge progress has been made, but sometimes I indeed 
fall into the 'trap' that "using this or that way is so much more powerfull 
and easier" might not be as easy as it sounds for first user experiences....

> I think that current cvs is moving in the right direction by allowing
> use of the mouse buttons to do basic things, and I love how this kind
> of "beginner" interface can be added without hurting expert users at
> all.
>
> And yes, the InputEngine's flexibility is really cool!  It's been fun
> and easy to tweak the keymap to start making it work the way I wanted
> it to work.  :)

:-)

(Some real cool hacks in there to make that happen ... lol)

> > But nothing prevents you to use a different way to delete clips, it most
> > likely is just as simple as adding another entry in the keymap file ! (or
> > in combination with a simple new Command class)
>
> Oh, okay.  I couldn't figure out how to delete clips.  I was going to
> ask about that later.  :)  But since you bring it up, I was thinking
> that there should probably be a way to delete a clip in a similar way
> to deleting a curve node, track mark, or track.  (as a command
> performed on the clip itself... maybe also mapped to <<R>> for
> consistency?)

Hmm, doesn't it show up in the context menu for the audioclip ??

I've been thinking about this too btw, << R >> on a clip to remove it seems 
logicall. I'll see if I can make that work, or better, please file a bug 
report for this (marked as wish), so I don't forget about it.
Previously, this was not possible, but it is now, as you can see with removing 
a track.
Should << R >> on a clip remove that clip, or all clips in the selection (if 
the pointed clip is selected ?)

> But back to selections and grouping, I agree that selecting a bunch of
> tracks and then moving one of them should move them all.  I wonder if
> that concept could be abstracted out so that if you perform a drag
> action on a clip that is part of a selection, all selected clips are
> affected in the same way?  Edge drags, gain adjustments, etc...  That
> probably only makes sense for some of the commands...

Something that needs investigation. Selection on clips is done by the 
assumption that it is always done on a list of clips. Using this technique 
could equally work well with moving clips.
But perhaps, it should be implemented seperately by a move selection, set 
selection edge commands, etc...


> > And voila, dragging the edge works for the mousebutton too.... But oops,
> > dragging the clip with the mousebutton no longer works.....
> > So, I would suggest to use [ D ] (Drag) for that now, or perhaps [ E ] (
> > Edge ) is still easier ?  :D
> >
> :) I guess what I was thinking was that it would be cool to have the
>
> mouse work such that starting a drag from within a few pixels of the
> edge of a clip would drag the edge, but a drag that started from the
> middle of a clip would drag the clip.
>
> I was thinking that maybe AudioClipViews could have invisible child
> views (AudioClipEdgeViews?) at each edge that were just a few pixels
> wide, and that could receive events directed at them...  This would
> allow for even greater UI flexibility.  :)

Dispatching events from the InputEngine to objects by means of calling a 
function is rather limited in functionality.
Using the plugin framework allows you to supply a list of arguments to the 
Command that is called. This for example could be used to implement this very 
feature!

> I also though a similar approach might work to allow the things that
> look like buttons and sliders in the Track headers to be usable by
> beginners.

Indeed!
I would love to accept Command classes that do just that :-)

> And then to teach people the right/advanced/un-guessable way to do the
> same thing, we could have tooltips and status bar messages while
> hovering over a pseudo-button or -slider, that tell people how to use
> the advanced input method for adjusting the relevant property.
>
> I'm worried about the current usability of the items in the Track
> Header, since I think they currently seem like door knobs that don't
> open the door, or a switch on a lamp that doesn't actually turn it on.

ROFL

Lovely analogy!

It's indeed something that is confusing...

I recently started to add more tooltips, and re-enabling the 'information 
widget' that spits out usefull information on succes/failure.

>
>  :P  The way they look invites users to click on them, so I think we
>
> should acknowledge their interaction attempts, and try to do the right
> thing if we can.
>
> Thanks for listening to my ramblings!

You're mostly welcome!

Greetings,

Remon