Apache OpenOffice (AOO) Bugzilla – Issue 73155
Reconsideration of read-only mode
Last modified: 2016-03-18 17:07:56 UTC
User scenario: 1. A citizen visits a web site of public office to obtain an application form. 2. She clicks on a link decorated with an icon of OpenDocument file format. 3. The document is successfully opened in her web browser with OpenOffice.org, but she cannot enter anything in it. At this moment, many people simply close the document because it is not editable, i.e. not usable for them. Consequently, they click on another link decorated with an icon of Microsoft Office file format and achieve their task. Some people know that the document has been opened in a read-only mode and it can be turned to be editable by clicking on an icon "Edit File" on the tool bar of OpenOffice.org. 5. She clicks on the icon "Edit File" and gets an unwanted alert saying "Object not accessible. The object cannot be accessed due to insufficient user rights." accompanied with a white cross-shaped mark on a red circle. She becomes worried about violation of access right. 6. She clicks on a button "OK" because there is no other choice. 7. She gets another message saying "This document cannot be edited, possibly due to missing access rights. Do you want to edit a copy of the document?" Now most people answer "No" although they know what they are doing, and they abandon use of OpenOffice.org and go back to familiar office suite. She got warnings about insufficient access right two times. She did not want to violate access right. She did not want to commit a crime. A few, well-trained, experienced OpenOffice.org users know that the warnings can be simply ignored. They answer "Yes" to the message to make a copy of the document and start to edit it. 8. She clicks on a button "Yes" to get a copy of the document and successfully accomplishes filling a form. 9. Now she notices that an original file name of the document has been lost and is currently named "Untitled1." Being an experienced user, she easily succeeds in finding the original file name by leaving her mouse pointer over the icon of OpenDocument file format in the web page to get information on the link. 10. She types the file name by hand to save the document and eventually achieve her task. What we could learn from the user scenario: What she might expect are: 1. She clicks on the link to open an application form. 2. She wants to immediately start filling the document. 3. She wants to save it with its original file name or similar name. Realities: a) She gets interrupted with unwanted warning messages two times. b) The messages are enough to make her worried about violation of access right. c) The original file name has been lost upon her saving the document.
reassigned
*** Issue 75946 has been marked as a duplicate of this issue. ***
I reported this bug to Ubuntu, and read the result of the discussion of Issue 75946. Incidentally, that is where I learned about the Edit File button, which is a nice feature. If it could be put somewhere in the File menu—and work “inline” without errors, that would be really nice, though. I can imagine that the errors before creating the new document would scare or deter some users.
Yes, suppressing the error message would be a good step forward. Unfortunately this issue here is a little bit off-track in some other points. The points 9 and 10 are wrong as the user won't be able to save to the original location if step 5 resulted in an error message due to missing access rights. If a saving to this location was possible this error message wouldn't appear. And it mixes in another thing (the browser plugin) that is not related to the read-only mode per se: whatever we might do to the "normal" mode we won't allow for editing files in a browser window. This is not a safe environment as the browser can kill the plugged window at any time without a chance to save the content. Plugins shouls stay read-only all the time. I will see if we can do something against the error message when a user clicks on "Edit file" without having the necessary rights to access the file in writing mode. Immediately asking for creation of a copy would be better, I think. In a next step we can try to find out what might happen if we allowed write access anyway as then the user will get the error message when she tries to save.
Voted on this, because sometimes users may want to edit a file "on-the-fly" and print it directly. If editing is disabled in "read-only" mode, users would have save the file first, edit & print the file and then delete the saved file, which adds extra steps and is enough to affect the usability.
well maybe I'm not experienced enough, but I didn't actually know about the "Edit File" button until I read the bug#75946 as pointed by mtrausch today... I think allowing users to edit the file when opening a read-only file is okay, just give a warning message and popup the "Save As" dialog when user clicked "save" is sufficient.
it seems MS Word also just popup the "save as" dialog box when user clicked "save" in read-only mode instead of disabling any editing, which definately made it easier than OOo to just edit "on the fly" and print.
This is a major pain for us. In our case it's usually someone trying to view a generated spreadsheet on our intranet. Fill out a form, submit, and the browser prompts to open the spreadsheet. The problem is that when you start looking around the spreadsheet you see some data that's cut off, so you go to resize the column, but you can't. You have to click the Edit File button (which I only learned of thanks to this bug report), then confirm another prompt, and then it becomes editable, but it also scrolls back to A1 so you lose your place. There shouldn't be all these extra steps just to *view* information in a spreadsheet. With Excel you just open and adjust columns as needed, with no messing around.
Issue 126877 makes this same request, which additional supporting arguments.