[Libreoffice-ux-advise] [Bug 125268] Wrong text highlight color when export document to doc/docx

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #39 from Mike Kaganski <mikekaganski at hotmail.com> ---
(In reply to Michael Meeks from comment #38)
> This is an old-chestnut. There is a very significant cost in code
> complexity, maintenance and CPU time of walking the entire LibreOffice
> document model before starting to serialize it. Worse - whatever output we
> produce is never going to be completely accurate anyway.

I don't think it's that complex. Just moving the warning dialog from beginning
of the export into "in the middle", when an export model was created, but not
yet written t the file, would allow each export function to output its warnings
to a provided logger. No need to create a dedicated step.

> Worse - this will inevitably produce a long, and impenetrable series of
> highly technical 'stuff' as text (if we had even more infinite resource we
> could link each item to the document somehow) - that is going to be
> frightening and/or not interesting to all of our end-users who just want to
> understand:
> "why does it not work?",
> "Why did you let me get into this situation I don't understand !?" - etc.

Believing that you may always come with an "elegant" solution to problems
caused externally is daydreaming IMO. The list might be collapsed by default,
but not providing it because many wouldn't understand it is demeaning users. In
fact, currently many users just disable the warning that has no value at all,
because it seems to be wrong ("I saved my simple document to DOCX many times,
and never got any problems - it must be a joke!") only to later stumble upon a
problem with a thing that they never used before, and come here or to AskLibO
with "you ruined my many hours of work without warning!". If instead we only
output the dialog when there's actual dataloss, like here, or at least make it
"we didn't identified specific issues, but still there might be some problems"
when nothing specific was identified, it would provide value to people.

> I'm not in the UX team; but I would be staggered if this was thought to be a
> good idea. Almost certainly it is far easier to solve the problem in a more
> elegant way.
> 
> As an example: if you load a DOCX file - then we can safely assume you will
> save as DOCX (this covers some vast proportion of the use cases) - and so we
> can hide the UI options associated with doing more powerful ODF supported
> things =) On ODF export to DOCX people expect some format shifting problems,
> so we select the nearest feature, and the nearest matching hue for this case.

Which would effectively mean "let's implement MS Word for those who load DOCX;
Pages for those who load .pages, etc.". That would become a nightmare of
multiple inconsistent UIs, each trying to satisfy some subset of users, and at
the same time dissatisfy e.g. users who receive a DOCX and are editing it to
save as ODT.

-- 
You are receiving this mail because:
You are on the CC list for the bug.