Thanks Dan.
Well, I hope the fact that I'm exposed to students on a daily basis, since 2000 helps my understanding of what results intuitive and what not. I've found for example that floating windows were always a problem with new students, a few years back. They constantly (and inadvertently) moved them partially beyond the screen limits and then say things such as: "I don't have that option in my program". Obviously that option was out of screen. :)
When Adobe changed the interface to docked panels (in CS2) that problem completely disapeared. I instantly knew that was a good change!

With this widget I've always had a good experience. Is all I can say.

But it's interesting to know that this kind of widget was not really designed by Adobe, but by CoSA, the company that created After Effects, in 1993, then the company was absorbed by Aldus, which in turn was absorbed by Adobe.
http://aeportal.blogspot.com/2009/08/after-effects-1-interface.html
Then, many years (5 or so) later, Adobe started incorporating this kind of widget into its other products. So let me take this as a sign that marks it wasn't really a rushed decision, but one moved by proven facts.
This of course wouldn't be a proof of anything, if the widget wouldn't have provided a great performance, but I my experience it did!

Also, over the years there have been many solution for that same problem. I expose some of them here:
3ds Max has its spinners, and they are good! Specially as they alow to drag infinitely past the screen border, and they allow to reset it's value with just one click of the mouse.
Lightwave has its mini sliders and they are good! Specially they allow to drag color channel values individually, or right click drag to change luminosity of the color.
Maya has a virtual slider system in the ChannelBox (only) and it's not completely good. It has its pros (slide several parameters simultaneously), but it's cons too (not available everywhere, more clicks to use it tan other systems). It also have an invisible way of dragging values by pressing Ctrl and dragging in any value input box (each mouse button changing the speed of change), but usualy the cursor gets "trapped" inside the input box after dragging turning the solution really bad. This used to work really well, untill they switched the interface to Qt in the last release. I presume they will fix this perhaps in a later release.
Photoshop has it's sliders too (sliding over the parameter name, not the value) and they are good. But if you manually enter a value, then the cursor will always get trapped inside the input box until you click in other part of the interface.
Combustion has its sliders and are good, but take much space and clutter the interface (not so different to some ideas proposed here, with rectangles enclosing parameter values). Also, they are sometimes hard to use, because they require you to double click to enter a value directly.


But I think After Effects widgets are the best of them all.
If I had to resume why, Id say because:
They are small: That way actual working or viewing space gains importance in the interface against space devoted to parameters and other technical things.
They are light. Visually they do not call the user attention all the time. But when the user needs them they are fully functional and its reduced footprint allows to see more parameters in less space.
They are flexible: The user can slide visually if he/she wants it to (by expanding the widget to a visual slider or rotation knob).
They are intuitive: Users quickly discover how to use them, and they like it. That's my subjective experience in class, of course.
They are easy and precise. Inserting a value manualy is just a click away, for the times you want to get precise. (Believe it or not more users than one would think have problems with double clicking!!)
They are safe: The cursor never gets trapped inside the input box, like in Photohsop, 3ds Max, Maya or many many other programs' value widgets. This is perhaps the most irritating and confusing fact happening in so many programs, and sometimes users just don't understand what's really happening when they face it. They just think the program is "not working well".

I don't say it's something that can't be perfected, I just say it's really efficient and it works.
So taking it as a basis for our program can't be a bad choice.

P.S. regarding honesty. just look for me here:  :)

Regards,
Gabriel




2011/2/8 Dan Dennedy <dan@dennedy.org>
2011/2/8 Gabriel Gazzán <gabcorreo@gmail.com>:
> After Effects way of showing parameters is the best and most productive way
> of handling parameter values and presentation I've seen so far. (I've used a
> lot of graphics related programs out there to a great extent and my
> conclusion favors the After Effects way. I'm certified instructor of 3ds
> Max, Maya, After Effects and Premiere, I've used Lightwave, Photohsop, GIMP,
> Krita, I'm here since the Amiga days and expecienced many many kind of
> programs all these years.)
> This is not to say you can't have a different (and better) opinion than me,
> but just to say that I've really experienced what I'm sustaining here as a
> good option, and why I know it really workes well.

I think Gabriel's background is very good to have available - assuming
honesty ;-). With that said, Gabriel, I ask you to also consider the
intermediate user base and not just power-user. Maybe you are, but is
what you are suggesting fairly obvious and visually consistent with
the KDE/Qt widget designs? I am not claiming your suggestions are not;
I have done enough recent analysis of the proposals, but I know for
example, that dashed underlines under editable values are fairly
obvious but not consistent whereas sunken boxes are both obvious and
consistent, if somewhat heavy.

--
+-DRD-+

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Kdenlive-devel mailing list
Kdenlive-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kdenlive-devel