PowerPoint Add support for setting a document as read-only recommended
Sometimes when a teacher posts a document that we should do, I see that another student wrote their answers onit
Justyna K
shared this idea
7 comments
-
Mike M
commented
I would just like to point out that a thread started by @wataru (I think) has been merged into this one, but the issues are very different. This idea (read-only) is about permissions, whereas the commentary from @wataru and me, @Mike M, are about 3 things: versioning, date modified and autosave. Please read my comment that is highest in the list to @PowerPoint Team, where the first point is expressly about not assuming that a user will know if they want to open as read-only. This read-only thread has only two comments (@Justyna K and Anonymous) that sound like their intentions are known at the time of creating the first version. Additionally, permission systems, such as those in Windows file system or SharePoint, allow different permissions for individuals or for groups of users and should be handled by the file system/SharePoint. I don't think permissions should be a use case for PowerPoint. The comments by @wataru and @Miike M are user independent. I worry that by merging into this thread, the moderator has obscured our ideas and blocked an opportunity to innovate a couple simple changes that could be applied to all Office programs and have big benefits. It would likely be more than one change, but each change could be simple. For example, (1) if a document is closed in the same state it was opened, the date modified is not changed despite several autosaves; (2) if a document is closed with a change in state, a version is created and the user is prompted to provide a description of the version, if they want; (3) if the user expressly saves, a version is created and the user is prompted to provide a description of the version, if they want; (4) if a user makes changes which autosave but disconnects without expressly saving, they pick up where they left off, still allowing ability to discard changes when they reconnect--nothing changed in the meantime; (5) if a second user opens a document that was disconnected with autosaves pending, they will see the most recent changes but the date modified will be unchanged if they only read it; (6) if a second user actually makes an edit (not just reading it) while the first user has it opened, a version is committed, to which the first user may opt to retroactively edit a description for it. The last one, 6, is where autosave takes on a complex behaviour.
-
Anonymous
commented
Have a lock on documents that may not need to be changed
-
Mike M
commented
@PowerPoint Team: If I understand you correctly, I would say that neither points you made are valid. First, asking a user to decide whether they will edit a document or not before opening fails to recognise human behaviour. We might open the file without any intention to edit, but then see cause to do so. On the contrary, we may open to edit, begin editing and then decide it was just right the way it was and close without saving. My understanding of autosave was to come to the rescue of those who get caught up in their work and forget to manually save. Ultimately, whether to save and create another version should remain in the hands of the user; otherwise, you are making the user accommodate and be subservient to the system. Is there a barrier to provide the tried-and-true algorithm when files were simply saved locally? I sense that this has come about because of cloud storage, perhaps even because of introducing a new feature to share a document with someone and allow live editing. If the latter, would it be better to put the problem in the domain of sharing rather than file saving. By that I mean, rather than ask the user to choose edit or reading view, ask the user if they intend to share a file with real-time edits. I think you would find the number of instance that people need this feature is insignificant to the number of times they simply open, perhaps save, and close a file on their own.
As for version history, making this visible in the application is a good idea, but it should not be mistaken as a solution. Version history should only be an intentional creation by the user, giving them a chance to describe the version so it can be later identified. Otherwise, you have the situation described by @wataru having to open each save to figure out what it contains, if anything. If the autosave is not working as expected, restore it to what is expected. Is this another issue that has come about because of trying to find a solution for live sharing?
Just trying to help. Always open to other ideas.
-
wataru
commented
I agree with what Mike M said in the comment section - the file should not be saved until the user click 'save' to commit the change. A better experience would be a prompt to save before exiting Word. In that way, the user can choose whether to commit the change or discard the change. Right now Autosave simply functions as OneNote and it's too troublesome to find the right version to revert back.
For example, I was editing a document the other day, I made a mistake in my editing, and did not want to save it. I had 'autosave' on, and I had to dig the version history and open each version one by one and still didn't know exactly what version was the last saved version. Alternatively, I could also keep clicking 'undo' button till it grayed out. Either way it's a colossal waste of time. When I exit Word, I am not given the option to discard the change if 'autosave' is on. Therefore, I opted to disable 'autosave' in OneDrive.
-
Mike M
commented
Was also mentioned in 31085206-add-option-to-change-the-autosave-default-to-off
-
Mike M
commented
@Wataru, I don't think this is the solution. It happens to me when I open a file using O365 desktop on Windows 10. Autosave is, however, a necessary function and should start when the file opens. The real problem is that when a file is open, there used to be a copy of it opened, and when you made a change and saved or simply clicked the save button, the original file would be overwritten. If you made changes and didn't save, it would prompt you whether to save or not. This is a use case that has existed for a long time, and I'll bet there are many people who are not yet aware this is happening. Many business processes might rely on this date being accurate. Now, as soon as the file is opened, the change in date happens. The date modified field no longer truly represents what it's title conveys, and yet it is important, perhaps even legally. It should save locally until I commit a change, and the autosave should merely save to this local temp file.
-
wataru
commented
Currently autosave is forced on every file on Onedrive. Terrible idea. Why? Because every time it saves, it changes the file's modified date. So I have no way knowing when the file was last edited. Let's say, if I open a file I edited in March.13th on Onedrive, the instant I open it and type something, its modified date changes to Sep.18th (today). So now I have to figure out whether the file is old data or new data, or when I lastly 'really' modified it (from the explorer) unless I open it in Powerpoint to see its saved history. Moreover, if I move the file to my local drive (it will happen when it is time to archive the file), all the history saving info is lost (good luck finding out your last edit). The autosave feature severely breaks my existing workflow (e.g. relying on 'modified date' for file editing history check). Terrible, terrible idea.
Never liked OneDrive. With AutoSave in place (and w/o the ability to disable it permanently), there is even less incentive to use it, or continuing subscribing to O365 in my next bill.
