Issue 43146 - Users should have the option to have the cursor position remembered when opening a document.
Summary: Users should have the option to have the cursor position remembered when open...
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: 680m80
Hardware: All All
: P3 Trivial with 28 votes (vote)
Target Milestone: ---
Assignee: eric.savary
QA Contact: issues@sw
URL: http://specs.openoffice.org/appwide/o...
Keywords: oooqa
: 43993 44993 47364 48430 48871 51199 51578 51770 52219 62802 (view as issue list)
Depends on:
Blocks:
 
Reported: 2005-02-19 18:56 UTC by peschtra
Modified: 2013-08-07 14:41 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description peschtra 2005-02-19 18:56:45 UTC
I would like to have the option to have the cursor position remembered as OOo 1.1.x.

I am filiing this because that is how I was told to proceed. This started with
issue #41136. I was told that this behavior could not be changed by v2 release.
Also I am told that this is the desired behavior (not remembering the cursor
position.)

Now, I understand other office apps don't have this option, but OOo did, and
that is what helped make it great. Many people I know like this feature and I
have talked to very few that don't. Further more, having the option to restore
cursor position (as in 1.1.x) makes everyone happy.

If you read the spec file, (is that what it is called?) which I have provided
the url to in the url box above, you will see scenario involving two people that
share a document. The rational for making this change in OOo was that Mary might
might think Peter is lazy for not moving the cursor back to the top of the
document when he is done editing if she opens it and the cursor is in the middle.

There are two *fundamental* issues with this scenario:

1) It doesn't address the need of Peter, per se. Perhaps he is editing a 150
page document and has to do it chunks and isn't able to remember where he left
off. Perhaps he is editing several large documents, and he relies on the program
remembering where the cursor was to do his job. He is now SOL.

2) The scenario presented was solved for in 1.1.x. Mary could unclick the
/restore editing view/ option in her version of OOo and Peter could leave it
checked. Wow, wouldn't that be nice, the best of both worlds!

Now we have an OOo that only opens at the top with no shortcut to jump to the
last cursor position. Not a good alternative.

I urge whoever makes this decision to change the behavior back as as possible in
whatever version it can be done in.

Thank you for your time.
Comment 1 dcarrera 2005-02-19 21:26:57 UTC
I think that remembering the cursor position is a *very* *useful* feature. The
point is not that it is impossible to get by without that feature. If that was
the standard, then we'd have almost no features. Most features we add are added
because they *help* and are *useful*.

Thanks to the OOoAuthors project, I regularly work with documentation, and I
find this feature very useful. It allows me to go back to a document and
continue where I left off.

What am I supposed to do now?
Write some kind of text that says "((daniel -- continue here))" ?

Don't you see some problems with that approach? For one, it's an ugly kludge for
something that used to be simple. Second, it's adding text and altering the
pagination of a document for no good reason.

Is it possible to do? Yes, this isn't the end of the world. But that's not the
point. The point is that it's a useful feature.

Cheers,
Daniel Carrera.
OpenOffice.org volunteer.
Comment 2 dcarrera 2005-02-19 21:28:56 UTC
Here's a suggestion:

Can this feature be made into a setting? You can have it default to "off", but
at least allow people to set it back to "on" at some point.

Please?

Cheers,
Daniel
Comment 3 lohmaier 2005-02-19 22:19:50 UTC
I'll just copy my comment from issue 39486:

Don't keep it. Revert the "feature" to the old behaviour. The user-scenario
itself is a "joke".

If Mary doesn't like the restored view, why doesn't she simply turn off "restore
editing view"?

Does Mary really add her writing to the top of the document? I doubt so. She
will add her text somewhere in the middle or at the bottom, but only in rare
cases at the top.

If you think the behaviour has to be changed, then add the option "restore
cursor position" and turn it off by default so that it can be turned on at least.

Why do you impose annoying actions on the user (pressing the non-yet-existing
shortcut?) 
There is already a shortcut to jump to the start of doc <ctrl>+<home> - why not
have Mary press use the shortcut?

