https://bugs.documentfoundation.org/show_bug.cgi?id=135871

--- Comment #50 from Telesto <tele...@surfxs.nl> ---
Created attachment 165744
  --> https://bugs.documentfoundation.org/attachment.cgi?id=165744&action=edit
Example file

(In reply to Mike Kaganski from comment #46)
> Created attachment 165739 [details]
> A sample with some bold text
> 
> (In reply to Telesto from comment #45)
> 
> The attached document contains four sample lorem ipsum paragraphs, followed
> by two dummy text paragraphs.
> 
> The first sample paragraph uses "bold" PS. The second one has one sentence
> using "bold" CS. The third one uses paragraph-level direct bold formatting.
> The fourth one has one sentence with character-level direct bold formatting.
> 
> The first dummy text paragraph has Default PS. The second one has "bold" PS.
> 
> The scenario is that a Benjamin gets this document, and needs to work with
> some formatting.
> 
> Initially the demo of natural, fundamentally unavoidable problem that
> Benjamin sees when working with the document. We copy a single bold word
> from sample paragraphs into *non-bold* dummy paragraph.
> 
> 1. Select "ipsum" (double-click it) in the first paragraph, Ctrl+C, click
> between "He" and "heard" in the first (non-bold) dummy text paragraph,
> Ctrl+V.

PS bold; pasting into PS Default. Result: unbold

-> Confusing for Benjamin. He pasting bold text to different paragraph, and
suddenly becomes unbolded. What the...
Wouldn't change with the different model

> 2. Select "nec" (double-click it) in the bold sentence of the second
> paragraph, Ctrl+C, click between "heard" and "quiet" in the first (non-bold)
> dummy text paragraph, Ctrl+V.

PS default; DF bold. Pasting into PS default; without DF.
Result BOLD paste. However would be unchanged

> 3. Select "velit" (double-click it) in the third paragraph, Ctrl+C, click
> between "quiet" and "steps" in the first (non-bold) dummy text paragraph,
> Ctrl+V.

PS default; DF bold. Pasting into PS default; without DF.
Result BOLD paste. However would be unchanged


> 4. Select "cursus" (double-click it) in the bold sentence of the fourth
> paragraph, Ctrl+C, click between "steps" and "behind" in the first
> (non-bold) dummy text paragraph, Ctrl+V.

PS default; DF bold. Pasting into PS default; without DF.
Result BOLD paste. However would be unchanged

> 
> This shows that the first bold word became non-bold when pasted to the
> target. That is because paragraph styles are in play here; the copied word
> does not bring its source paragraph's style to the target, and takes
> formatting from the style of the target one. Benjamin has no clue why;
> that's a natural confusion (he operates text created by someone else, using
> tools unknown to him, with concepts unknown to him). This is not a bug, and
> should not change.
> 
> Now let's see how this changes when Benjamin starts using *his* tools. Let's
> copy the same four words into the second dummy text paragraph (the bold
> one), but first make each word not bold prior to copy.
> 
> 5. Select "ipsum" (double-click it) in the first paragraph, Ctrl+B, Ctrl+C,
> click between "He" and "tried" in the second (bold) dummy text paragraph,
> Ctrl+V.

PS bold. DF unbold after pressing CTRL+B. Pasting into PS Bold

Result unbold (difference).

->


> 6. Select "nec" (double-click it) in the bold sentence of the second
> paragraph, Ctrl+B, Ctrl+C, click between "tried" and "to" in the second
> (bold) dummy text paragraph, Ctrl+V.

PS Default; DF Bold. Switching to unbold. Pasting into bold PS. Result: unbold.
In make case bold would be turned off

> 7. Select "velit" (double-click it) in the third paragraph, Ctrl+B, Ctrl+C,
> click between "to" and "nervously" in the second (bold) dummy text
> paragraph, Ctrl+V.

PS Default; DF Bold. Switching to unbold. Pasting into bold PS. Result: unbold

= Change would mean. Bold paste, instead of unbold


> 8. Select "cursus" (double-click it) in the bold sentence of the fourth
> paragraph, Ctrl+B, Ctrl+C, click between "nervously" and "tap" in the second
> (bold) dummy text paragraph, Ctrl+V.

PS Default; DF Bold. Switching to unbold. Pasting into bold PS. Result: unbold
= Change would mean. Bold paste, instead of unbold

> 
> The Ctrl+B step makes the selected text explicitly non-bold *in all cases*.
> Benjamin may be sure, that no matter what magic was used to create the text
> that he is facing, he may use this tool, and the text after that tool will
> behave consistently with his expectations: it will be non-bold, no matter
> where it arrives.

True;

> For comparison, let's see what would happen if, instead of applying explicit
> non-bold attribute, Ctrl+B would just clear (remove) bold attribute in the
> fourth sample paragraph (from where we have copied "cursus"). The first
> sentences of the fourth paragraph don't have the explicit non-bold
> attribute, so words in those first sentences are the perfect example what
> would result from your proposal.


> 9. Select "ipsum" (double-click it) in the non-bold first sentence of the
> fourth paragraph, Ctrl+C, click between "nervously" and "tap" in the second
> (bold) dummy text paragraph, Ctrl+V.

Default PS; pasted in Bold PS. Inheriting formatting

> 
> I.e., if Ctrl+B in the fourth paragraph would just clear the bold attribute,
> then Benjamin would face the situation, that after using a tool "B" he would
> still have the result behave unexpectedly/unexplainably to him (you can't
> explain this behaviour unless you understand styles).

Created attachment 165712 [details]
Example file

Open the attached file. Select first paragraph. Drag or copy past it after the
bold paragraph. Result: That didn't bode well. is unbolded because DF unbold.

> So the current status is:
> 
>  - Benjamin might have some difficulty working with other's documents (or
> after using advanced tools cluelessly); but there are tools that he may use,
> to get a simple behaviour expected by him.


