I find tooltips very helpful and I think everybody arguing they are not needed on a good UI design thinks very limited.
Just to give you some idea ...
Generally a good UI design (as a lot of other things in life) is one that is effective and efficient over a certain period of usage time.
Effective means, you can do what you expect you could do (e.g. making a call with a mobile). Efficient means, it is doable with minimal user effort (e.g. just typing the numbers and pushin some "dial" button, not having to navigate through some menus first). Over a certain period of time means, that it may not be optimal on first usage or, the other way around, after you got to know it and everything in between (e.g. an airport terminal screen maybe needs to be more focused on one-time-user "dummies" than a video editing software for professionals like Adobe Premiere).
This said I find tooltips extremly helpful in situations, where
- as a designer you do not want/cannot explain every detail about some GUI functionality within some given UI area
- due to usability, available overall space etc.
- e.g. taking the above examples it may be helpful even on a simple mobile call scenario for elderly people.
- That may be not familiar with a lot of things we "freaks" ;-) find trivial.
- And they should be encouraged to click around without the fear to accidentially call some shopping hotline and beeing finally convinced that they cannot live without the 1000 EUR vacuum cleaner.
- so in this case a one-click tooltip paradigm could make sense
- generally I wouldn't recommend it though
- as a user you are not sure about the meaning of some provided action/button etc.
- again sticking to the previous examples, even an experienced Adobe Premiere user may not remember all the details about a certain functional area of all the available modules/plugins
- e.g. if most of the time you cut videos and seldomly adjust audio settings
- whereas others may have the problem vice versa
Now back to the limitations and possibilities of a touch interface...
- :-) Hover: I recently saw somewhere, that some devices can recognize the finger before it actually touches the touchpad or it differentiates between the touch intensity (e.g. only very soft touch). This would seem the perfect pendant to the established tooltip functionality on WIMP interfaces to me
- of course it would be dependent on the touch hardware capabilities
- :-) Zooming UI: I actually like the Zooming UI concept mentioned by Joey as well
- the concept of using only two fingers is already quite common for zooming and the idea is quite intuitive, e.g. showing more details, like typical tooltip infos, on zooming on a button
- but it admittedly introduces the problem of differentiating between I like to have a tooltip for this button and I like to zoom the whole area in/out, not having the button tooltip near my fingers in mind
- although I would think that typical tooltip-enabled areas are quite different from zoomable areas in general
- e.g. some PDF readers content area is generally visually quite separated from e.g. some toolbar (button)
- tooltips for non-action areas, like some text area are again not trivial to handle or would require some more "gesture differentiation agreement"
- from the development perspective it seems also quite robust
- :-) QM: the question mark click or drag'n drop feature solution could be a good alternative too
- having a lot of these everywhere on the screen seems stupid, especially when they have to aquire a certain space to be clickable/draggable
- having one to drag everywhere seems better, but again would require the space for it on the screen
- from a development perspective I would find it at least a little difficult as a general solution because the drag'n drop is a common feature and differentiating in a UI between here comes some tooltip drop I have to handle and here comes some file drop I have to handle (e.g. on a file upload area) may not be easy or at least common ground to existing frameworks
- :-| Hold: the idea to trigger the tooltip if the user does not release the push after a certain period of time, e.g. 1s, seems to be a 2nd best solution to me
- it is already a common feature in some scenarios, as the mentioned on-screen keyboard popups (e.g. resting on an "o" and getting a list of choosable alternatives like oóòô)
- again it requires some trust from the user, that it won't execute the areas action on the release
- on some buttons it may be difficult to differentiate what the user wants to do, e.g. clicking on a "+" sign/button to increase some number and holding it down to increase more or faster may contradict this tooltip functionality
- for non-action areas a push-hold action may not seem intuitive
- from a development perspective it could be rather easy although some behaviour contradictions like mentioned may exist
- :-| SCT/DCA: the solution single-click showing tooltip, double-click executing action I could imagine to be useful in limited scenarios
- e.g. the mobile call for some elderly or dummy people mentioned above or where the action should be kind of protected from unconcious or unsure usage
- again the development perspective looks robust again here
- :-/ SCA/DCT: the solution single-click executes action, double-click shows tooltip seems very strange to me
- if you are not sure about some functionality you would hesitate to click a button at all, and surely not twice, especially if you cannot be sure if you can expect this behaviour
- the development perspective could be problematic here:
- after which time is a double-click two single-clicks?
- what if the second click is not recognized or cannot be recognized, e.g. because some other popup comes up, the UI layout changes suddenly, the user did not carefully aim, ...
- :-/ Other Gestures: using other gestures mentioned or I could think of, like drawing a question mark over the to-be-tooltipped-area, swiping over the area in some way etc.
- because this seems no common ground I wouldn't like it because it also may block other functionality otherwise available