You really should have listened to UFI :-(
Comment 4 peschtra 2005-02-19 23:51:55 UTC
In response to Daniel's second comment, I would like to again point out that his
suggestion is the old behavior.
Comment 5 richlv 2005-02-21 07:01:48 UTC
this really is a useful feature that i got used to - but it felt so natural that 
it was irritating to work with 1.9 builds.

one of arguments to remove this setting - reduce options in gui. the problem is, 
as a result a feature is lost. it was functional, many people used it.

this should be brought back to 2.0 (the sooner, the better - so that no 
fundamental changes are made that make it harder to reimplement)
Comment 6 michael.ruess 2005-02-21 11:25:01 UTC
MRU->ES: you are named as QA-rep. in the spec. Please clarify with MMP, what to
do with this.
Comment 7 eric.savary 2005-02-21 15:10:14 UTC
it's a duplicate of issue 39486.


*** This issue has been marked as a duplicate of 39486 ***
Comment 8 eric.savary 2005-02-21 15:11:23 UTC
closed
Comment 9 richlv 2005-02-21 15:20:22 UTC
um. duplicate ? again ?
maybe my english is _that_ bad ?
i believe this not a duplicate, because issue 39486 deals with a manual key 
sequence (which is a new feature), this one - with a feature that was available 
before but for some reason has been removed completely.

i believe also that ongoing discussions in issues and mailing should have 
cleared the confusion about this functionality.

could this be reconsidered, please ?
Comment 10 eric.savary 2005-02-21 15:30:09 UTC
I believe this is all the same. It's about the whole design of this feature:
- should it come back as it was?
- as a check box in the options?
- what should be the default?
- should there be a shortcut?
- what should the shortcut do by default (restore view/top of doc)?

Thus it's a duplicate.
Else, it's better to concentrate the action on 1 task, but IZ is not the right
place anyway to discuss features (discuss or users mailing lists)
Comment 11 peschtra 2005-02-21 17:08:51 UTC
NO!!! This is NOT a duplicate of 39486!

Specifically, 39486 is this (the summary) "Implement a shortcut to jump to the
saved cursor position." This not what this issue is.

In this issue, I am asking for the old behavior back, so that when I open the
document it just starts were I left off. Read the conversation on that issue and
the conversation in #41136 and you will see.

I do NOT want just a shortcut, I want the 1.1.x behavior back.
Comment 12 eric.savary 2005-02-21 17:10:23 UTC
Reassigned
Comment 13 peschtra 2005-02-21 17:21:14 UTC
@es comment #2 --

It is not one big issue. How many times have we been told, one issue per issue,
not to try to lump the whole thing together. This is the difference, if you read
the spec (in the url I provided) it says that v2 the only option is the doc to
open at the top and that there will be a shortcut key to restore the last cursor
position.

In the snapshots, you can only open a doc at the top (as expected), but there is
not shortcut key in the snapshots, hence #39486 is a DEFECT. Something that is
supposed to be happening isn't. If we bundle everything into that one issue (the
fact the we want the behavior reverted) and it is fixed, then the whole rest of
the conversation is lost. That is why you file two issues when you have two issues.

This issue, 43146, is a request for enhancement. We want a different feature we
want the program changed. This feature could be marked as won't fix. So, if we
lumped it with 39486 and it got marked won't fix, then the shortcut also
wouldn't be added.

Do you see the difference?
Comment 14 michael.ruess 2005-03-03 13:22:32 UTC
*** Issue 43993 has been marked as a duplicate of this issue. ***
Comment 15 norbert2 2005-03-03 13:32:18 UTC
I agree dcarrera: A setting for this behaviour would be the best solution.

Especially when editing big documents (I plan to write my diploma thesis with
OOo Writer) I really would like that Writer opens at that position where I have
worked  at last!

Please check if such an option could be targeted to OOo 2.01.

I'm really annoyed of having lost this feature!
Comment 16 norbert2 2005-03-03 13:37:02 UTC
Some of you may think this is not a big issue. But you must see this from the
user's point of view
Users save the document. And later they open it again to continue editing the
document...

So please implement an option to allow users to enable old behaviour...
Comment 17 norbert2 2005-03-03 13:39:47 UTC
(Maybe an interesiting alternative would be to keep old behaviour and adding an
option when saving to not store the cursor position...)
Comment 18 norbert2 2005-03-03 13:43:18 UTC
(forget my last comment. this could be achieved by setting the cursor at the
document's beginning before saving :-) )
Comment 19 baernie 2005-03-11 01:54:56 UTC
I had the same problem (not saving cursor position) with OOo 1.0 and helped 
myself by painting red the last written word. So I could find it easier after 
re-opening the document and scrolling down. 
In OOo 1.1.2 the cursor position was saved and I was able to finish my 
dissertation (about 100 pages) without searching for the last position (because 
of lots of images and few memory scolling through the document took about 5 
minutes!). 
If the new standard behaviour will not be changed back, I'll keep on using OOo 
1.1.2 (or 1.1.4/5 perhaps) because this feature is essential for larger 
documents! I think there are more people using WRITER than IMPRESS or BASE, so 
the great advantages of OOo 2.0 could be drawn back by this. (and other things 
like the quickstart-"enhancement" #30853)
Comment 20 michael.ruess 2005-03-14 15:15:25 UTC
*** Issue 44993 has been marked as a duplicate of this issue. ***
Comment 21 othr 2005-04-29 11:13:28 UTC
Would very much like to retain the option where the cursor moves to the 
location of the last edit when a file is opened. Like 1.1.0.

For me, this would give OOO a significant edge over MS-Word.
Comment 22 stefan.baltzer 2005-05-09 13:29:43 UTC
SBA: The old behavior "vanished" on purpose. See issue 20333 for details.

In my opinion, this is about "Editors vs. readers (of Writer documents)":
(1) The EDITOR prefers to keep on writing in the last position
(2) The READER prefers to read a document from the start.

I believe that "The BIG average" use of a Writer document is "More often read
than edited". Thus it makes sense to have a "reader friendly" default.
Reassigned to MMP.
Comment 23 othr 2005-05-10 06:17:08 UTC
Glad to hear the functionality is being reconsidered. The default can be start 
at beginning. But useful to have an option to change it. There seem to be some 
users who feel passionate about this :-)

I don't know anyone who uses MS-Word or OOO-Writer _primarily_ for reading 
docs. Email, html or pdf is the more usual method for reading, in my 
experience :-) 
Comment 24 richlv 2005-05-10 15:05:29 UTC
sba, it makes sense to change the default if majority of users would prefer 
other choice than current default setting. in this case a feature has been 
completely removed, so (supposedly) minority that preferred old behaviour tries 
to make some noise and get it back in oo.org :)
Comment 25 rittmey 2005-05-10 17:05:51 UTC
I agree with othr. In my experience OO.o is used for editing and
presentation/reading is done via exported PDFs. This might be different in big
companies, but why would I pass a document to s.o. which they can change if it's
not for editing? I simply do not get it.

