Bug 159446 - UX Design/Technical Writing: Collect and analyze tooltip text on fields
Summary: UX Design/Technical Writing: Collect and analyze tooltip text on fields
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.6.4.1 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyInteresting, easyHack, skillCpp
Depends on:
Blocks: Fields
  Show dependency treegraph
 
Reported: 2024-01-30 11:33 UTC by jan d
Modified: 2025-12-04 10:28 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example tooltip for page number field (63.42 KB, image/png)
2025-12-04 10:02 UTC, Jim Raykowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jan d 2024-01-30 11:33:46 UTC
Problem: Writer offers "Fields", that is dynamically changeable text fragments that e.g. refer to a headline’s text, a page, a date etc. 
These fields can be inserted via: 
- Insert/Field
- Insert/Cross Reference

The fields usually show some information when hovered with the mouse. This can be useful to understand what the field does and what it refers to. However, these texts are currently not consistent. Some show the target, others just repeat the rendered field etc. 

There is potential to make this function more useful and to avoid mode switches to View/Field Names or other manual inspections. At the same time it is essential to keep the tooltip text short; we can't just add all info that might be useful.

The outcome of this task could be a table that has the following columns:

Field-Type |  Current Tooltip  | Suggested Tooltip | Reason for change/notes
Comment 1 jan d 2024-01-30 11:36:12 UTC
Based on Stéphane Guillou’s comment: https://bugs.documentfoundation.org/show_bug.cgi?id=159299#c13
Comment 2 Heiko Tietze 2024-01-31 09:39:58 UTC
Hossein, this could be a nice easyhack. Please add some code pointers.
Comment 3 jan d 2024-01-31 13:25:26 UTC
@Heiko: Putting it into action is probably an easyhack, but I wondered if it should be treated as (potentially) two tasks, one of analysis, one of implementation which would enable to involve non-coders as well. (If someone wants to do both, also great)
Comment 4 Buovjaga 2024-01-31 13:27:15 UTC
Reverting risky needinfo status which should not be used in this case.
Comment 5 jan d 2025-02-08 18:00:46 UTC
Heiko wrote: 
> Please add some code pointers.

Are there no central files where UI strings are collected (for language switching, translation...) instead of being hardcoded in C++?
Comment 6 Eyal Rozenberg 2025-11-28 10:33:47 UTC
So, @jan_d, is this bug report about having a uniform policy for the tooltips? About making their content configurable via Tools > Options? Or just building the table as something for developers to be able to consider?
Comment 7 jan d 2025-11-28 10:42:48 UTC
> is this bug report about having a uniform policy for the tooltips? About making their content configurable via Tools > Options?

No. This is specifically about the tooltips that show when hovering a text that is generated by a field function (which are usually shown as text with gray background). Helpful tooltips are relevant here, because it is hard to know what the field does (it does not have a lable itself, it is just special text in the doc). Currently the texts are not very helpful imho. 

So this task has two steps: 
1. Create a table for how the tooltips are for each field now and what a better alternative would be

2. Change the fields in code/UI strings file (I don't know how this is implemented)
Comment 8 jan d 2025-11-28 10:43:32 UTC
Probably helpful: Writing/using tooltips: https://developer.gnome.org/hig/patterns/feedback/tooltips.html
Comment 9 jan d 2025-11-28 12:24:45 UTC
For example, Fields/Document seem not to have any tooltips. There something like "Field: Time" or so would be helpful to identify what the text is.
The Cross-References vary: If you link to a headline, it just repeats its text without saying that it is a cross-referece to a headline. Something like: "Reference to..." or the like could clarify.
Comment 10 Heiko Tietze 2025-12-03 05:38:41 UTC
Essentially you suggest to show View > Field Names probably with more actionable content like "Document: Author", "Document: Date (variable)", "Cross-reference: Headings > Chapter", "Cross-reference: Table > Caption Text", "Docinformation: Revision number", or "Variables: Show variable".

> The fields usually show some information when hovered with the mouse.
We show tooltips on links (footnotes etc.), variables (the value), and maybe some other but not for date/time, page number and many other. Could be doable, though. The tooltip would be a shortcut to double click, which reveals the field configuration or to showing the field names.

Jim, what do you think about this idea?
Comment 11 jan d 2025-12-03 19:45:13 UTC
> probably with more actionable content

Yes, to be more specific: Content that answers the question: "What is this?", since the fields just appear as some text with a gray background. 

Also, I think it is good to get rid of merely repeating the field's content since it does not answer the question. (Except maybe when in "show field ID" mode, but that might be too difficult to make mode-dependent)
Comment 12 Jim Raykowski 2025-12-04 10:02:39 UTC
Created attachment 204427 [details]
Example tooltip for page number field

+1 from me! Definitely seems doable.

Attached is a screen shot showing a added tooltip for a page number field in a document.

Pointers for the coding part of the task:
sw/source/uibase/docvw/edtwin2.cxx => SwEditWin::RequestHelp
sw/inc/fldbas.hxx => enum class SwFieldIds

Technical writing part:
Create useful tooltips for each of the items in the enum class SwFieldIds that we want tooltips for.
Comment 13 jan d 2025-12-04 10:28:54 UTC
> Create useful tooltips for each of the items in the enum class SwFieldIds that we want tooltips for.

Would make sense to go through them separately, but in general, a Field:[Fieldtype] probably is a good default. (like "Field: Page Number" or "Field: Date(Fixed)")