Description: The menu item "View/Field Names" seems to toggle between showing fields with their value (like the names of chapters, the page number they refer to or the relative positions like "below") and the names of the ids they refer to (like "__RefHeading___Toc####_#########" or "Bookmark_1"). It is easy to accidentally switch on "Field Names", particularly when using keyboard shortcuts (Ctrl+F9 for me) and be stuck with these identifiers without knowing that they can be switched off again; it is also unclear to me what the use of the setting is (If one does not know what a field does one can, via menu or context-menu open the field dialog without ever seeing the ids and still solve potential problems). See Bug 159149 for me getting stuck. Suggestion: Remove the entry from the menu and particularly the keyboard shortcut to prevent people accidentally toggling it. Steps to Reproduce: 1. Accidentally press the Keyboard shortcut for "Field Names" Actual Results: Document has unexpected values for fields, sometimes unusable ones (like __RefHeading___Toc####_#########) Expected Results: Have no such easy-to-toggle functionality exposed via menu and keyboard shortcut. Reproducible: Always User Profile Reset: No Additional Info: Nielsen Heuristics: #5 Error Prevention, #9 Error recovery
No from me for removal from menu. But it might indeed make sense to remove the keyboard shortcut; see a similar case of "track changes" shortcut removal in bug 130847. The difference here is that I don't see the existing Ctrl+F9 shortcut to be close to a really frequently used functions; but OTOH, the questions about Field Names do appear from time to time; and this shows, that people do use the shortcut accidentally. Examples are: https://ask.libreoffice.org/t/8265 https://ask.libreoffice.org/t/9003 https://ask.libreoffice.org/t/9718 https://ask.libreoffice.org/t/14158 https://ask.libreoffice.org/t/15201 https://ask.libreoffice.org/t/18541 https://ask.libreoffice.org/t/20791 https://ask.libreoffice.org/t/24158 https://ask.libreoffice.org/t/32812 https://ask.libreoffice.org/t/50430 https://ask.libreoffice.org/t/61094 https://ask.libreoffice.org/t/78435 https://ask.libreoffice.org/t/76986 https://ask.libreoffice.org/t/94684 Asking for UX advise.
If you say "No from me for removal from menu" you probably know what the function is useful for. Could you add a brief comment on this? It might help the UX people to understand why the function is there and what it can do (aside of confusing people like me, which certainly is not its purpose!)
Exactly to inspect, which field if for what. E.g., you may have a page number field; a total pages field, a number range field; a reference field ... all showing some numbers. Indeed, it is possible to enter each of them, and see which is what; but for people who work with fields on an advanced level, it is much more convenient to toggle the function. Also, some fields take no space at all (e.g., Set Variable, or Next Record, or Hidden Paragraph). Locating and managing such fields might be difficult without the feature - especially when they are put together (one immediately after the other), which makes the same thin grey shadow as if there is only one such field there. The same Ask site has several cases, where the advise was to *enable* the "Field Names" feature, e.g. to diagnose a problem. https://ask.libreoffice.org/t/993 https://ask.libreoffice.org/t/2915/6 https://ask.libreoffice.org/t/20990/2 https://ask.libreoffice.org/t/56569/6 https://ask.libreoffice.org/t/58342/7 https://ask.libreoffice.org/t/69900/12 https://ask.libreoffice.org/t/71729/3 https://ask.libreoffice.org/t/76549/17 https://ask.libreoffice.org/t/77210/8
I agree with Mike on this, I'd prefer keeping the functionality exposed for comment 3 use cases, and potential others. Troubleshooting field issues: understanding what someone else's document/template is supposed to show at a glance, or finding out why one field does not show what we expect it to show... The Navigator is helpful but does not replace seeing the fields labelled in their context. I also find it useful to interact with fields when they are too small to interact with (for example insert a Title/Author/Subject field in a document that does not have those properties set, then try to double-click to edit it: it's very tricky to place the cursor at the exact right spot). And I can imagine many users sending disappointed reports about it if it is removed from the menu. On the other hand, if someone has a nice UI suggestion to make it more obvious to the user that this setting is on, why not.
Thanks for describing the use case, it helped me to see what it is used for, which seems to be (also reading the comments on ask for its use) to diagnose problems or make it easier to interact with fields by going into that specific display mode. So it is useful when activated with a purpose but can cause quite some confusion when activated unknowingly. Some potential remedies: - Remove the keyboard shortcut (or at least have one less easy to trigger accidentally). Not good if we have usecases where there is often toggeling of the option needed and at the same time the users do not know how to add a shortcut. - Rename to "Field IDs" or something similar that points to its somewhat technical nature This might need to be weighted against the frequency of use of "Fieldnames" in our documentation and other places. It also does not help a lot when accidentally triggering via shortcut or when assuming this is just a general bug rather than a view option. - a simple modal of "this activates… do you want to proceed?" with an option of "don't ask me again", so experts would need to activate it once. A bit clunky, but probably a good remedy – this is what Firefox and Windows do when entering alternative interaction modes for accessability settings. (For Firefox, e.g. when pressing F7) - Show a floating mode indicator serving as reminder and easy way to get out again: [showing field names _help_ [deactivate]]. This would address the problem most directly, but I do not know if we can easily use such elements (We could use a bar like the ones for "support libreoffice" after start, but these take much more space than a floating indicator)
(In reply to Mike Kaganski from comment #3) > Exactly to inspect, which field if for what Not buying this use case. It's rather a debug functionality. > The same Ask site has several cases, where the advise was to *enable* the > "Field Names" feature, e.g. to diagnose a problem. Wouldn't Tools > Options be sufficient in those cases? (In reply to jan d from comment #5) > - Remove the keyboard shortcut > - Rename to "Field IDs" +1 > - a simple modal of "this activates… do you want to proceed?" with an option > of "don't ask me again", so experts would need to activate it once. -0.5 (too clumsy for my taste) > - Show a floating mode indicator... Do you have some kind of tooltip in mind, eg on hover while a modifier key is pressed, that shows the ID instead of the usual explanation? What do you think, Mike?
(In reply to Heiko Tietze from comment #6) > (In reply to Mike Kaganski from comment #3) > > Exactly to inspect, which field if for what > Not buying this use case. It's rather a debug functionality. Sigh. Let us then please drop the style highlight - it's exactly the debug functionality. > > The same Ask site has several cases, where the advise was to *enable* the > > "Field Names" feature, e.g. to diagnose a problem. > Wouldn't Tools > Options be sufficient in those cases? No. If you read the very first link in comment 3, you see that people need ease of use. OK, let us think about dropping the shortcut; but having it hidden in the dialog is wrong.
Created attachment 192097 [details] non-modal overlay to indicate a view mode …would automatically closed if mode would be exited via menu or shortcut.
> Heiko: "-0.5 (too clumsy for my taste)" Agree, but it seems to work. (+0,5 from me!) > Heiko "Wouldn't Tools > Options be sufficient in those cases?" Hmm, it would not be an option that you keep on because you prefer it, there is some back and forth it seems. > Mike: [highlight being debug functionality, too] I agree. Actually highlight is a great example for an less obstrusive indicator for a mode-of-displaying-the-document. > Heiko: "Do you have some kind of tooltip in mind" No, I actually meant something like a non-modal, small bar or the like? I attach a mockup (not saying its great, but have a look) Actually, I like the idea of showing the ID in the tooltip as it offers a modeless way of debugging. It would not solve the problem that some fields are very small and hard to hit (Though I do not know how frequent that is). If we decide to do that, we might want to check what useful lables would be; Currently, for bookmarks is shows the bookmark name; for headlines the headline content etc. without indication of the type of reference (or the ID in the case of an headline)
(In reply to jan d from comment #9) > No, I actually meant something like a non-modal, small bar or the like? I > attach a mockup (not saying its great, but have a look) We call it infobar (eg. shown when opening a read-only document). > ID in the tooltip ... some fields are very small and hard to hit True And since we have some strong arguments to keep the function in the menu it remains a) only to remove the accelerator (simple easyhack) and b) optionally add an infobar (sounds like over-engineering to me as users would deliberately enable it; medium difficult easyhack). Code pointer: All <node oor:name="F9_MOD1" oor:op="replace"> assigned to .uno:Fieldnames in officecfg/registry/data/org/openoffice/Office/Accelerators.xcu needs to be removed. An example for the infobar would be BaseWindow::ShowReadOnlyInfoBar(), but I suggest to not follow the idea.
> And since we have some strong arguments to keep the function in the menu > it remains a) only to remove the accelerator (simple easyhack) and > b) optionally add an infobar (sounds like over-engineering > to me as users would deliberately enable it; medium difficult easyhack). As it seems to be a tried solution for such casess, the "a simple modal of "this activates… do you want to proceed?"" would still do the job (and would even allow to keep the accelerator as-is). I don't know how hard it would be to create though (particularly because of the "Don't show again" option)
(In reply to jan d from comment #11) > "a simple modal (with) "Don't show again" option ...has been done for bug 155561
(In reply to Heiko Tietze from comment #6) > Wouldn't Tools > Options be sufficient in those cases? Strong -1 for this, as the Options dialog is more for "set and forget" options, whereas the feature here is likely turned on then off in quick succession. Clarified the summary. (In reply to jan d from comment #9) > Actually, I like the idea of showing the ID in the tooltip as it offers a > modeless way of debugging. I like this idea, as currently hovering over fields does not seem to do anything (in my test, even with extended tips - has anyone seen tooltips for fields?). Maybe show label if value is used, and show value if label is shown? In any case, something for a separate enhancement request.
How about: - I create a ticket for the implementation of a simple modal (with) "Don't show again" option. - I create a ticket, targeted as at a designer or writer to review the current tooltip behavior and to suggest potential improvements (Or are there strong vetos against either of these?)
(In reply to jan d from comment #14) > How about: > - I create a ticket for the implementation of a simple modal (with) "Don't > show again" option. > - I create a ticket, targeted as at a designer or writer to review the > current tooltip behavior and to suggest potential improvements > > (Or are there strong vetos against either of these?) Apparently no veto :-)
created: "View/Field names can trigger confusing mode, implement warning" at https://bugs.documentfoundation.org/show_bug.cgi?id=159444
"UX Design: Collect and analyze tooltip text on fields": https://bugs.documentfoundation.org/show_bug.cgi?id=159446
The command uno:Fieldnames is still assigned to a shortcut. Keep it or handle it in this ticket?
> The command uno:Fieldnames is still assigned to a shortcut. > Keep it or handle it in this ticket? If we get a warning for activation in case of click or Keyboard shortcut, we can keep the shortcut; if not, I would suggest to remove it.