If I as editor decide that my document should be read from the beginning (for
example because I offer a basic Calc-Sheet for download on the internet), than I
 should have an extra option to set the "start reading from beginning" flag (in
my opinion the best place would be in the file properties-dialogue).

But I guess in 99 per cent of all cases the opener of a document is just
continuing to edit a document of his own.
Comment 26 eric.savary 2005-05-12 10:48:10 UTC
*** Issue 48871 has been marked as a duplicate of this issue. ***
Comment 27 peschtra 2005-05-21 21:15:51 UTC
*** Issue 48430 has been marked as a duplicate of this issue. ***
Comment 28 cno 2005-06-05 10:06:49 UTC
pls. bring back this functionallity, that is of so much use for me in 1.1.x, back

Stricking Ctrl-Home for someone needing to 'find' the start of a document, is
much and much faster than looking for position 'x'
So people using OOo as a powerfull editor etc, as I also do, will (in general of
course) sure be pleased with the 1.1.x behaviour.

Thank you very much!
Comment 29 cno 2005-06-05 10:07:56 UTC
pls. bring this functionallity, that is of so much use for me in 1.1.x, back

Stricking Ctrl-Home for someone needing to 'find' the start of a document, is
much and much faster than looking for position 'x'
So people using OOo as a powerfull editor etc, as I also do, will (in general of
course) sure be pleased with the 1.1.x behaviour.

Thank you very much!
Comment 30 jehojakim 2005-06-05 15:21:04 UTC
To my opinion the bias towards the reader, vs. the writer, is wrong. Indeed,
chances are that there are a lot more readers than wirters of a document. But,
mostly, readers will read the document only once on the screen, and from my
experience readers tend to print the document rather than read it on the screen
at all, especially with larger documents - for which the whole issue is the most
important. Writers and editors, however, handle the document many, many more
times. So the disadvantage for writer/editor of the cursor not being positioned
on the last position is much greater than the disadvantage for the reader to
have to jump to the top of the doc.

So, my votes are for the old behaviour.

Cheers, jehojakim
Comment 31 philippasveer 2005-06-06 19:20:30 UTC
I would like to keep the possability to get to the latest position/mutation by
opening a document in OOo writer. The reason is that I usely write very long
documents that I mostely work on for months. Therefor it is for me essential to
keep that possability also in OpenOffice.org 2 and further. I would appreciate
it iw you would put this function in OpenOffice.org 2 and further. Thank you.

With kind regards,
Philip Pasveer
Comment 32 matthias.mueller-prove 2005-06-08 12:29:43 UTC
retarget to OOo 2.0.1
duplicate to i33307

*** This issue has been marked as a duplicate of 33307 ***
Comment 33 matthias.mueller-prove 2005-06-08 12:45:11 UTC
closed; to be followed up in i33307
Comment 34 othr 2005-06-08 12:47:04 UTC
hmmm... 33307 is about a new shortcut... Better than nothing, but not quite 
the same as this issue which is about something more closely resembling a 
former functionality. 

I note that we already have a shortcut to return to the beginning of the 
document :-)

Perhaps I should ask: If you are going to store the last-save position (ie 
even with 33307), what is the problem with having an option to do this 
automatically? Is it a big memory or architecture problem?
Comment 35 richlv 2005-06-08 12:55:50 UTC
erm. we already had this issue closed as duplicate to issue about a shortcut 
(and this is not about a shortcut).

i don't think it's worth to reiterate, comments to this issue since Mon Feb 21 
08:11:23 -0700 2005 reflect opinions well enough.

it seems that this issue will get burried beneath issues about adding some 
shortcut, not resolved the way users want it - by getting back the removed 
functionality.

f this is not the case, i would appreciate more verbal comments why this is 
considered a dupe and closed - and what is the current view regarding position 
restoring.
Comment 36 matthias.mueller-prove 2005-06-08 12:57:46 UTC
The best solution would be
a) optimal view with no shortcuts for reader (someone who opens a document for
the first time) and author (someome who has opened and edited the document quite
recently.)
b) no shortcuts
c) no additional option

Point a) is the hard part -- to detect the context under what a document is
opened. As long as we don't have a feasable solution for this I recommend to
treat the readers more politeley than the authors.  Point b) is the price that
authors have to pay for that. Point c) imposes a solution for power-users that
is totally out of sight for the average.
Comment 37 cno 2005-06-08 13:03:18 UTC
If I understand the specs-doc correct, the point is:
- avarage user is confused about starting in the middle of a doc;
- power-user has no problem using Shft-F5 to return to latest cursor position.
I can happily live with that.

