[libreoffice-design] Minutes from the UX/design meeting 2025-May-06

Present: Eyal, Dan, John, Heiko
Comments: Jan, Jay, Stuart, Martin

Tickets/Topics

 * No notification/reload suggestion after file replacement on disk
   + https://bugs.documentfoundation.org/show_bug.cgi?id=171341
   + warning on save is thrown, continuously checking might be a
     performance issue (Heiko)
   + sounds like a nice to have; OS may have functions (Jan)
   + sync file system is used when other apps show a file changed
     info via infobar; does not work / well on CMIS (Dan)
     + some fallback might be feasible if the sync is not possible
   + use case: files generated by other processes, or remote connection (Eyal)
   => no blocker from UX

 * When launching LO with an already-opened document, that has changed
   on disk, nothing happens
   + https://bugs.documentfoundation.org/show_bug.cgi?id=171342
   + opening a file that is open brings the window in foreground (Heiko)
   + topic is about modifications on this file; expect a hard reload
     with confirmation on load rather than a bring-to-front (Eyal)
   + ideally we also offer compare/merge functions (Eyal)
   + sounds reasonable (Dan)
   => no objection from UX

 * When creating a new cell validity, open the "Criteria tab
   + https://bugs.documentfoundation.org/show_bug.cgi?id=170359
   + checking for validity could be an easyhack but this violation
     of a rule, namely to open at the same position as before, here
     enhanced by "only if properties have changed" is barely
     possible in a consistent fashion (Heiko)
   + predictability is prime; Consistency over Efficiency -> WF (Jan)
   + some other dialogs behave similarly - if there's an inherent
     workflow for engaging with them (Eyal)
   + the Validity dialog is actually not a free choice but kind of
     a step through a fix workflow - and in this case we could
     encourage/request the Ui to apply the existing wizard (and to
     not touch the dialog memorization) (Heiko)
   + if the attributes have been entered, the dialog is meant
     to allow modifications and we might need to go then with the
     tabbed dialog (Eyal)
   => comment

 * Should shortcut keys be translated to a localized UI
   + https://bugs.documentfoundation.org/show_bug.cgi?id=90546
   + not everyone has a keyboard with English layout (Jay)
   + try harder to follow the OS/DE configuration (Stuart)
   + pretty much every other app on MacOS adheres to the English standard
     (CMD + B for bold), see bug 171871 (Martin)
     + macOS has some automatic localization; the statement is maybe
       not true; since Monterey the shortcut is the position on the
       keyboard rather than the actual key stroke (Dan)
   + Localizing shortcuts is important for users who don't use English, and
     perhaps not even know a Latin alphabet for their second language. Some
     users may not have Latin symbols on their keyboard. (Eyal)
   + add shortcut definition to the text localization; wont solve the
     OS/DE issue though (Heiko)
     + alternatively we allow to customize/ship/install just shortcuts
       and expect the local community to create an extension for shortcuts
     + if done, we should remove the hard-coded localized shortcuts entirely
   + MSO changes the shortcut from ctrl+B to shift+ctrl+f for Bold when
     switching from English to German
   => dedicated extension sounds like the most flexible solution, also
     covering the case when English is preferred

--
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy