[Libreoffice-bugs] [Bug 135836] UI: Discourage usage of the to page anchor by hiding it from toolbar/context menu

Wed Sep 9 19:10:12 UTC 2020

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

--- Comment #5 from Telesto <telesto at surfxs.nl> ---
(In reply to Heiko Tietze from comment #4)
> Even when it's unclear how  exactly this works you may try and see what goes on.

This started with me reporting bug 135829. I was pointed to 

Quote from:
https://ask.libreoffice.org/en/question/199971/multiple-captioned-images/#post-id-199989

* "To Page is very special, and actually is very unfortunate to even exist."*  
While the first four mean that an object is linked to some real fundamental
document elements - paragraphs, characters, or frames, that actually constitute
the document, - the To Page anchoring links objects with something ephemeral,
dynamic in the world of text processing software, to something created and
destroyed on demand: to a page number. Any given page is only existing there
because there's some text that needs to be placed on a page. As soon as the
text gets modified/reformatted, it might take less paper space than before, and
any given page may become unnecessary. Or the text may grow, edits may insert
content before any given text, and so any paragraph may move to following
pages. But objects linked to "page number" would stay where they were, would
not move anywhere; would cause blank pages to be kept - just to let the linked
object stay there. There's nothing in the document that would let these objects
move forward or backward - if you insert more pages "before" such objects, the
objects would "jump" to "previous" pages, actually keeping anchored to the same
"page number 3 in the document, no matter what"."
*"I strongly advocate against this type of anchoring."* 

Not saying the author/ developer did say to hide or remove it; that's based on
my reading of it. And my experience with this type of anchor

-> Bug 135829
-> Bug 136581
-> Bug 135838
-> The beloved attachment 164912 effect (plenty of empty pages). Which always a
'odd' experience
-> The can't be exported to DOCX/DOC (so gets converted)

The fact that To page can be understood differently (Bug 135829). To this page,
instead to this page at exactly this position (within a range of pages). 

So what I tend to say: To Page isn't self-explaining feature. 

Also I have seen number of documents where they to page anchor is used, where
you can ask question why this being done. Not for they 'stick to this page, and
exactly this page' aspect, IMHO. So or people are 'abusing' To Page for
something different compared to what was expected for. In that case I should be
replaced by To Page anchoring 2.0.  

So I would love 'some arguments' why this should be accessible at prominent
place.

It's certainly not obvious where 'to page' stands for. Nor do I actually know
if all major text editors support this (it doesn't seem Word doing this); else
the DOCX export broken....

I listed a number of 'issues'. Why I prefer 'reducing' they prominence. Which
indirectly 'discourage' they use. If it only be in the 'right click' context
menu.

I would love a list of where this is being useful; making sense (for ideally
the largest group). Still not clear that benefits of the 'to page' anchoring
are. And especially where the advantage is for they 'general public'; which I
assume is the main audience. Is there actually an UX analyses of they user
base. And guidelines say visibility of features ? And what they need. They read
the lovely manual/help still not really convincing. My principle is keep it
simple; idiot proof; with advanced features slightly buried.
Or a quick configure dialog to 'tweak' you're LibreOffice as desired (with only
'basic' functionality at the start)  

There is no UX-reach department with telemetry, UX interviews, observations of
X number of users.. This will be again a topic where we are battling blind
folded?

I'm aware that most people around here are more experienced with 'changes' (and
the backfiring). They change isn't major. Nor definitive.. In the sense that
can be customized back into they context menu. It's still accessible from other
dialogs. 

And it's even possible by experiment in Master and see how many complains we
get at beta/rc. Not an invitation to arrange an angry mob. 

Drifting off:  
I assume power users to tweak LibreOffice to their desires.. Not set the power
user features to default so they main audience can struggle with it. As they
didn't ask for it/ require it (or shouldn't use it).

There are certainly 'default' where I question if this being direct to main
public, or more based on personal preferences groups with special needs/ and
desires. Markdown partial or full is a feature you enable, IMHO. Not being
enabled by default (similar as autocomplete). Except if LibreOffice being
advertised as a Markdown or even LaTeX editor in principle. If have the bright
idea of 'we can do this too'; it's a feature which do enable. As long as you
don't intend to be a markdown editor all the way. 

However, I assume my opinion to by pretty clear already ;-)

-- 
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/20200909/a635c995/attachment-0001.htm>