This tip is not strictly D related, but rather about UI design: I recommend you avoid toolips.
Why? The short version is that they're just awkward to use.
It often isn't obvious that tooltips are there at all. UI designers can mitigate this by consistently using the dotted underline, maybe an ellipsis, or an indicator icon though.
Even when the user knows a tooltip is around, it takes some excessive effort to trigger - it requires a mouse to trigger at all; no keyboard or touch screen compatibility, and you must move the mouse and then pause (which might mean taking your hand off the mouse so you don't shake it). This is slightly annoying for checking one thing, and quite painful for checking multiple things, putting a minimum time on each interaction (assuming it works, which if it is buggy is hard to tell with the delay). Any information the user wants to see in a tooltip is thus difficult to access. Adjusting the delay can mitigate this but then has other trade offs with accidental triggering.
Accidental triggering of the tooltip might be the most annoying aspect, since moving the mouse or parking it might trigger something, which then covers up what you're actually trying to get to or look at on the other side!
You might be able to mitigate the popup covering content by making it disappear easily on future movement, but then you can't select text in the tip to copy/paste since if you move the mouse, it disappears! Each solution brings a new problem.
If you must put data on some kind of popup, I suggest making it both pop up and dismiss on explicit clicks instead of on mouse movement or hovering. Clickable things can be triggered on touch or keyboard but are not likely to be accidentally triggered, and dismissing it on click also gives the user a chance to interact with it and ensures it won't accidentally disappear if they wiggle the mouse too far. No timers hacks required.
Here's some alternatives to consider instead of tooltips:
, just show "2025-02-27 (Yesterday)". Instead of a tooltip label on an icon, show the icon and the text together. All the info is there at-a-glance. This can be subject to space restrictions, but also means it is easier to review in a long list. You might also show the information through other channels, such as an icon, perhaps paired with a different color for recent vs old events; these things quickly become rough estimates anyway "about 2 months ago" might mean anywhere from 6-10 weeks depending on the implementation, so a recency/ancient signifier may convey the same meaning. (just remember not all users can see all colors and poor contrast is just frustrating when you are trying to read something, so i probably wouldn't grey out old dates)
* put the information on a toggle, such as a "View" menu to change sorting, details displayed, etc. for everything at once
* put the information in a dedicated area. you might have a details pane, or a status bar, or similar area, always visible, never obscuring anything else, that shows this and other information (with the additional space, you might show the time in different time zones, for example. "2025-02-27 17:00Z / yesterday / 1pm local time for editing user / 4pm for you / 5pm in office" you're no longer limited to a small tooltip window so you're free to explore other useful options). I'd recommend this dedicated area be changed on mouseover events, but not be cleared on mouse leave events in most situations, so users can refer to it or maybe even go over and copy/paste out of it without it disappearing as they approach.
Remember, one of the benefits of tooltips is their proximity to the user's attention focus, so if you use a dedicated area, make sure they can notice it somehow, either by still keeping it nearby or by using it so commonly that the user is trained to expect more information there. )
And remember, if you do use a tooltip, I strongly recommend you put it on click/touch/keyboard activation and dismissal instead of based on mouse hovering and movement. (BTW even if you do put it on hover, it should also be available on these events for users without a mouse anyway, so you ought to be doing this regardless)
On a related note, I've been thinking about the window status bar a bit more lately, trying to enhance and standardize both ui and api.
A window status bar is a fixed part of a window, typically in the bottom, dedicated to displaying various messages. It is broken up into one or more parts, each with a particular job. It is frequently updated, including on mouse motion, to display details about what is under the cursor, cursor location, alerts or other background notifications, and other status flags that might be relevant. One could argue that the system taskbar incorporates elements of a status bar with its clock and notification area.
Go to https://jspaint.app/ for a nice live demo - it is a pretty faithful recreation of the Windows 95 Microsoft Paint program, including its original status bar. Notice how it shows a generic help message by default, but as you mouse over many of the tools on the left, it will display a description of what they are (which is in addition to a tooltip on hover, which shows just the name of the tool) and as you move over the canvas area, the second zone of the status bar shows your current pixel coordinates. The third zone shows the size, in pixels, of any rectangular selection you make. (I would add even more info there, such as rgb values of colors, but still, you get the idea.)
Windows Notepad uses its status bar to show caret location, zoom level, line ending, and file encoding too, showing some more "status"y information.
Application status bars have fallen a bit out of style in recent years, and I'm not really sure why. So much of UI style isn't about usability gains or technical limitations, but rather just following trends set by a leader (and let's not kid ourselves, most everybody follows what Apple, Inc. does, even if it leads them right off a cliff). It is true that sometimes vertical space is limited, like on a small 1366x768 laptop - but vertical space was also limited in the 640x480 or maybe 800x600 days on Windows 95, so that can't explain it alone. On phone screens, or on smaller windows, you might not have the horizontal space to display much text but... again, there's enough if want to, and even if you compress when space is limited, that's not a reason to still not show it when space is abundant.
Microsoft has several points of guidance in when NOT to use them at this reference: https://learn.microsoft.com/en-us/windows/win32/uxguide/ctrl-status-bars
Some paraphrased and summarized points I'd like to discuss from that:
A lot of their advice is good. A status bar is a kind of ... regional widget. It isn't local - it doesn't appear right where the user's attention is, but it also isn't global, it is tied to the application. It is for information you want available when wanted, but not in the way when it isn't.
Regardless of the reasons and history, I still see value in them as well as some untapped potential. I'd like to make some standard integrations with things like logging and notifications, perhaps the clipboard too. Didn't we just say logging and notifications aren't appropriate for a taskbar though, since they change frequently and require attention? Well, it depends on the details of how you do it.
On my desktop, there's a global status bar, which shows (among other things), a combined feed of notifications from various applications. If I get an email, it updates there. A chat message, there. A program completes its operation, it is there. The first bit of details appear in the status line and the window requestion attention shows an indicator on the taskbar. This way, I can glance at it if I want to, and if I don't want to right now, it is far enough out of the way to not be a major interruption. I can even pull history by mouse wheeling over it if I want to. I'm pretty happy with it.
I'd suggest doing logs and notifications in application similarly: a dedicated place for a combined feed. Depending on how much detail is already visible in the window, the status bar might just indicate there is something or it might show some of that info directly. It can also bubble up the information to the top level of the desktop, if appropriate for the message and for the user's environment. For a log indicator, instead of showing a constant feed, it might just show if there is something available since last check at the given log level or filter.
Small update and some thoughts on tooltips in ui design.