I'd like to draw some attention and elaborate a bit on an issues which
came up in the last design meeting. Excuse me for not managing to have
my thoughts reflected in the minutes.
----------------
"Improve description of keyboard shortcut binding names"
https://bugs.documentfoundation.org/show_bug.cgi?id=169659
----------------
The bug poster was complaining about not being able to understand what a
command does, as he was examining commands in the Keyboard Shortcuts
dialog. The poster hoped to rely on the command names, as appearing in
the Customize dialog, to have at least a basic notion. While some
commands names stand on their own, e.g. "Export to PDF", some have
shortened names, relying on the context due to being placed in a menu,
e.g. "Footnote", which when placed on the Insert menu, is read as
"Insert Footnote". Or "50%" which means "Set viewport zoom to 50%".
Never mind what the bug poster asked for specifically, or what they can
do personally. Even though that bug is closed, the salient point for me
is that we have an inconsistency in at least two of our fields regarding
commands: Label and Tooltip. They are set based on an implicit
assumption of their being located in the menu where we place them by
default. I believe that _is_ problematic, and bites us in the a** in
other UI modes. All commands should have a context-less label; and a
context-specific label is something to give more thought to: Perhaps
there is a "one true context" for every command, but perhaps a command
can have different contexts, necessitating different contextual labels.
As for tooltips, I lean towards a claim that the tooltip should use the
availability of more space, and always be non-contextual, i.e. contain
any necessary words of context.
Eyal
On 28/01/2026 22:07, Heiko Tietze wrote:
Present: Eyal, Sahil, Heiko
Comments: Stuart, Martin, GJord, Samuel
Tickets/Topics
* Improve description of keyboard shortcut binding names
+ https://bugs.documentfoundation.org/show_bug.cgi?id=169659
+ unlike other UI elements the keyboard shows tooltips only on the
functions list (Stuart)
+ not asking for a tooltip but better understanding eg. where the
command is being used like "Insert > Footnote" (Martin)
+ improved labels requested for bug 169766 and bug 169767, for example,
easy to do but with drawback for the Notebookbar, see also
bug 163117 (Heiko)
+ some kind of "descriptive label" in addition to the existing at the
command solves this issue and other but is over-engineering (Heiko)
+ issue in the narrow sense is solved tackled per trial and error or
by RTFM (Eyal)
+ could imagine some description in the online help per command (Eyal)
+ categorization of commands is sufficient (Sahil)
=> WF
* Allow collapsing threads of Writer Comments/Annotations
+ https://bugs.documentfoundation.org/show_bug.cgi?id=169301
+ missing function (GJord)
+ implemented with the (experimental) comments sidebar (Heiko)
+ don't like the comments sidebar and would like to have alternative
access (Eyal)
+ since the sidebar is experimental it makes sense to improve existing
solution (Sahil)
=> comment
* Make accessibility sidebar font size configurable
+ https://bugs.documentfoundation.org/show_bug.cgi?id=169420
+ alternative UI scaling option was removed for bug 101646 (Samuel)
+ agree with the request; could be configured at Options... (Stuart)
+ against fiddling around and overwriting system settings (Heiko)
+ on Windows, system settings > a11y > text size = 150% or the like
+ no good reason to change the font _only_ on this view (Eyal)
=> WF/INV
* FEATURE REQUEST: Paragraph styling: capabilities for lead-in
+ https://bugs.documentfoundation.org/show_bug.cgi?id=170006
* FEATURE REQUEST: Drop Caps: option to skip over leading punctuation
+ https://bugs.documentfoundation.org/show_bug.cgi?id=170044
+ both sounds like over-engineering (Heiko)
+ possible solution is to double the per-character drop cap options
and provide the same for n words (Heiko)
+ lead-in could be an extra setting additional to drop caps;
with style settings for words, lines, or until the next
punctuation (Eyal)
+ option to skip leading punctuation welcome (Eyal)
+ lead-in is essential for professional print layout (Eyal, Sahil)
=> comment