Furthermore the specs-doc says something about an option to make default
restorage of cursor position (& view) posible. But I couldn't get the clue on
whats proposed to do with that idea.

Comment 38 matthias.mueller-prove 2005-06-08 13:09:59 UTC
The option "Editing view" in OOo1.1x (Tools>Options>OpenOffice.org>View) was an
all or nothing option. All modules open the document on the first page or all
modules open the documents on the last edited page. This was not good. Section
6.6. says that this options should be removed. 
I suppose this has to wait until OOoLater. Until then this option has no effect
on Writer and Impress. But still on Calc.
Comment 39 richlv 2005-06-08 13:10:04 UTC
and what's wrong with
- option to choose wether automatically restore editing position;
- shortcut key for those who want restoring only ocasionally.

in this scenario everybody is happy - this option would be turned off by default 
and only those who want this functionality would enable it.

it's been argued in this issue a lot that most people don't read long documents 
onscreen, they print them out; usually creating/editing the document requires 
more work and iterations of opening/closing than just reading it; that there 
already is a shortcut to go to the beginning of the document (and most people 
already know what ctrl+home would do).

it feels like these arguments are just ignored without even an attempt to 
disprove them.

i feel so disappointed that i would have tried to see into this myself already - 
if only i'd knew how to code. as i do not, i can only try to reasonably justify 
my view. and i really believe that oo.org will lose by removing this 
functionality.
Comment 40 matthias.mueller-prove 2005-06-08 13:22:33 UTC
This might work as an interims solution. But from my point of view it is too
much effort for 2.0.1.
We have to treat different modules differently, and sometimes an author becomes
a reader and vice versa. A general option does not address this issue.

I like to see a shortcut as specified for 2.01 and hopefully an elaborate
feature for OOo 3.
Comment 41 matthias.mueller-prove 2005-06-08 13:23:36 UTC
set parent
Comment 42 cno 2005-06-08 13:34:35 UTC
As far as I'm aware, not mentioned before, is the great advantage for using
templates, when the cursor is at the past position on opening a document.

Imagine: you save the template with the cursor is on the position where the user
has to start with typing .. the cursor is just there when a new doc is created
from that template. That ís handy! 

Can this be achieved in/with 33307??
Comment 43 matthias.mueller-prove 2005-06-08 13:45:46 UTC
As far as I expect: yes. But I doupt that all template users know the shortcut
to jump to the saved position. So we have a bad solution for your scenario.

Do you know actual users/companies who rely on this behavior?
Comment 44 cno 2005-06-08 14:01:32 UTC
Long time ago, when I worked on automating corporate styles in MsO, we had a
bookmark and a piece of code to start at the start position ;-)

Not difficult to implement in OOo, however for the few projects we did until
now, there just was no need to do it, because of the default behaviour.

Furthermore, that only works when combining templates and macro code. 
For many relative easy works, where no macro´s are used, it's just fine when the
cursor is there.
Comment 45 richlv 2005-06-08 14:15:02 UTC
"This might work as an interims solution. ... A general option does not address 
this issue."

i would like to restore editing position in all kinds of documents. actually, 
the fuss is not about adding the option, it's about removing of functional 
option and not providing that envisioned improvement where office suite would 
find out wether person wants to read the document or write at the last position.

why not leave this option until optimal solution is developed ? i don't want to 
go into bad analogies land, but it's like removing a handbrake because sometimes 
people can use it while driving and that migh cause undesirable effects.

software should help users in their work. usually i have to work with several 
documents. it is very handy if i have the latest text just after opening the 
document, it helps me to restore my ideas and get on with the work itself. 
sometimes i even don't remember that i have left a sentence in the middle of the 
document unfinished - and only when i have it in front of my when opening i 
remember that there is something unfinished.

so, shortcut key is not sufficient for my workflow, where i depend on software 
to remind me where i left my work. and why not ? this way i can concentrate on 
other things immediately instead of trying to remember which was the sentence 
that was unfinished in this 200 page document.

now there is no replacement for this feature. removing functionality and hoping 
that something a lot better will be implemented usually results in no 
improvement or it comes after several years. if there is a need to restructure 
this feature, shouldn't it be done so that it does not disrupt existing 
workflows ? in that case improvements would be warmly greeted.
Comment 46 bernhard 2005-06-08 16:23:41 UTC
It's senseful to reduce the amount of Issues by marking them as duplicates and
closing them.

But in this case you do know the difference between this issue and issue 33307:
We want to keep the opening behaviour of OOo 1.x  (the checkbox may be checked
off as standard), a shortcut would be a workaround - if it would work by now!

So it is *not* a duplicate. If you would have closed it with the real reason,
there would be much less complaint (probably we would have to open a new issue
as "feature request"). 

