[Libreoffice-bugs] [Bug 135871] Highlighting no fill is not the same as no fill; there is still direct formatting present according to paragraph style

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #51 from Telesto <telesto at surfxs.nl> ---
(In reply to Mike Kaganski from comment #48)
> (In reply to Telesto from comment #45)
> > I'm not a heavy user. I'm only give my opinion based on what I have noticed.
> > However, you should ask people who actually are correcting formatting and
> > how often they need to do that. And if this a cumbersome job etc. 
> 
> And I have ten years of experience using MS Office, and then another ten
> years of experience using, deploying LibreOffice in a real commercial
> company; training people; creating templates; helping them solve problematic
> situations related to creating new documents with really complex text
> formatting (see GOST 21 at [1]), and to documents received from those using
> MS Office; and sending our documents to parties using MS Office, etc. That
> was prior (and the reason) to my joining development of LO.
> 
> Don't assume that your opponents have no clue what real users use and what
> problems they see.

I didn't intend to offend or intimidate, or discredit your knowledge. And of
course it's hard to know somebody's background/experiences. I only stating my
'gut' feeling. And I assume there are more people who run in to certain issues
with DF (and styles). I'm surely not representing the whole world, not even an
explicit group. Only giving my view :-). And have seen comments by Luke/Thomas
related this matter (so not such big audience either :-).

I do know it isn't easy for my to get to the bottom of DF formatting (and
CS/PS). So DF bold being overwritten by CS Strong Emphasis. Or changing PS
throwing out certain DF (reported that). If DF is always on top, Strong
Emphasis shouldn't throw CS Strong Emphasis out. Or if this is desired .. I
want to be able to tell the difference between DF bold and CS Strong Emphasis
bold (at formatting button level). To be able to tell what I have in front of
me.


> 
> > I'm more they type of experiments.. Worse what can happen is a 'revert' (and
> > some wasted time/ money developing it). However we get feedback/ and data/
> > experiences. Not that ever idea has to become an experiment.. arguments are
> > fine.. but some point 'experiences' matter. 
> 
> As I already stated: this is bad. Any "battle-testing" would only attract
> people who have problems with the change, and only part of those. The people
> would be vocal; the reports would never show you how many have benefitted;
> how many have problems with the change (only would show how loud those who
> report are).

This will always be never ending topic. I assume there are many more bug out
there than in the bug tracker. People don't report it for various reasons
(don't notice, don't know what happened, have not time, not interest etc). 

I always assume someone else will report an certain issue. Or the QA department
of TDF will figure it out.. 

> And in this special case, your proposal for battle-testing is even worse.
> You are making a change that presumably might (I say will) hurt those who
> are the beginners, those who might as well assume their problems are due to
> them being newbies. Such a change would hurt them, but would not result in
> proportional increase of reports - only in proportional abandoning the tool
> that was tested, and proven not suitable.

Yes, ideally an separate experimental version :-). Or some 'advanced' setting
etc. But than people won't use it. So this topic will go in circles. 

There is always an unrepresented groups. Most people don't have the time,
interest etc to care. They want a working product; and the take what fits their
needs. 

And I love to bring up markdown. I still can't believe (no data; can't proof
anything] this is 'wanted' by majority. But somehow it got (a) implemented (b)
turned on by default. The only thing I can argue is that add additional
UX-principle. LibreOffice should restrict itself to 'core' functionality being
enabled by default [not sure what the rules are about new functions etc;
embedded or extension]. 

And of course somehow we need to end up with a decision :-). They organ in
charge being UX-department. A understaffed, black box department. Still
disagreeing on certain decisions (arguments), but at least a decision is made

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200921/783ae336/attachment.htm>