Bug 146493 - "Insert > Special Character" and "Insert > Formatting Mark" should be renamed
Summary: "Insert > Special Character" and "Insert > Formatting Mark" should be renamed
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.2.4.1 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Main-Menu
  Show dependency treegraph
 
Reported: 2021-12-30 22:49 UTC by jsv
Modified: 2022-01-05 13:46 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
indesign (10.28 KB, image/png)
2022-01-04 16:47 UTC, jsv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jsv 2021-12-30 22:49:22 UTC
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
Comment 1 Dieter 2021-12-31 08:36:52 UTC
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).
Comment 2 jsv 2021-12-31 09:12:20 UTC
Is clear in what way? It actually gives you access to all the characters of the selected font.
Comment 3 LeroyG 2021-12-31 14:29:03 UTC
(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".
Comment 4 Roman Kuznetsov 2021-12-31 15:01:26 UTC
-1 for both suggestions

You always forget about documentation and translation teams

I don't see any benefit with those renamings
Comment 5 jsv 2021-12-31 18:46:00 UTC
> 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?
Comment 6 Dieter 2022-01-02 12:08:50 UTC
(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.
Comment 7 jsv 2022-01-02 16:36:37 UTC
> 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.
Comment 8 Heiko Tietze 2022-01-03 13:05:07 UTC
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.
Comment 9 Adolfo Jayme Barrientos 2022-01-03 13:26:10 UTC
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
Comment 10 sophie 2022-01-04 14:15:39 UTC
(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.
Comment 11 jsv 2022-01-04 16:46:21 UTC
> 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.
Comment 12 jsv 2022-01-04 16:47:16 UTC
Created attachment 177308 [details]
indesign
Comment 13 sophie 2022-01-04 17:00:44 UTC
(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.
Comment 14 jan d 2022-01-04 17:03:09 UTC
Without having a clear case where users are irritated by the current labels, I would stick with what we have.
Comment 15 jan d 2022-01-04 17:15:24 UTC
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.
Comment 16 Daveo 2022-01-04 17:23:24 UTC
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.
Comment 17 jsv 2022-01-04 17:42:03 UTC
> 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.
Comment 18 Daveo 2022-01-04 18:02:12 UTC
(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.
Comment 19 Thomas Lendo 2022-01-04 19:22:16 UTC
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.
Comment 20 Daveo 2022-01-04 19:56:01 UTC
(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.
Comment 21 jsv 2022-01-04 20:54:16 UTC
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.
Comment 22 jsv 2022-01-04 21:20:45 UTC Comment hidden (abusive)
Comment 23 V Stuart Foote 2022-01-04 21:35:48 UTC
-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.
Comment 24 Heiko Tietze 2022-01-05 07:15:26 UTC
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.
Comment 25 Cor Nouws 2022-01-05 10:17:23 UTC
(In reply to Roman Kuznetsov from comment #4)
> -1 for both suggestions

Likewise.
Comment 26 Adolfo Jayme Barrientos 2022-01-05 13:46:26 UTC
Marking WONTFIX. This proposal is too disruptive.

I am sorry that this proposal has been handed poorly and the discourse has descended into bickering.