In my eyes the real reason is something like that (it's just a suggestion, but
I'ld like to know if I did understand you):

1) There have been complaints about the old opening behaviour by readers of
writer-documents (ACK)
2) Turning off the checkbox as standard solution disables the feature in calc-,
impress- and base-documents as well. The reader of the writer-document wants to
open the other document types where he has left them. (Otherwise he wouldn't
have a problem with unchecking the option - I think, he would open the other
documents at the beginning without many complaints)
3) People writing longer documents know better than the "readers" how to move to
the point where they want to start. So it's more senseful to ask them to use a
shortcut than the others. (ACK)
4) The implementation of the shortcut has been too complex to include in 2.0
(refer to #33307), but the "readers" must have their optimal behaviour (starting
writer documents at the start, others at other positions) in 2.0. (Do you worry
about loosing new users?  - the power-users wouldn't go to MSO anyway!)

Closing the issue with these reasons could be understood (without agreeing to),
but closing as duplicate is wrong IMHO.

Just two more points to discuss:

1) The point of starting template-based documents is a new one. Here "simple"
standard-user could have an advantage of the old behaviour, but by now we don't
know how often it is used.

2) While it is clear, that the shortcut can't be implemented in 2.0 final, it
should be the better compromise to go back to the old behaviour with turning off
the checkbox as standard. I assume that the "simple" standard-reader doesn't
mention the problem that calc-, impress- and base-documents (if he uses them at
all) open at the beginning.
For all the people using writer with longer documents there must be a
possibility to begin where they stopped at the last session (without bookmarking
every time before saving...)

I don't see why the standard-reader can't open all documents at the beginning -
or decide to open all (including writer) at the last edited position and check
the option. Who is able to check an option is able to uncheck it as well (or use
an *existing* shortcut for temporary movement to the beginning).

Perhaps there is a reason I don't have in mind - please let me know!

Bernhard


Comment 47 matthias.mueller-prove 2005-06-08 16:54:49 UTC
Hi gang!
so many good arguments - I'd like to tune in and sing the song of the good old
times. Cut. A general option for "advanced users" is not sufficient - IMO. Every
user is reader and of received documents and editor of her own. Roles of reading
and editing change and we cannot distinguish between the situations. 
Currently the spec defines a new behavior that was implemented partly due to
engineering constraints. The last view position is saved in OOo2. OOo2.0.1 will
add the shortcut to jump to that position.  i33307 is the task to implement this
postponed aspect of the spec.
To open the first page for Writer & Impress plus a shortcut is a better solution
for the majority of use cases. 

The behavior in OOo 1.1x was half right and half wrong. With the option "Restore
Editing views" it was half wrong and half right. If this task i43146 is about to
get the 1.1 bahavior back then you do not have my support. 

I propose to continue as specified and to develop ideas how we can better
support the editing use case for OOo3. I cannot describe it better than richlv
did. Software should support the work of the user. I, as user experience
engineer, have to consider all styles of working with OOo. And that includes
authors and users sharing documents.  In this case I fight a little bit more for
the readers.

Suggestion:
i43146 is no longer a dup of i33307
Target would be OOoLater
We discuss what this task is about. 
Comment 48 bernhard 2005-06-08 17:56:28 UTC
Hi mmp, *

you wrote:
> Suggestion:
> i43146 is no longer a dup of i33307
> Target would be OOoLater
> We discuss what this task is about. 

For me, thats all ok. But what would you think of re-opening? ;-)

To your arguments: 

There is nobody longing for the "good old times"!
The point was to disable the feature *before* we have a sufficient workaround.
Not having a possibility at all is IMHO the reason why so many people voted for
this issue, a shortcut is not the same - but it's better than nothing.
As a temporary solution I can agree to the shortcut, in the long term there
should be a document-dependent behaviour:

a) standard: doc is opened at the first page

b) if the user wants to restart at the last position he has to to two things:
   - mark a specific option (when *I* reopen this doc, it shall start at last
position)
   - make sure that the user data is used for the document properties
   the program has to save a new option in the properties to find out, if the
current user ha marked the re-opening option.

c) if the user wants the doc to open at a special position every time it is
opened by any user, it shold have an option "reopen at bookmark" (should be
usable for templates as well)

It's just an idea - not finally thought through, but perhaps a starting point.

Cheers,
Bernhard
Comment 49 dcarrera 2005-06-08 18:25:44 UTC
cornouws touched on another example of why the current (1.1) functionality is
important.

At OOoAuthors we have a template for the user guide. The first page is taken up
by the chapter cover. The second contains the license information,
acknowledgements, etc. So we have to put the instructions on the third page.
These instructions tell the contributor what to do before starting the chapter.
The volunteer has to edit some fields, and must be aware of some OOo bugs and
work around them. We also provide basic writing information and links.

We save the file so that the first thing you see is the instructions. This
simple choice has decreased confusion among volunteers to almost zero.

I honestly think that the old behaviour was better. And that the proposed
"solutions" are worse than what this issue says.

Daniel.
Comment 50 lohmaier 2005-06-08 18:34:35 UTC
reopen issue.

A few comments:
> To open the first page for Writer & Impress plus a shortcut is a better solution
> for the majority of use cases. 

