Description: 1 Insert > Special Character This is confusing. In my opinion, what an average user would assume under "special character" is a character from a very limited set of characters. I suggest to rename in to "Character map" instead. 2 Insert > Formatting Mark This is even more confusing. In my opinion, what an average user would assume under "formatting marks" are things that are used to make formatting more "visual", but cannot be edited directly. For example, blue pilcrows (¶), which you can see if you enable View > Formatting Marks. I suggest to rename in to "Special character" instead. *** So, Insert > Special Character should be renamed to Insert > Character map Insert > Formatting Mark should be renamed to Insert > Special character Steps to Reproduce: see above Actual Results: see above Expected Results: see above Reproducible: Always User Profile Reset: No Additional Info: see above
Thank you for your suggestion. cc: Design-Team My opinion: I think "Special character" is clear and so I won't support this idea. Perhaps there could be some improvements around the name "Formatting Marks" (see also bug 127954).
Is clear in what way? It actually gives you access to all the characters of the selected font.
(In reply to jsv from comment #2) > It actually gives you access to all the characters of the selected font. I support the change from "Special Character…" to "Character map".
-1 for both suggestions You always forget about documentation and translation teams I don't see any benefit with those renamings
> You always forget about documentation and translation teams I do understand that this is additional work for documentation and translation teams. But, apart from this, are you really really sure that, for example, the nonbreaking space is a formatting mark and not a special character?
(In reply to jsv from comment #2) > Is clear in what way? It gives me access to characters, that are not part of my keyboard.
> It gives me access to characters, that are not part of my keyboard. As well as access to the character that _are_ a part of your keyboard. A part of your keyboard layout, to be precise. Als, I don't think that you will call any character that is present in the font but missing on your keyboard layout a "special character". :) Liberation Serif, for example, have glyphs for Russian language. Would you call these characters "special"? Of course no.
IMO this is a lot for sake of renaming itself, haven't met a user who actually struggles with the terms. But if we change the non-breakable formatting marks into special character this will bring a lot confusion for users who are familiar with the terms. But what term suits better should be decided primarily by the native speakers.
We actually have a discrepancy, in Math we have a dialog that we call Symbols instead of Special Character. If any renaming is to be done, it should encompass both
(In reply to Heiko Tietze from comment #8) > IMO this is a lot for sake of renaming itself, haven't met a user who > actually struggles with the terms. But if we change the non-breakable > formatting marks into special character this will bring a lot confusion for > users who are familiar with the terms. > > But what term suits better should be decided primarily by the native > speakers. I second your comment, I've never met a user confused by those strings too. I don't see any benefit of renaming them.
> I've never met a user confused by those strings too. I don't see any benefit of renaming them. These strings are simply wrong, and this is, in fact, plain obvious. It seems these names are "inherited" from MS Word, but this doesn't make them correct. Neither InDesign nor Affinity Publisher follow this naming. See the InDesign UI screenshot which I have just added.
Created attachment 177308 [details] indesign
(In reply to jsv from comment #11) > > I've never met a user confused by those strings too. I don't see any benefit of renaming them. > > These strings are simply wrong, and this is, in fact, plain obvious. > > It seems these names are "inherited" from MS Word, but this doesn't make > them correct. they were already there in StarOffice, we usually don't care what proprietary software are doing. >Neither InDesign nor Affinity Publisher follow this naming. > > See the InDesign UI screenshot which I have just added. These are specific tools dedicated to design or PAO, not an office suite. I still don't see why we should ask l10n, documentation teams and our users to change when they don't see a need to, that will only confuse them.
Without having a clear case where users are irritated by the current labels, I would stick with what we have.
The question of what other software is doing makes sense in case we know that there is a problem and a change is needed. People come to new software with existing experiences and it makes sense to see what they might be familiar with and thus what is intuitive to them (https://www.asktog.com/papers/raskinintuit.html). I agree that the current lables might not be ideal. Aside of the suggested design tools, MS Word, in recent versions, actually does something similar to what jsv proposes: Insert-Ribbon → Symbols → [Window with two tabs:]"Symbols" (big table of characters), "Special Characters" (typographical and control characters like non-breaking space, en-dash, em-dash, ellipsis and writing-direction overwrite) However, it still is something that I would not change without some test or other data, and if we can’t research is further, leave as it it.
This was the terminology used by StarOffice and subsequently in OpenOffice and now LibreOffice. With millions of users over more than 20 years the is the first and only known report of our users being "confused" by this. My take is NOT A BUG. Please let's stop "Bike-shedding", playing with semantics and concentrate on REAL issues.
> MS Word, in recent versions, actually does something similar > to what jsv proposes: ... Thanks, Jan. -- To Sophie: This doesn't make a difference whether we talk about an office suite or desktop publishing software in this particular case. What I mean is that Adobe (and even better example is Apple) pay a lot of attention to thing like design, naming, wording, typography and so on. -- Actually, unless I started to write my own LO documentation, I never have problems with the current naming. But once you will start to write such documentation, you will soon discover that referring to things like "non breaking spaces" as formatting marks is confusing, especiallyn when the same name is used for "virtual" things such as blue paragraph marks. -- To Dave: You just one person who advoactes for calling a cat as "dog" and a dog as "cat". Just because "nobody strugged before". OK, I don't want to waste my time arguing with people who have no understanding how the professional should look.
(In reply to jsv from comment #17) > To Dave: > > You just one person who advoactes for calling a cat as "dog" and a dog as > "cat". > > Just because "nobody strugged before". > > OK, I don't want to waste my time arguing with people who have no > understanding how the professional should look. To (Anonymous jsv) This is NOT an open forum for NON-CONTRIBUTORS like you, to jump in insult and attack the views and opinions of project members who have contributed to this project and it's predecessors for 20+ years.
Please, calm down all. jsv made a valid suggestion to improve the software for all users in his view. I support a change if it's "viewed holistically" for all parts of the program and all strings in menus, options, help, etc. Personally I've no idea what's a better wording. Also keeping the status would okay for me.
(In reply to Thomas Lendo from comment #19) > Please, calm down all. jsv made a valid suggestion to improve the software > for all users in his view. Thomas, it is NOT a case of "calming down". Agreed, (Anonymous NON-CONTRIBUTING jsv) ORIGINALLY expressed a view/opinion about a subject and as someone involved with this project for over a decade, I respect that everyone is entitled to that, but (Anonymous NON-CONTRIBUTING jsv) then proceeded to attack, abuse, insult and make meaningless infantile derogatory "cats dogs" commentary about the view/opinion of another Bugzilla reporter. THIS IS NOT THE WAY THAT TDF & LibreOffice MEMBERS TREAT EACH OTHER.
to summarize: * calling a menu item that is used to insert characters such as em dash or non-breaking space "Formatting marks" is wrong and confusing, and since this affect writing documentation, this does matter * calling a menu item that is used to get access to all of the character of the font "Special characters" is wrong and confusing, and since this affect writing documentation, this does matter * using argumentation "you are the first and probably the last user who have problems with it" is either naive or manipulative, and it can be proven in many ways, e.g. comparing with other software (german Papyrus Author, if you don't like InDesign) or by talking with "casual", that is, not biased, users.
(In reply to Dave Barton from comment #20) > proceeded to attack, abuse, insult and make meaningless > infantile derogatory "cats dogs" commentary about the > view/opinion of another Bugzilla reporter. my God... i'm from Russia. is it OK that you, brave western guys who conquested the world, are so snowflakes now? is it OK for **YOU** ? this is just disgusting. Dave, you are not a man. You are a 12-years old girl.
-1, on both changes (the Insert -> "Special Character..." dialog, or the list of Insert -> Formatting Mark) they are self-documenting and self explanatory. No real advantage to changing our legacy labeling/naming of the UI elements. And as to the "Symbols..." dialog in the sm module of comment 9--that is a completely different implementation that has no relevance to the "Special Character..." dialog. Nor could the dialog be linked for use in sm without major refactoring--its off topic. Back to Unconfirmed as there is NO consensus this change is needed, nor UX movement in that direction. Frankly this is 'bikeshedding'--I won't close it Won't Fix, but that is my suggestion for any UX action.
I can follow the argument that users might misunderstand Formatting Mark as "show the pilcrows". And the InDesign example is tempting: "Insert > White Space and Break Character". But still bike-shedding.
(In reply to Roman Kuznetsov from comment #4) > -1 for both suggestions Likewise.
Marking WONTFIX. This proposal is too disruptive. I am sorry that this proposal has been handed poorly and the discourse has descended into bickering.
(In reply to sophie from comment #10) > (In reply to Heiko Tietze from comment #8) > > IMO this is a lot for sake of renaming itself, haven't met a user who > > actually struggles with the terms. > > I second your comment, I've never met a user confused by those strings too. > I don't see any benefit of renaming them. Note how bug 139107 advocates for inclusion of the non-printing characters *non-existing* in a given font into this dialog, *exactly because* the name of the function does not imply the connection to all the *font's* characters, but instead talks about some "special characters". IMO, this needs revisiting.
(In reply to Mike Kaganski from comment #27) > Note how bug 139107 advocates for inclusion of the non-printing characters > *non-existing* in a given font into this dialog, *exactly because* the name > of the function does not imply the connection to all the *font's* > characters, but instead talks about some "special characters". > > IMO, this needs revisiting. Sure. Our legacy menu and button labeling has used 'Special Character...' for the dialog, but it clearly is an implementation of a "Character map" (though it does have implementation issues, and has dropped its edit buffer for text string composition). Do we really gain anything by relabel? While the use case of insertion of non-mapped/non-visual control characters, not associated to any font, has remained a menu of individual UNO actions (uno:FormattingMarkMenu, and the list of available UNO controls one for each control character). The menu of UNO actions could certainly be expanded to provide categorization to accommodate additional control characters (each needing its own UNO). Adopting a sub-menu similar to OPs posted attachment 177308 [details] would probably be needed to accommodate the additional formatting marks. But the first level Special/White space/Break would not be needed. But no real advantage their either to relabeling its insert "Formatting Mark" and remains consistent with the view "Formatting Marks" visibility toggle for NPC.