PowerPoint Feedback by UserVoice

Mike M

My feedback

  1. 17 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    7 comments  ·  PowerPoint for the web  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    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.

    An error occurred while saving the comment
    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.

    An error occurred while saving the comment
    Mike M commented  · 

    Was also mentioned in 31085206-add-option-to-change-the-autosave-default-to-off

    An error occurred while saving the comment
    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.

    Mike M supported this idea  · 

Feedback and Knowledge Base