I strongly disagree. You write that everyonw is both reader and editor. True.
But the majority of the users are editors more often than readers. And for the
readers-case there is already an easy shortcut: <ctrl>+<home>. In the unlikely
case that the users is mainly a reader, there's the option [ ] restire editing
view. The all-or-nothing approach is not wrong for the reader. If he doesn't
want the cursor-posistion, he doesn't want the zoom-level and other related things.

> If this task i43146 is about to get the 1.1 bahavior back then you do not have
> my support.

The change you did doesn't have the support of many users. A dilemma. But be
assured: This one is not about the old behavioiur, it is about having the
possibility to open documents with remembered cursor-posistion by default.

Whether you introduce another option [x] always restore editing position or do
it differently is of no interest.

In any case: This one is not a duplicate. If you insist on your new design, then
close this one as wontfix (and p*** of lot of users)...

The "optimal" solution would be:
* OOo is able to read the user's mind and act accordingly. This is not possible.

It is far easier to have the readers either uncheck the existing option or have
them press a shortcut than doing it the other way round.

> I cannot describe it better than richlv did.

Well, richlv want OOo to jump to the saved cursor position on load.
Comment 51 g.marxen 2005-06-08 20:14:30 UTC
"... Software should support the work of the user. I, as user experience
engineer, have to consider all styles of working with OOo. And that includes
authors and users sharing documents. ..." 

I think, mmp is wrong with his opinion about the "old" feature. It is extremely
helpful for authors. 

Writer is a "word processor" (text processor) to write (long) text documents,
not to read them. Normal users read texts when they are printed (or exported to
pdf). It is a good behaviour, not to distribute documents, which can contain
macros or other active content. 

"Software should support the work of the user" and absolutely most work with
writer is to write documents! And this is best done with the old feature! 

I work with Writer, FrameMaker and Word and I prefer Writer because of this
"old" feature, which the other software does not have. 

Please restore it! 
Comment 52 dcarrera 2005-06-08 20:41:50 UTC
Another consideration: what happens when someone doesn't know the shortcuts?

You can't expect everyone to know the shortcuts, or even most people. Shortcuts
are inherently hard to remember, and even harder to find out (how do you expect
someone to learn about the Shift+F5 shortcut, or even Ctrl+Home?).

If you don't know shortcuts, going to the beginning of the document is really
easy. Just grab the scroll bar and move it all the way up. On the other hand,
what if you want to work where you left off? For even a short 10-page document
it can be very frustrating. For a larger document, or a document where you're
not even sure if you were editing that document or not.

So, changing the behaviour in a way that makes life very difficult for the
editor and only marginally better for the reader seems like very bad usability
design to me.

Add to that, the fact that the editor spends more time on the document tan the
reader. And when the editor is finished, and wants to send the document to the
readers, he can just go to the first page and re-save. That's what I currently
do with OOo 1.1.

Cheers,
Daniel.
Comment 53 cno 2005-06-08 21:18:02 UTC
Furthermore: if I do send a document to others in an editable form, and do not
convert it to PrivateOpenXML (.doc), I can be so wise to place the cursor in
top, before saving.
Comment 54 peschtra 2005-06-09 02:06:57 UTC
I filed this issue a while ago, and it is so clear to me that I don't understand
some people opposition to it.

Question to mmp: Who is disadvantaged by the 1.1.x behavior?

The scenario provided (in the spec) is laughable. I have already elaborated on
this, so I won't repeat myself.

I am big fan of the arguments along the lines of OOo is not a format intended
for reading documents. Writer is text editor. There a readers for documents out
there. PDF is a good format, ebooks I guess work, but Writer is not really
intended for reading, it is for editing.

I think Daniel's point is also very good. Going to the top of a document sans
shortcut is SUBSTANTIALLY easier than finding where you left off.

I am not a big fan of the idea of making the feature document dependent. I think
it is interesting, but I don't want to have to remember everytime I make a
document to check the box. I suppose if I could edit my default template to have
that box checked, I would survive. :)

Mostly, I would like to have someone give me a real circumstance where the 1.1.x
behavior is harmful to productivity. I can give (and others have given you)
several examples of where the 2.0 behavior, even with a shortcut, hurts
productivity.

The only way I would say we could improve upon 1.1.x is to clarify the checkbox?

I mean, why is this feature okay for Calc and not Writer?

Sorry, I am rambling, but it is just so clear to me that this is a good feature,
something that propels OOo over MSO and a feature that will require me to keep a
copy of 1.1.4 on my computer for my editing work until 2.0 has an acceptable
feature.
Comment 55 matthias.mueller-prove 2005-06-15 12:30:45 UTC
Hi gang,
here's what I propose for OOo 2.01
a)
We will implement the shortcut Shift-F5 as specified. (i33307)

b)
IF author of the Writer document and current user of OOo (Options>OOo>User
Data>FirstName+LastName) are the same THEN open the document at the recently
used position.
IF EITHER author of the Writer document is not set OR the current user data is
not set THEN open the document at the first page.
Shift-F5 can be used anyway.

Please let me know what you think.
Matthias
Comment 56 cno 2005-06-15 12:50:14 UTC
Hi Matthias,

Sounds good to me.
A handy and natural distinction between user and reader.

And uhh, is there any possibility that our life in between 2.0 & 2.01 is made
easy as well :S  At least with Shift-F5?

Comment 57 richlv 2005-06-15 14:21:49 UTC
sounds reasonable, though maybe we should compare also 'modified' field with 
current user information ?

for example, if i receive a file to work on, resave it, i would like to remember 
position for it (as i have become an editor now), but the only place my 
information is (as far as i can see) - in 'modified' field.
Comment 58 dcarrera 2005-06-15 17:02:15 UTC
Hello Matthias,

I like the idea, it's a clever solution. Though I like richlv's suggestion even
better. It seems to do something closer to what you intended.

But in any event, if you use the Author field as you suggested I'll be very
happy. If you use the last-modified field as richlv suggested I'll be happier yet.

Thanks!

Cheeers,
Daniel.
Comment 59 peschtra 2005-06-15 19:55:44 UTC
I think that is a fair compromise.

I would still like to see the option implemented in the future to go back to the
world of 1.1.x. Should we open a new issue for 3.0 once this one is resolved?
Comment 60 othr 2005-06-16 01:26:02 UTC
Author field and last modified fields are good ideas, I think, plus shift F5 
(same as MS-Word). This would keep me happy.
Comment 61 Mathias_Bauer 2005-06-16 08:14:22 UTC
Matthias, that sounds like a nice idea.
I'm still thinking how that fits to other use cases where the "old" feature came
in handy:

(1) Creating documents from a template where editing in the new document always
should start at the same position. 

(2) A workflow where a document is passed between users that consecutively add
their contributions.

Of course the shortcut would at least enable them to do so but it still looks a
bit tedious to me.

I'm still wondering wether we should work on the document side.
Documents can leave the application in different ways: they can be sent out by
email, they can be saved or copied. 

At least the first use case can easily be handled by not providing restore
information at all when we create the copy that is sent by email (we always
create a copy for various reasons), but we can also provide additional meta data
that tells OOo not to use existing information.

The workflows I described wouldn't profit from Matthias' suggestion, but we
could enable them by providing a document setting (not a global one as in
OOo1.x) that tells OOo "always restore cursor position automatically", at least
if the document is not opened read-only.

I admit that this is not thought to the end, but I wanted to point out that
there still could be room for improvement.
Comment 62 bernhard 2005-06-19 02:36:56 UTC
Hello Matthias, *

comparing author and users data is a good idea, but as richlv 
suggested "modified" should be taken into account. In my eyes the author and 
all editors (listed in "modified") should be compared to the users data to move 
the cursor to the last saved position.

If a former editor wants to start at the beginning, he does know the shortcut 
<CTRL><HOME> - in the most cases the automatism would work quite well.

Just one thing to mention: If I'm not wrong, the standard behavior is to 
set "document modified" status when a doc is printed (Options - OOo - General). 
I have the checkbox unchecked, but I think I dit it manually a lot of time ago.
Perhaps this should be standard - just to avoid confusing Mary.

For mba's reflections there should be a solution (at least in a later version).
His first point (opening template based documents) seems to be quite important 
for some users.

