[PD] tooltips in pd-extended 0.43

[Jonathan Wilkes]

----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Ivica Ico Bukvic <ico at vt.edu>
> Cc: 'Jonathan Wilkes' <jancsika at yahoo.com>; 'pd-list List' <pd-list at iem.at>
> Sent: Wednesday, March 7, 2012 12:08 AM
> Subject: Re: [PD] tooltips in pd-extended 0.43
> 
> 
> On Mar 6, 2012, at 9:04 PM, Ivica Ico Bukvic wrote:
> 
>>>  I think that we should be pushing GUI stuff to the Tcl side of things 
> as
>>>  much as possible, plus I prefer the current tooltip display down on the
>>>  lower right.  I find that popups right next to the mouse are often 
> annoying.
>> 
>>  I agree, except I don't want to push this notion to the point where 
> unpredictable nature of tcl/tk's canvas implementation entirely hampers or 
> limits tool's productivity and provides a half-baked feature. E.g. it's 
> impossible to highlight nlets or show tooltips when trying to patch a cord 
> because tcl/tk's canvas keeps "current" tag on the object that was 
> last clicked on, and yet arguably this is where a new user needs tooltips the 
> most. Selection of nlets and their detection is finicky at best, is very 
> unforgiving (you really need to nail that pixel on the screen to get it), and 
> the list goes on.
>> 
>>  Also, the status bar tooltips are really not very intuitive and from the 
> HCI perspective represent a considerable increase in cognitive load over text 
> bubbles because one's eyes have to move at times relatively far from the 
> point with which the tooltip is associated (heck, it is not even that obvious to 
> which object it belongs to if there are two objects located near the cursor). 
> Even a long arrow from an object to a status bar tooltip can cause a 
> considerably higher cognitive load than a co-located tooltip. There is a reason 
> why co-located tooltips exist even in browsers in addition to the somewhat 
> arcane status bar model.
>> 
>>  The only context where I see the status bar approach as the optimal way to 
> display tooltips is when the tooltip emanates from a manual invocation that 
> Jonathan pointed out earlier where it makes perfect sense to post it in one 
> uniform place that is not dependent on the mouse position and thus potentially 
> misleading.
> 
> Even better, off load this to a GUI plugin, then people can choose the method 
> that works best for them.  But I still like Jonathan's original 
> implementation the best.
> 
> I find that the slightly increased load of moving my eyes down to the lower left 
> corner a worthy sacrifice for not being interrupted by a popup bubble.  
> Interruptions also increase cognitive load, and should be reserved for things 
> that are the most important.
> 
> Most of the time, most users will not need the popup describing the inlet, so 
> most of the time it'll just be an interruption.

This is a tough problem because the user experience of creating a patch is a lot 
more like a paint program than it is a code editor.  And in paint programs like 
Gimp there are no tooltips on the canvas, where the user must 
always be able to see as much of the image as possible without distraction.

There are, however, tooltips on the static toolbars, where they are much appreciated 
since Gimp relies so much on icons.  In that vein maybe there should be some way 
to have "Run mode" tooltips for GUI objects.  There I think it would make a lot more 
sense to implement them as some of the original tooltip patches do, where you can
define a "tip" method for that particular class that lets the user specify what should be 
displayed (e.g., "Volume", "Reset", "Toggle Syrup").

-Jonathan

> 
> .hc
> 
> 
> ----------------------------------------------------------------------------
> 
> Mistrust authority - promote decentralization.  - the hacker ethic
>