<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - UI: Discourage usage of the to page anchor by hiding it from toolbar/context menu" href="https://bugs.documentfoundation.org/show_bug.cgi?id=135836#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - UI: Discourage usage of the to page anchor by hiding it from toolbar/context menu" href="https://bugs.documentfoundation.org/show_bug.cgi?id=135836">bug 135836</a> from <a class="email" href="mailto:telesto@surfxs.nl" title="Telesto <telesto@surfxs.nl>"> Telesto</a> <pre>(In reply to Heiko Tietze from <a href="show_bug.cgi?id=135836#c4">comment #4</a>) > Even when it's unclear how exactly this works you may try and see what goes on. This started with me reporting <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - Page break moves to next page when text flow over, but leaves image anchored to page behind" href="show_bug.cgi?id=135829">bug 135829</a>. I was pointed to Quote from: <a href="https://ask.libreoffice.org/en/question/199971/multiple-captioned-images/#post-id-199989">https://ask.libreoffice.org/en/question/199971/multiple-captioned-images/#post-id-199989</a> * "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 -> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - Page break moves to next page when text flow over, but leaves image anchored to page behind" href="show_bug.cgi?id=135829">Bug 135829</a> -> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED INVALID - Page frame moves to different position after anchor change and save to DOCX (save & reload)" href="show_bug.cgi?id=136581">Bug 136581</a> -> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Switching anchor from to page to paragraph attaches the image to header" href="show_bug.cgi?id=135838">Bug 135838</a> -> The beloved <a href="http://bugs.documentfoundation.org/attachment.cgi?id=164912" name="attach_164912" title="Example file">attachment 164912</a> <a href="http://bugs.documentfoundation.org/attachment.cgi?id=164912&action=edit" title="Example file">[details]</a> 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 (<a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTABUG - Page break moves to next page when text flow over, but leaves image anchored to page behind" href="show_bug.cgi?id=135829">Bug 135829</a>). 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 ;-)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>