xparq / MuLab

MuLab Collab. (e.g. for issue tracking)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add visual cues (e.g. hover-highlighting) to click- (or drag-/drop-) sensitive areas

xparq opened this issue · comments

commented

The most prominent example is the track "headers", which have at least four separate areas with distinct functionality, both in terms of click, double-click, right-click, and drag-and-drop (but not the same way: e.g. some have different dbl-click actions, but share same right-click menus), all that with insufficient (or, in case of drag/drop: no) visual indication of when and which area/function is being engaged. E.g. even the tooltips are the same for each area, further blurring the most important perceptional feedback (hover) instead of emphasizing important differences. OTOH, functions like "Rename" is available via at least 3 different and visually distinct ways there, further increasing the risk of confusion.

(Note: although the icon, the label and the empty space do look different and distinct, but they look static, so their appearance neither does imply the availability of input functionality, let alone all that many different ones, nor does it provide clues about the differences between them.)

Triggering different functions on actions like click, right-click, double-click, hover, drag/drop etc. depending solely on different pointer positions over static graphics (like a label, or a small, static icon, in some homogeneous empty space), also within a usually dense area, is highly unexpected to people used to common UI practices. Surprising, unusual behavior like that reduces confidence in controlling the UI, and thus takes considerable extra (and unnecessary, i.e. avoidable) effort to learn all those subtleties. It's also likely to cause some frustrating hit-and-miss results for beginners in the trial-and-error phase (i.e. during the trial period, before deciding on a purchase).

Todo:

  • As a minimum, different tooltips revealing the individual input objects/handles could be the quickest workaround.

  • Giving feedback via some kind of hover-highlighting to indicate that the given areas, despite looking completely static, are actually sensitive (input) widgets.

  • Optionally, some graphical clues could also be provided already on the static level (e.g. some "etching" around, and/or more coloring to the icon, also perhaps a subtle border around, or underlining of the track name etc.).