Bug 135835 - UI: Re-label anchoring to page to anchoring to page number
Summary: UI: Re-label anchoring to page to anchoring to page number
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-17 09:55 UTC by Telesto
Modified: 2021-09-11 07:25 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (413.01 KB, application/vnd.oasis.opendocument.text)
2020-08-31 10:09 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-08-17 09:55:23 UTC
Description:
UI: Re-label anchoring to page to anchoring to page number

I assumed anchoring to page being anchored to page (bug 135829). So moving with page break. To page actually means it fixed to a certain page number

However the label should be adjusted to what actually does to reduce this misunderstanding. I would propose: Anchor to page number, instead of the general 'anchoring to page'. At minimum this will confuse people, so looking it up in the first place :-). 

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

Steps to Reproduce:
1. Open Writer
2. Insert an image 
3. Anchor it to page

Actual Results:
Anchoring to page

Expected Results:
Anchoring to page number (to generate 'confusion' and to make it more specific)


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 6.3.0.0.beta1+ (x86)
Build ID: 5cfac16dbd4af456a7fb6d52c8953c69a72ba2ba
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 2 Telesto 2020-08-17 10:02:46 UTC
The documentation team will love this
Comment 3 Roman Kuznetsov 2020-08-17 10:03:25 UTC
and if I change any numbering in my document? what will happen?

-1 from me
Comment 4 Telesto 2020-08-17 10:30:44 UTC
(In reply to Roman Kuznetsov from comment #3)
> and if I change any numbering in my document? what will happen?
> 
> -1 from me

Feel free for a suggestion for alternative. Not attached to the description as such. To Page is also really confusing. Look at STR of bug 135829. I really expect the image to go to new page with the page break, not stick around. It's not simply 'to page'. It's to, and only THIS specific page.

So alternative might be anchoring to "to this (specific) page". Specific doesn't fit well, I think in they UI and also dubious. Other alternative might be "Lock to page". "Bind to page" (but losing the 'anchor' description here)
 
FWIW, It's not really clear to me how to interpret: "and if I change any numbering in my document? what will happen?" Not sure what you're referring to exactly. Changing page numbering, heading numbering? Adding pages? 
I do get there is some 'issue' with number as volatile factor, so might be misleading too. However it surely not 'evident' description. To page seems to have some obvious meaning; which doesn't apply.

At least for me to page doesn't mean to this, and only this specific page. I won't move anywhere, any time. Maybe 'because it's called anchor" and anchors tend to be dynamic (paragraph/to character/ to frame'). 

FWIW: this is will become more trivial if bug 135836 is honored :-). So happy to stick with 'to p[age' if there are objections from documentation/ and or/ a risk of user confusion as the setting is hidden as much as possible already. 
However it should be changed if the decision is to have that setting present all over the place, IMHO.
Comment 5 Heiko Tietze 2020-08-31 09:27:53 UTC
Disagree with renaming. It might be more precise but adds confusion since To Page is well known. No objection, however, to add a footnote to the help what To Page actually means.
Comment 6 Mike Kaganski 2020-08-31 09:55:06 UTC
(In reply to Heiko Tietze from comment #5)

I also don't think that renaming is good; mostly because of consideration from comment 3. For user, a page number is mainly associated with user-visible/defined page numbering; and that's not what counts here, where just "Nth page of the document, no matter which number was assigned by user". And no, I don't have an idea what would be the best. A lengthy description in help? definitely needed, but wouldn't be read my most ;-)

Also tdf#135836 seems questionable ... at least definitely its scope must be limited to most prominent UI, without removing it from e.g. dialogs, and by no means removing the function at all.

(In reply to Telesto from comment #4)
> I really expect the image to go to new page with the page break, not stick
> around. It's not simply 'to page'. It's to, and only THIS specific page.

Here's a problem of user's perception, when user imagines there's something like "THIS" page, while in reality, from the model PoV, there's only THIS text, and all pages are just dynamically appearing/disappearing depending on viewing mode/formatting/whatever ... pages are ephemeral.
Comment 7 Telesto 2020-08-31 10:09:02 UTC
Created attachment 164912 [details]
Example file
Comment 8 Telesto 2020-08-31 10:29:43 UTC
Bug 135836 and this bug are interconnected. So it's more 'or' 'or' approach

The problems I personally have with 'to page' are
1) What's described in bug 135829
2) And whats happening in attachment 164912 [details] (change the anchor on page 13 to 'to character'

This is from model PoV fine. However a potential source for confusion. And I do see people use To page, where it probably shouldn't be used.

As said I assumed 'to page' meaning 'to this page' in dynamic sense. So if pages are deleted before, it moves. Not To Page as exactly this page (including page position) shown under 2. Where plenty of empty inaccessible pages created to being able to hold the image on page 13. You could say those are 'virtual pages'; and should be visualized differently. Because those are not 'real' pages in some sense. 

I prefer self-explaining options, instead of pointing to manual/documentation. Especially if it initially does what you think it should do. The surprise is occurring mostly at different point in time. 

Point to the manual/help/documentation is always second best, IMHO. And should be avoided as far as possible. The need for lengthy documentation shows something not to obvious and might need improvement.

So would like to list the options, before jumping to improving documentation as last resort.

1) So renaming: some suggestions in comment 1 and comment 4
2) Making To page less prominent. [Removal was only a try out; to check the response]
3) Add here the alternative I didn't think of: ....
Comment 9 Heiko Tietze 2020-09-09 13:00:04 UTC
There is no point in discouraging the use neither renaming the function. It is just one of the features that require to learn the usage. To Page is known as that in all major text processors, so dropping it would be a serious regression.
And ultimately it's also a bit nitpicking to me. Even when it's unclear how exactly this works you may try and see what goes on. Everything beyond needs to be addressed in the help (CC'ing Olivier).
Comment 10 Dieter 2021-09-10 15:39:07 UTC
(In reply to Heiko Tietze from comment #9)
> There is no point in discouraging the use neither renaming the function. It
> is just one of the features that require to learn the usage. To Page is
> known as that in all major text processors, so dropping it would be a
> serious regression.

Heiko and Telesto, this bug report is untouched for almost one year. is there still something to discuss or can we close it as NAB or WF?
Comment 11 Heiko Tietze 2021-09-11 07:25:58 UTC
Roman, Mike and me are against renaming. So let's close as NAB.