[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 #33 from Telesto <telesto at surfxs.nl> ---
(In reply to Heiko Tietze from comment #32)
> (In reply to Telesto from comment #29)
> > I certainly don't want more decks :-)
> 
> It was meant as subtle hint how we solved the issue: with the Styles
> Inspector deck listing the changed attributes.

Didn't get that; obviously. But still, how do you search a whole document
filled with 'actual needed' and unneeded DF. Walking a 200 pages text line by
line? I personally prefer to avoid a document being riddled by DF advance.
Especially if it can be prevented rather easily (if you ask me). It's certainly
not obvious bold toggled on and off again does result unbold DF instead of
disabled bold DF

The current design makes it unnecessary hard to manage DF/styles. Or to even
correct mistakes.  

So I don't see the The Inspector as a solution the problem at hand. Say PS is
unbold.. you have to walk through the whole text to find snippets with unbold
DF. If toggling bold of would remove the DF, you simply no need to search for
'unbold DF'. Or no-fill highlighting. Removing herculean task. It's would also
make it more noticeable of someone used Strong Emphasis CS with Italic DF or
say bold + Italic or Emphasis CS with bold DF (even without Styles CS dialog
open or Style Inspector deck). 

The toolbar "notification" might be the reason to look at they Style Inspector
(to see what's going on)

FWIW: only giving my view. Currently I seeing more advantages as objections.
I'm  maybe biased as I propagate something.. But propagating and being devils
advocate at the same time rather hard

-> OMG. How much do people think like that when discussing UX?
For the record, this happens far more often than you think. Maybe not saying it
out loud, but in the meantime.. Discussions are not clear. They
Adam/Eve/Benjamin persons are not defined. Even the workflow scenario's not
being written out. So it's hard to know what a Benjamin looks like. So my
representation of Benjamn is different compared to yours. And my Benjamin is
also bit unstable personality, I tend to bend him around into making my point. 
There are people dedicated to UX as a profession (so surely not simple) 

Also the argument of not being used is used pretty often. I complained about
'core' stuff being broken, dismissed by not used by not a problem for the
general user. They use Writer at Wordpad level. Which of course ends up with
the question why did you implement it in the first place. Take track & Changes
or table styles. 

Where we end up who is the actual audience etc.. What the intended user. So we
land in the area of the Business Plan, Marketing Plan. Project/Product vision
etc. The define the target user. TDF public might be somewhat different
compared to they targeted eco-system partners public (yes, of course there is
overlap). As there is no single public (there simply different groups of
users). For Writer itself, and even for the Office Suite as such. A group
mostly uses Calc, Calc being utmost important. Say they use Pivot tables all
day. Others use mostly Writer (being the utmost important part). Others are
designers using Draw.. 

Going into off topic mode
There are reasons for it of course. Table styles being outdated.. not
maintained in years. So GSoC project to make more modern. However
underestimated the complexity etc. so GSoC ended, but the table style project
wasn't finished. So 'half-baked' table styles implementation even more
prominent in the dialog, but not working properly. A topic of awful code; no
budget; no developer responsible; no customer paying. LibreOffice being a
project (not product) (so nobody has to look at it). So everybody looking in
another direction. If you start 'pushing' it becomes a pet bug. Or do it your
self project. 

I still think there is a need to get certain bugs/flaws/limitation on an agenda
under the heading (UX) Quality Assurance (Committee). To prioritize (and order)
certain 'core' issues (UX/bugs). Ideally with 'some budget' or lobbying power
to get certain things done. So a bit more coordinated approach structuring
priority's instead of 'fixing' bugs at random (it's likely more nuanced). Or
waiting until for some magic reason it gets attention (say paying customer).
As they bug tracker is slightly to large having the oversight of what's seen as
 more important and less important (or large/smaller in scope). So Committee is
more or less intended to show certain things are on the table somewhere
(instead of drifting in a large bug tracker).

The (TDF QA/UX) Committee wouldn't replace the current way of working, but more
an addition. to monitor progress on certain flaws and raise attention once in a
while (and doing some lobbying as it know to channels to do that). So more
somewhat like MAB. [Likely wishful thinking; proposing is a lot easier compared
to doing]

-- 
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/20200916/b685b560/attachment-0001.htm>