----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Ivica Ico Bukvic ico@vt.edu Cc: 'Jonathan Wilkes' jancsika@yahoo.com; 'pd-list List' pd-list@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