keyword: ux-ctest

target 2.x for usability test results with prio 2

Concept ideas:
  1) Add smart-tag to function: Insert>Fields>Page Number to create a footer if
desired
  2) Rearange Insert menu to make Page Number more obvious. (related to i60428)
  3) Change default behaviour of Insert>Footer to contain page numbers by default

  1a) Add smart-tag to function: Insert>Fields>Page Number to create a footer if
desired
  1b) Add Insert Page Number dialog to function: Insert>Fields>Page Number to
create a footer if desired
  2) Rearange Insert menu to make Page Number more obvious. (related to 60428)
  3) Change default behaviour of Insert>Footer to contain page numbers by default

in addition: "Page Offset" is quite hard to find. Can we solve this usability
issue in the context of this issue?

Target 2.2

I'd rather use the existing issues for this... If you use this one, make sure to
adapt the summary accordingly.
The offset bug has countless "Invalid" or "Worksforme" and "Duplicates"

see issue 7065 and issue 12138

"The necessity of inserting a footer in order to insert page numbers etc. is not
always seen."

One does not need to insert a footer in order to insert page numbers — one can 
also insert a header, or even insert them directly on the page for a single page 
document, which is why the existing method is right. 

The only thing needed is to make it easier to do. I suggest that the best way to 
do this is to modify the default template to include a footer with a centred page 
number, and a blank header. If "show text bounderies" is on by default (I 
believe it is), then new users won't find it hard to figure out where page 
numbers have to go, and they can just click inside the header or footer area.

An insert page number dialogue is also another way to solve the problem. However, 
what should happen if headers or footers already exist? Clearly they should not 
be replaced. 

If that route is followed, insert fields, page number should not call the insert 
page number dialogue, but should just insert the page number code where the 
cursor is, as it does now. There should be a separate menu item for "Insert Page 
Number."

"The necessity of inserting a footer in order to insert page numbers etc. is not
always seen."

One does not need to insert a footer in order to insert page numbers — one can 
also insert a header, or even insert them directly on the page for a single page 
document, which is why the existing method is right. 

The only thing needed is to make it easier to do. I suggest that the best way to 
do this is to modify the default template to include a footer with a centred page 
number, and a blank header. If "show text bounderies" is on by default (I 
believe it is), then new users won't find it hard to figure out where page 
numbers have to go, and they can just click inside the header or footer area.

An insert page number dialogue is also another way to solve the problem. However, 
what should happen if headers or footers already exist? Clearly they should not 
be replaced. 

If that route is followed, insert fields, page number should not call the insert 
page number dialogue, but should just insert the page number code where the 
cursor is, as it does now. There should be a separate menu item for "Insert Page 
Number."

change target to OOo 2.3

Anything new? 

move to target 2.4 because of insufficient time before 2.3 feature freeze

What's the user experience opinion on the pesala's proposal ? Seems much more
efficient than putting more complicated paths to insert a page number with
footer/header.

Because MS Word has this shortcoming (that MS Word users miss), OOo should quit
its more robust method ???

*** Issue 61661 has been marked as a duplicate of this issue. ***

there is a new extension that offers this missing feature: 
 http://extensions.services.openoffice.org/project/pagination

add spec URL: http://specs.openoffice.org/writer/extensions/InsertPagination.odt

Frank please take over this important issue from mmp. Thank you. We should try
for target 3.0, if possible.  

Double.

*** This issue has been marked as a duplicate of 7065 ***

Closed.