Created attachment 184413 [details] video demo showing emphasis of the entry the mouse pointer is over in navigator content tree Please see the attached demo that shows emphasis of the entry that the mouse pointer is over in the Writer Navigator content tree. Thoughts appreciated.
(In reply to Jim Raykowski from comment #0) > Thoughts appreciated. Kudos for continuing to think about improving Navigator. Some random thoughts... 1. Is it possible to put a delay before the bolding appears? Reason: I suspect it will be irritating/distracting to have what, in effect, would be a constant blinking when moving the cursor in Navigator. It would be nice to be able to scroll up and down (e.g., between "headings" and "bookmarks", etc.) without the blinking, but when the mouse slows down and starts to "rest" somewhere, then it would be meaningful, and even helpful in the cases where tooltips are not shown. 2. Maybe, to start, only implement this feature for one or a few categories in Navigator (e.g., Bookmarks, Tables, Images, Objects, Frames), and then wait and see if BZ requests come to add this feature to other categories. The suggested list was chosen because these categories do not have tooltips, unlike Headings, where tooltips give feedback on what is selected. (also, for Tables, Images, Frames, Objects, the labels may often be similar, as seen in the attached video). 3. As you know, adding "needsUXEval" to keywords will provoke a response...
Created attachment 185371 [details] emphasize entry only when entry's object is overlaid (In reply to sdc.blanco from comment #1) > Kudos for continuing to think about improving Navigator. Thanks and thank you for the comments. I was thinking about how to improve the overlay feature. Perhaps more useful would be to only emphasis the entry when the corresponding object is overlaid? > 3. As you know, adding "needsUXEval" to keywords will provoke a response... Let's ask UX for advise.
I am assuming that nothing has changed from demo 1 and demo 2 -- but demo 2 shows a new dimension -- of highlighting the relevant items in the document. First reactions: looks useful (e.g., especially for finding small fields); also the "global" feature (e.g., highlighting all hyperlinks). Comment 1 was written in relation to demo 1, which did not show highlighting in the document (except for one instance where "Images" was selected and maybe "Image 94"). In light of demo 2, my impression is that it would be nice to be able to turn this feature off/on (e.g., in context menu) -- not have it as the only option.
The color inversion works well in all cases. But it feels obtrusive to me when the black font on white background switches to white on black. Would be better to just "shade" the background. I would abstain from delays and unclear dependencies when the highlighting happens. Assuming the user wants to know where this particular field is, any delay of the feedback would be awkward. Or what Seth writes with "I am assuming that nothing has changed" after 'emphasize entry only when entry's object is overlaid'. My first impression was to switch it off (because of the string contrast) or to only blink once or twice and go back to the normal view. But in the end there are not so many scenarios where the cursor rests over an entry in the Navigator and users probably want to know where this item is. With a more subtle visualization it could be a nice feature. (Wanted this for the Styles Highlighter in order to detect where a particular PS/CS and DF is used.)
(In reply to Heiko Tietze from comment #4) > The color inversion works well in all cases. But it feels obtrusive to me > when the black font on white background switches to white on black. Would be > better to just "shade" the background. This is about making the item text bold in the Navigator, not about highlighting the element in the document canvas.
(In reply to Buovjaga from comment #5) > This is about making the item text bold in the Navigator, not about > highlighting the element in the document canvas. Why should one do this?
(In reply to Heiko Tietze from comment #6) > (In reply to Buovjaga from comment #5) > > This is about making the item text bold in the Navigator, not about > > highlighting the element in the document canvas. > > Why should one do this? Should or should one not do this is exactly what is being asked from UX team.
(In reply to Buovjaga from comment #7) > (In reply to Heiko Tietze from comment #6) > > Why should one do this? > > Should or should one not do this is exactly what is being asked from UX team. or the one coming up with the proposal... That would help us to judge, I think :)
(In reply to sdc.blanco from comment #3) > I am assuming that nothing has changed from demo 1 and demo 2 -- but demo 2 > shows a new dimension -- of highlighting the relevant items in the document. A note as I did not notice this bit before: the highlighting in doc canvas is already in 7.5: https://wiki.documentfoundation.org/ReleaseNotes/7.5#Writer Bug 152029
The thought was that it might be useful to match the content brought to attention on the visible canvas to the entry in the navigator content tree. Possibly only have this behavior when the feature is active?
We discussed this topic in the design meeting (only the bold font weight). First of all it is unclear if the weight changes on hover or on click. Highlighting happens on both events. But more relevant is the missing use case. What problem is resolved by this special handling of tree nodes? Basically it's very clear what node is in focus/hovered.
Dear Jim Raykowski, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping