As QA people use to say: "Bugzilla, or it didn't happen". So here we go https://bugs.documentfoundation.org/show_bug.cgi?id=133023
On 02.05.20 12:54, Marc Paré wrote: > Thanks for pointing me to bug-59754 for which I am more concerned about. > > I would like to see this discussed on merit. > > If we are serious about making LibreOffice accessible to more users, > then we should have predictable returns on typing text in documents. > This will make LibreOffice more of a reliable suite and lead to less > confusion and frustration by users. Using the argument that this will be > an occasion for users to expand their knowledge is the wrong approach; > the end result of this default setting is to only frustrate users for no > reason at all. LibreOffice then has to take a hit on the bad reputation > side for having set as default an added feature that it calls > auto-correction. > > This should be discussed as it is, at best, bad marketing of the product > when it creates frustration for no reason at all. Making settings return > predictable results will make the suite more of a valuable tool to a > larger expanding group of users and avoid comments of frustration on > such obvious mistake at setting a reasonable default. > > Marc > > Le 20-05-02 à 02 h 14, Heiko Tietze a écrit : >> You are not alone. But the idea was rejected in the past. >> >> Disable autocompletion/autocorrect by default >> https://bugs.documentfoundation.org/show_bug.cgi?id=59754 >> >> AutoCorrect need alternative for handling use of keyboard input of >> apostrophe as apostrophe (rather than single quote) >> https://bugs.documentfoundation.org/show_bug.cgi?id=127883 >> >> (and other) >> >> On 02.05.20 03:56, Marc Paré wrote: >>> Someone on a list other than LibreOffice pointed out that the initial >>> settings in AutoCorrect are set with the following formatting >>> feature-default of, when you type: >>> _CausesTextToBeUnderlined_ /CausesTextToBeItalicized/ >>> *CausesTextToBeBold -CausesTextToBeStruckThrough- >>> >>> As I would see this more of a formatting "feature" and not of a >>> formatting "correction", I wonder if the initial user-default with these >>> switched ON makes sense. To me, such a "feature" would be best >>> rationalized as a feature one would offer to a user wishing to use >>> keyboard alternatives to the conventional Ctrl-B, Ctrl-U etc switches. >>> >>> I wonder if, from a regular user point of view, it would make better >>> sense to have the initial settings in "Tools-->AutoCorrect-->AutoCorrect >>> Options-->Options" set with these switches OFF (default). This would >>> then mean that, should a user start typing a URL such as /home/test, >>> that user would not continually have to battle to rid him/herself of the >>> "home" being formatted into an italics "home" and not being allowed to >>> complete the URL without being formatting before typing the complete >>> line as is. I would argue, that, setting the switches to the OFF >>> position as the LibreOffice default, would return a format that one >>> would expect when typing any stings such as /home/test etc. >>> >>> Having these switches turned ON as the LibreOffice default, from the >>> point of view of a regular-user wishing to adopt the LibreOffice suite, >>> returns a behaviour that is NOT expected, and, raises the level of >>> frustration a little more as to deciding whether to adopt the suite or >>> expecting to trouble-shoot an issue where the result goes contrary to >>> what one would expect. >>> >>> I wonder if we could re-consider the ON-default and leave these switches >>> to the OFF position? >>> >>> This would then give a better result of, where more-advanced-users, >>> wishing to adopt the LibreOffice suite, and, wanting to expand >>> formatting switches, being pleasantly surprised that these switches >>> exist (a positive reaction), rather than what we presently have, where, >>> a regular-user wishing to adopt the LibreOffice suite, experiencing the >>> unpleasant auto-correction switches formatting text in a way that is not >>> expected (a negative reaction) and making that user doubt his/her choice >>> of LIbreOffice adoption. >>> >>> Leaving new-LibreOffice adopters with a good impression, with very few, >>> if any, complaints would seem to be a good goal; making the initial >>> default to the OFF position, in my opinion, a good change. >>> >>> Marc >>> >> >> _______________________________________________ >> List Name: Libreoffice-qa mailing list >> Mail address: Libreoffice-qa@lists.freedesktop.org >> Change settings: >> https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa >> Problems? >> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ >> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette >> List archive: http://lists.freedesktop.org/archives/libreoffice-qa/ > > -- Dr. Heiko Tietze, UX-Designer and UX-Mentor Tel: +49 30 5557992-63 | Mail: heiko.tie...@documentfoundation.org The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint
signature.asc
Description: OpenPGP digital signature
_______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/