Modifiers

Modifiers.  I have a love-hate relationship with modifiers.  On the one hand, they allow instant access to a lot of functionality in a way that’s easy to manipulate with your non-dominant hand.  On the other hand, they have, in the past, hidden useful functionality in ways that are almost impossible to discover.  This was exasperated with the introduction of Tablet PCs, and their complete lack of useful non-dominant hand input buttons or other devices (which is a very annoying shortcoming of Tablet PCs – c’mon, I may not be able to control a second mouse or whatever with my left hand, but for gosh sakes I can push a darned button!).


In some ways, they are a necessary evil – we’ve already essentially used the entire keyboard for shortcuts, the menu system is already complicated enough without being overloaded with more command variants, and while we’ve been on a general kick to make sure all previously hidden modifier only behavior is exposed in the UI somewhere, if you’re really in a groove you don’t want to have to track your mouse all the way over to the options bar just to add a chunk onto a selection.  Pointer locality is an important part of usability (even if we do sometimes fall short – a subject for later).  Heck, I’ve always meant to either find or implement some sort of floating window modifier substitute widget in my copious free time.


We’re in such desperate straights for additional modifier keys that we treat the space bar as one (which has caused more than one funky issue in the past, with keyboard and locale switching).  I’ve joked in the past that we need Emacs style prefix keys, but I really was only joking, as nobody would get those.  It doesn’t help that when you’re trying to squeak in a feature at the 11th hour, and it’s already too late to modify the documentation, that attaching behavior to a modifier doesn’t make a liar out of the screen shots.  But it also doesn’t make for a discoverable feature.


We have tried to fix this in general by exposing what was modifier behavior only in the user interface – particularly in the options bar.  We’ve also tried to rectify this a little bit for the Macintosh folks by adding the tool hint text to the Info palette in Photoshop CS2.  Windows users will recognize that this is the same text that was in the status bar previously (there were other reasons for getting rid of the status bar, plus I’m a stickler for trying to maintain platform parity).  Unfortunately, the Info palette is underneath the Navigator palette by default.  So, bring that Info palette to the front (the tool hint text is enabled by default – check out the Info palette options from the palette flyout menu for more stuff) and watch the tool hint text while you use different tools.


Yes, of course that doesn’t explain everything.  Like it misses explaining what hitting a modifier before the first mouse click with one of the lasso tools does (it is different than what happens with the modifiers after the first click with one of the lasso tools).  In that case, the cursor should give some hint of what will happen.


It also doesn’t help when you’re not trying to do something with a tool.  Like with the Option/Alt key in most dialogs (hint: watch the button labels).  Or in Photoshop 6, 7 and CS, holding the shift key while modifying a linked type layer will operate on all of the type layers (in Photoshop CS2, you can just multi-select the type layers).


Now, most if this is documented in the manual I’m sure you’ve read (nudge, nudge, wink, wink).  But there’s always the undocumented ones, too, like holding the shift key on Windows when dragging the Photoshop CS2 application window (I’m going to make you try it instead of describing it – and no, it’s not perfect, but it really helps in multi-monitor situations).


Remember, nothing goes boom when you press a modifier.  And there are times when us engineers really want to put in useful functionality when it’s too late to modify the UI.  So don’t forget to give your local friendly modifiers a try.


-Scott