> 
> Your proposal is:
> 
>  - no matter what tool Benjamin would use: without understanding of styles,
> the behaviour of the result of *his* actions would still behave unexpected
> to him.

------------------------------------------

> This shows that the first bold word became non-bold when pasted to the
> target. That is because paragraph styles are in play here; the copied word
> does not bring its source paragraph's style to the target, and takes
> formatting from the style of the target one. Benjamin has no clue why;
> that's a natural confusion (he operates text created by someone else, using
> tools unknown to him, with concepts unknown to him). This is not a bug, and
> should not change.

I really don't understand how 'this' is accepted.. And 6-9 which in effect is
about the same thing, not. And even worse, if Benjamin even expects styles to
be inherited, but it's not the case because some 'DF unbold' is floating around
(Luke Kendall)

So yes, the downside is that Benjamin will lose unbold text. But this is also
happening when moving PS bolded text to unbolded PS text. 

And tri-states (off, unbold, bold) is harder to 'grasp' compared to bold (on)
bold (off). 
It's easy to solve with Benjamin tools (and even rather easy to explaining; I
think).

I still think it's evil trade-off. Especially with copy from style to another
cases formatting changes being acceptable. So in essence exact the same thing.
Also needing the same background knowledge about styles. I really don't see the
difference. Instead of 'being consistent' we make an exception in the logic
behave of Benjamin. 
* Which makes the logic of the concept harder to grasp. It's pretty straight
forward without. 
* They issue occurs in the opposite direction. So partly unbold DF text in
unbolded PS style.. pasting to different page style
* It makes the learning curve for styles harder (he starts making changes to
style but with not desired effect with DF unbold floating around in unbolded
PS). 
* Creating all sorts of untended side-effects for people who try to be style
conformant
* Ruining the whole concept of quick in easy style changes (for the "advanced"
user). 
* People having herculan task to clean up certain documents 
* We already in the area where PS styles are actively modified. 
* We pretend every thing is happening same level. So toolbar highlights 'bold'
independent of the source (PS/CS/DF). Which is making the communication about
'styles' and the working any easier. Even I press CTRL+B at Strong Emphasis
Bold, because I can't see the difference between DF Bold or CS Bold. Page
Styles are of course more obvious.
* They ODT get riddled with unnecessary DF formatting

So they current approach is - no offence - over-complicating things massively;
IMHO. No, I don't have years of experience in teaching LibreOffice. However I
do like programs which are design you 'learn' they workflow also in a natural
way. And exceptions 'on rules' don't make it easier. And not being able to turn
off DF after enabling simple unexplainable.  

And here I land into they UX-principles
ux-error-prevention -> Nope the whole document is riddled with unintended!!
formatting as BOLD toggle off isn't equivalent to OFF; Worse it can't be turned
off (
ux-implementation-level -> this works both ways. Currently Benjamin also Eve
has to cope with the problem. Or put it differently; even with knowledge about
styles the experience is still ruined
ux-control -> If I turn on DF, you can't turn it off again!


UX-feedback -> Nope. The formatting toolbar highlights without indication of
the source of the formattting
ux-discovery -> Discovering the system is hard, because of exception in the
rule which should make it easier for n00b Benjamin (questioning if this is
actual the case) but will eventually hinder his progress in understanding the
program in depth. And if he managed that hurdle, he has to work with mutilated
functionality. So so reaching the point of full awareness ends in a frustration
of incapability. While at the same time the 'adjustment' to make life for
Benjamin easier doesn't even cover the whole spectrum. So he will encounter the
same issue even with the adjustment made; where we say yes, we know but that's
the 'natural confusion'. However the 'exception' makes that the confusion never
stops.

I simply dislike trade-off. The current workflow is done with best intentions -
sure - for accommodating Benjamins, but is this really worth it? It's not in
the interest of Benjamin (in the long haul; learning to understand) nor making
Eve really productive.

Consequent behavior (so no exceptions); makes far easier to grasp the system.
Or if Benjamin isn't in the mood, he is surprised, pressed Bold again.. and it
will work. So he will life and be productive too.

Of course my opinion.. It's clear we both disagree in principle. So a lovely
gridlock situation. And people are (unusual) silent about this (hairy) topic.
And it's likely come up in the past. 

Anyhow, I'm not in the position making a anyhow ;-). Nor in the position the
person in charge. So this gets picked up some time, some day. Or stays as it is
in the current form.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to