Bug 113246 - UI: Menu 'Insert > Page Number' is wrong: superfluous, error prone, and consumes precious space
Summary: UI: Menu 'Insert > Page Number' is wrong: superfluous, error prone, and consu...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: implementationError
Depends on:
Blocks: Fields-Page-Number
  Show dependency treegraph
 
Reported: 2017-10-18 20:47 UTC by Cor Nouws
Modified: 2017-11-16 09:30 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2017-10-18 20:47:12 UTC
UI: Menu Insert Page Number is wrong.
 - superfluous: it is in the submenu
 - error prone: finding this field should not be too easy; use without preceding step to insert header/footer, make it behave wrong
 - consumes precious space - needs no explanation.

In case there comes a full swing function (see issue #..) for page numbers, that place is of course more than justified. For now. it should be simple removed.
Comment 1 Aschalew 2017-10-19 07:25:06 UTC
NeedInfo

version? Device?
Comment 2 Cor Nouws 2017-10-19 08:01:39 UTC
5.1.x - all OSses
Comment 3 Yousuf Philips (jay) (retired) 2017-10-19 10:46:28 UTC
(In reply to Cor Nouws from comment #0)
> UI: Menu Insert Page Number is wrong.
>  - superfluous: it is in the submenu

1. This assume users know that a page number is a field, which users like Benjamin won't.
2. It is the most used type of field from the fields submenu, so having it in the root menu is beneficial. we do the same for Image (media submenu) and Chart (object submenu)
3. Found in this root menu in competing word processors (WPS, Word 2003, iWork iPages)

>  - error prone: finding this field should not be too easy; use without
> preceding step to insert header/footer, make it behave wrong

1. highly used features shouldnt be hard to find in the menus
2. it is hoped that we can make the entry into a submenu which will do all the bells and whistles (bug 86630)

>  - consumes precious space - needs no explanation.

1. due to space, i moved hyperlink, bookmark and cross-reference into a single submenu and we eventually moved all of them back into the root menu on your recommendation
2. there are alot of things that can be inserted into a document, unlike in a spreadsheet or presentation, and we have to be selective on what goes into submenus based on usage

> In case there comes a full swing function (see issue #..) for page numbers,
> that place is of course more than justified. For now. it should be simple
> removed.

You had suggested the same remove in bug 91781 comment 103 and the same discussion was had there, so for me this is a WONTFIX.
Comment 4 Heiko Tietze 2017-10-19 10:58:12 UTC
Accepting Jays WF suggestion. Sorry Cor, changing menus is always a big deal.
Comment 5 Xisco Faulí 2017-10-20 08:28:54 UTC
Hi Cor, it was moved to REOPENED without explaining why, could you please make you point as least ?
Comment 6 Cor Nouws 2017-11-05 22:02:47 UTC
(In reply to Xisco Faulí from comment #5)
> Hi Cor, it was moved to REOPENED without explaining why, could you please
> make you point as least ?

Sure. maybe Jay can try to repeat is his own words what my arguments are. from his reply I do not get the idea he really understands what I say. So apparently that is not clear enough. If he tries to explain what he understands out of that, I would be able to better explain.
Comment 7 Yousuf Philips (jay) (retired) 2017-11-06 10:18:14 UTC
(In reply to Cor Nouws from comment #6)
> Sure. maybe Jay can try to repeat is his own words what my arguments are.
> from his reply I do not get the idea he really understands what I say. So
> apparently that is not clear enough. If he tries to explain what he
> understands out of that, I would be able to better explain.

Heiko read my arguments and understood them and closed as WF, so if i didnt understand what your arguments are, then you should explain them more clearly.
Comment 8 Heiko Tietze 2017-11-06 10:32:30 UTC
So let me summarize: Cor thinks Page Number must not be in the root menu because it usually needs to be preceded by adding a header/footer. Jay's opinion is that this function is used frequently and other programs have it at root level. (Space is always precious, and the duplication at the submenu could be solved the other way.)

The issue is that our Page Number is just a field and we actually need another function that includes adding a header/footer if there isn't one.
Comment 9 Thomas Lendo 2017-11-09 13:41:29 UTC
(In reply to Heiko Tietze from comment #8)
> The issue is that our Page Number is just a field and we actually need
> another function that includes adding a header/footer if there isn't one.
When this is fixed with bug 86630 then the current Insert > Page Number menu item should be exchanged with the new sub-menu.

So then this bug isn't necessary?
Comment 10 Heiko Tietze 2017-11-09 20:36:20 UTC
Discussed the topic in the design meeting. It wasn't an easy decision as we are split between the alternatives. But in the end it's safer to keep things as they are. => WF