After you (mmp) asked for users of that feature I posted the question on the 
german users-list and got answers from people using it in everydays work: 
One told about templates with input fields where it is convenient to start the 
free text at the right position after filling the input fields.
(http://de.openoffice.org/servlets/ReadMsg?list=users&msgNo=33143)
Someone else mentioned 8 templates he and his staff uses every day.
Others just agreed to the necessity of that feature.

Perhaps there could be a checkbox in the "save templates"-dialogue (File - 
Templates - Save) you have to check to open new documents at the cursor 
position.

For mba's second example (workflow with differnt editors of one document) I 
don't have a solution - if there will not be the document depending feature mba 
mentions, <SHIFT><F5> must be used (or a simple macro striking this shortcut on 
opening the document).

Bernhard
Comment 63 othr 2005-06-20 09:12:33 UTC
bedipp's survey has confirmed the importance of a document properties setting 
for "move to last edit position" for templates. 

However mba's idea doesn't apply only to documents saved as templates. I once 
worked as quality manager for a consulting firm with a couple of hundred 
staff. Many of our QA docs opened several pages into the document (ie after 
the table of contents and introductory sections).

Another example is reports: the Executive Summary/TOC/Introduction (ie the 
first page of really useful information) is often preceeded by a title page 
and a revision control page. A document setting to open at an author-defind 
location could be useful in that situation, too, especially as we move more 
deeply into the electronic age (although I have noted above that, in my 
experience, most documents are circulated as pdf - Acrobat's document-specific 
setting to automatically display the bookmark pane is useful in that regard).
Comment 64 matthias.mueller-prove 2005-06-22 10:46:02 UTC
I start to have fond feelings for this thread! Anyway. Thanks for the hint to
test for the "modifying author" first. This is absolutely necessary.

Concering the template positioning, I suggest that a macro will do the job much
more reliable than the likeley default setting in OOo 1.1. This was common
agreement between me and the user experience design team. Sure, it is a
trade-off, but its all I can offer for OOo 2.01.

BTW We have engineering commitment for  i33307, i43146, i50902. The spec will be
updated before implementation begins. 
Comment 65 matthias.mueller-prove 2005-06-24 13:45:56 UTC
51 votes and a vivid discussion. This will be done for OOo 2.0.
I'll update the spec during the next 2 business days
Comment 66 matthias.mueller-prove 2005-06-24 15:37:53 UTC
spec draft done - new sections are highlighted in bright yellow.
Comment 67 peschtra 2005-06-24 17:25:41 UTC
I am just so very happy.

I go around singing the praises of OOo to my friends, and they don't understand
why they should switch when they already have MS Office, but this is a reason.
The people have a voice. It is a beautiful thing.

Thanks Matthias for your hard work and compromise.
Comment 68 michae 2005-06-24 20:43:34 UTC
It's great 
Comment 69 eric.savary 2005-06-28 08:08:35 UTC
*** Issue 51199 has been marked as a duplicate of this issue. ***
Comment 70 aschrage 2005-06-28 15:50:29 UTC
Good news that it made it finally into 2.0. Thanks.
Comment 71 bernhard 2005-06-28 17:05:11 UTC
Thanks to Mathias (mmp) for changing the target milestone - it is much better
than any workaround...

Thanks to all of you con-discussants for convincing him of the exigence for that
feature.

That's how community works!
Comment 72 cno 2005-06-28 21:58:16 UTC
Hi Matthias, all,

My compliments as well for the discussion and the current outcome.

Furthermore I'll try to think about the situation regarding positioning in
tempates (and others). Using a macro is not a problem in corporate
style-environments. But it is an extra effort in other situations.
I do not intend to come with suggestions shortly. And above all I think the
solution as presented now is very OK for this moment.
Comment 73 matthias.mueller-prove 2005-06-30 15:15:47 UTC
spec is final - please implement section 6.2 of the spec.
Comment 74 Oliver Specht 2005-07-05 15:16:07 UTC
Fixed in cws os65 in
sw/source/ui/uiview/view.cxx
Comment 75 richlv 2005-07-05 15:24:03 UTC
* opens beer.

any ideas which master build might get this cws integrated so that we can 
extensively test it ? ;)
Comment 76 eric.savary 2005-07-05 15:57:16 UTC
*** Issue 51578 has been marked as a duplicate of this issue. ***
Comment 77 Oliver Specht 2005-07-06 09:58:16 UTC
cws os65 can be found on cws03

re-open issue and reassign to es@openoffice.org
Comment 78 Oliver Specht 2005-07-06 09:58:27 UTC
reassign to es@openoffice.org
Comment 79 Oliver Specht 2005-07-06 09:58:39 UTC
reset resolution to FIXED
Comment 80 eric.savary 2005-07-07 13:21:33 UTC
ES: verivied in cws os65.
Last Author reopens -> jumps to cursor position
New User opens -> at start of document.
Comment 81 michael.ruess 2005-07-11 10:32:03 UTC
*** Issue 51770 has been marked as a duplicate of this issue. ***
Comment 82 eric.savary 2005-07-13 17:05:51 UTC
Ok in build src680m117
Comment 83 eric.savary 2005-07-20 13:31:53 UTC
*** Issue 52219 has been marked as a duplicate of this issue. ***
Comment 84 matthias.mueller-prove 2005-08-15 16:47:42 UTC
*** Issue 47364 has been marked as a duplicate of this issue. ***
Comment 85 cno 2005-09-05 10:32:20 UTC
Hi all,

XP & OOo 1.9.125 Dutch

- I take a blanc doc
- Create an ott from that
- Create an odt from that template
- Ad some text
- Notice that File|Props lists my name at 'made at', same as in
Tools|Options|General|Userdata
- Save the doc
- Re-open it
- But no cursor at the last position :-(
- Sft-F5 doesn't have any effect either (which is correct, target is 2.0.1)

* What am I doing wrong?
* The Tools|Options|OOo|View|Restore is checked (however, according to specs, is
 of no use and will be removed later)
* Meta XML shows <office:document-meta
xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" 
so it should be the proper new fileformat.
* What file /node / prop is the position to be found?

Oeps, I just test an English/US version of OOo.
There it does work.
So it is an translation-issue.
Does it make sense if I look in one of the XML-files?

Thanks,
Cor
Comment 86 Mathias_Bauer 2005-09-05 17:21:22 UTC
Is it possible that you don't have entered your name into the user data? AFAIK
the cursor restore is bound to the equality of user names from last editor and
the person that opens the document. I assume that in case both are empty it is
assumed that they are not the same person.
Comment 87 richlv 2005-09-06 08:01:03 UTC
if both user information & owner/last editor of the document are empty, they are 
not considered the same.

though if it works ok in english version, somebody with corresponding localised 
version should test it.
Comment 88 aschrage 2005-09-06 09:35:06 UTC
I'm using 1.9.125 German version and there it works as expected. I make a
change, save the document and close it, reopen it and the cursor is at the place
where I made the last change.
Comment 89 hwoarang 2006-07-01 22:51:55 UTC
*** Issue 62802 has been marked as a duplicate of this issue. ***