Steps to reproduce: 1. Open StartCenter in 4.2.0.1 or newer 2. Hover over recent documents displayed in startcenter Current behavior: The tooltip with the file URL instantly shows up for the document hovered over. This destroys the otherwise nice and clean UI of the startcenter. Tooltips vary in length etc. It just doesn't look good. Expected behavior: I doubt many users do need the file URL. I suggest delaying the display of the tooltips around 3 seconds. If you really need the file URL it's fair to wait that short amount of time. For the rest and majority of the users that then means a much better UX when working with the startcenter. Talked to cloph about this in IRC and he said maybe that time is taken from the system since it matches the delay in gnome apps. I myself am using OSX here. Operating System: Mac OS X Version: 4.2.0.1 rc
Maybe uncoupling display of tooltips in LO and display of tooltips displayed in startcenter would be a solution? I like tooltips in LO, I hate them in startcenter. Currenty if I disable them they are competely gone. Not sure what a good way to deal with this is. Just had an interesting discussion with jmadero. He argued that many people with a naming scheme that allows for files with identical names are dependent on the file URL tooltips. Maybe if those would be displayed permanently below the file (where thers still is tons of white unused space) would make for a calmer UI and solve the issue?
LO doesn't use GTK timeout settings, but just happens to be that LO's default is the same (or very similar) to the 500ms that is default in GTK http://opengrok.libreoffice.org/xref/core/vcl/source/app/settings.cxx#1246 I guess that's where it is hardcoded.
If anybody knows who from UX to ping about this, would be great to get some feedback on this, please add them to cc:
LibreOffice should exactly match the timeout of the platform it’s running on. Immediate tooltips are annoying, and too-delayed ones aren’t useful. If this timing can’t be matched, I suggest using a default value of 1.5 seconds.
I disagree in the case of the recent files area in the StartCenter. Indeed tooltip is the only way to get the full path of a recent file. User will want an instant answer from the UI. So I prefer the current behavior. Best regards. JBF
NOTABUG. This is just working as expected. If users do use tooltips, they likely want them to behave the standard way. Anybody annoyed by tooltips will likely disable them.
I happened across this annoying behaviour a few days back and felt the delay should be longer than it currently is, as i see no delay when moving from one file to the next. (In reply to foss from comment #6) > Anybody annoyed by tooltips will likely disable them. Most users dont change the default settings in LO, so even if they are annoyed with it, they are not likely to change it. Also if they disable it in Tools > Options > General, that disables it in the start center as well, where it is quite needed.
REOPENING. V Stuart: Thoughts? If UX / Design agree on this, would be great to adjust the default for this specific location in LO.
(In reply to foss from comment #8) > REOPENING. > > V Stuart: Thoughts? > > If UX / Design agree on this, would be great to adjust the default for this > specific location in LO. Actually, I think the timing is about correct -- there is a noticeable pause at each UI action: 1) mouse over, 2) object focus, 3) tool-tip pop-up. But, assume it would be trivial to put a delay in at any of those UI actions. Although I don't really see it as improving the UX. However, we are missing tool-tip pop-up for keyboard navigation, only the file name is exposed to AT, no way to obtain path--an a11y issue. But, the timing in that regard would not have to change. Setting NEW and back to UX-advise for any Hangout decision. But, I'll recommend for Resolved Wontfix unless a developer has spare cycles and really wants to poke at this. Perhaps in the context of doing the mouse over module filtering enhancement of bug 80934#c3--mouse-over timings and GUI refresh would become significant to UX at that point. Another aspect that would be nice, if this is refactored, would be to make the tool-tip path available to copy/paste--but that is a different issue.
> If UX / Design agree on this, would be great to adjust the default for this > specific location in LO. UX feedback was already given to this bug in comment 4. Do we need to discuss that further?
Let's evaluate if 1,5s are possible. If easily doable could be a nice improvement. If this required tons of work > Wontfix. TBD on next design meeting (today?).
Let's close as worksforme