the tooltip I deleted

Tuesday night, around 10pm. i was adding a small new feature to one of the plugins, a behavior i thought would help producers in a specific edge case. when i tested it, the existing knob the new feature attached to felt unclear. so i did what felt obvious: added a tooltip. one sentence, hovers on mouse-over, explains what changes when you turn the knob and what to listen for. shipped to the test build, sent the link to two beta testers, went to bed.

Wednesday morning i opened the build, looked at the panel, and deleted the tooltip. then i deleted the knob. then i deleted the new feature.

the frame

KERN’s brand law #4: if a label needs a tooltip, it failed. the tooltip is the symptom. the knob is what’s broken. when i found myself reaching for a tooltip Tuesday night, i had walked into a design failure and tried to paper over it instead of fixing it. fixing it meant going back further than i wanted to.

a tooltip is the developer admitting the user cannot predict the knob’s behavior. predict is the operative word. if the producer can’t guess what happens when they turn the knob 30% clockwise on a vocal, they can’t use the knob, they can only push it and see. push-and-see is exploration, not control. it is the right mode for a synth. it’s the wrong mode for a mix tool that has to give the same result on the second mix the producer reaches for it. tools are reusable; results are not.

before: a knob that did two things and a tooltip explaining which combination of conditions triggered which. after: no knob, no tooltip, the two behaviors split into a default that just works and a hidden right-click setting for the rare case. the panel got smaller and clearer in the same edit.

three options when you reach for a tooltip

every time you find yourself adding a tooltip, as a developer, but also as the producer reading one, there are three real options, in order of how often each one is the right call.

rename the knob. about half the time, the knob name was the wrong noun. “amount” can mean intensity or wet/dry or input drive depending on what you assumed. picking a more specific name removes the need for the tooltip without removing the feature.

cut the knob. another quarter of the time, the knob is doing a job nobody is reaching for. the tooltip is the developer convincing themselves to keep a feature they should have cut. the test is the same one i wrote about two weeks ago: would removing this control cause a real workflow problem? if not, it’s decoration that costs decision time on every session for every user.

redesign the underlying behavior. the rest of the time, the behavior itself is doing two things at once and a single knob can’t represent both. the tooltip is patching over an architectural mistake one layer deeper. that is the case i hit Tuesday night. the knob was reasonable; the behavior the knob controlled was not. fixing it meant redesigning the feature, which meant cutting it for now and shipping a smaller, clearer version.

(option 4 exists: keep the tooltip. the cost shows up later, in support emails and confused beta testers, and the cost is paid by every user every session. i have stopped picking option 4.)

what this changes

next time you load a plugin that has a tooltip on a knob, ask: which of the three options would the developer have picked if they had run the test? then run the test on your own settings, there is probably one knob in your default chain that you keep turning past without thinking about. cut it from the preset.

from the studio

short studio update this week: the Field Notes archive is at three issues now and the early reply rate is honest. the “what knobs do you ignore” question from issue 1 generated a usable list, half a dozen of those become future Sound Science pieces.

what is a knob a developer should have cut from a plugin you have used for years? reply, name names, no diplomacy required.

jonas