[REQUEST] Auto save

[Chessel]

Suggestion/Concern

The user has to constantly save changes if they don't want their progress to be lost. Many times the progress is lost because the progress wasn't saved and one has to start over.

Proposed Solution

This could be resolved by auto saving progress every so often

[aaronreed708]

@lwnoble suggests we do some Design Thinking on this

[Chessel]

UPDATE: This is not working I messed up my issues.

[prithviraj-chaudhuri]

Looking at this and working on a solution @aaronreed708

[prithviraj-chaudhuri]

Added this feature with this PR #715

[aaronreed708]

Sorry @prithviraj-chaudhuri, I somehow missed that you commented that you were going to work on this. I'm sorry about that. I would have cautioned you that issues with the "design thinking" tag will usually require some level of discussion as to the user experience that we want to present before we begin working it. I see nothing wrong with your solution, but I believe that this requires some deeper thought. For example, a minute might be too long. And should we provide some level of undo? Should we have a way to turn off auto save? Things like that we probably need to decide on.

What time zone do you work in? A lot of us are traveling this week. Maybe I can set up a call next week. Would that work for you?

[prithviraj-chaudhuri]

@aaronreed708 I work in the EST time zone. Any time after 5.30 pm on weekdays and any time on the weekends work. Feel free to send me a calendar invite.

[aaronreed708]

I am in the EST, too, so that works for me. Let's try to capture some ideas here so that we have a basis to start discussions.

I like what I read here: https://design.gitlab.com/usability/saving-and-feedback#auto-save. The idea that auto save is saving "drafts" with timestamps feels like the right path to take. That the user can get back to previous drafts even if they close their browser feels right to me, but if they export their design system, it is the last one that they saved manually. The save button is prominent and always visible, so I think that we have to think that the user might not be clicking it for a reason (e.g. they aren't ready to keep the experimenting that they've been doing). But they also might not want to lose their experimentation, either.

One of the tough questions is when to autosave a draft. As the article recommends for forms, on blur for text fields, on click for button actions, menu items, etc seems desirable. But then we have to make sure that we handle these correctly in each of our panels, which may not be trivial.

[aaronreed708]

Discussed with @Chessel, she is thinking that this should work more like design tools that have autosave features. She suggested since that is our intended audience, for the most part, that we should give the user experience that they are used to/expect. That rather than drafts, she suggested that we save restore points so that a user can recover where they were if he heads down the wrong road. So maybe we need to target how other design tools handle auto save as our goal.

[prithviraj-chaudhuri]

I'll try and come up with a design that enables this. I'm guessing this needs some form of history that the user can go to. Give me some time to come up with something

[prithviraj-chaudhuri]

@aaronreed708 this is the design I am currently thinking of.

1. On every save (either by hitting Ctrl +S or auto save) we create a new entry with the difference between the previous theme and the new theme and store it in a file called history.
2. This history entry will be mapped with the theme name, and will have timestamps. So it a single theme will have multiple history entries and those can be sorted
3. On hitting undo (either by Ctrl + Z or by an undo button) we delete a history entry from the file ( essentially pop it from the stack or list of history entries) and write the difference to the theme and save it to the themes file.
4. By doing this you can also give the use control to go to a specific change in the history entries.

This is a pretty big change and hence is taking me some time to get this working. Let me know if you have any concerns about this in the meanwhile

[aaronreed708]

Hi @prithviraj-chaudhuri, so here are my initial, first-impression thoughts:

• I don't think I'd like keyboard shortcuts (in #'s 1 and 3 above), applied to the Theme Builder application as a whole, to affect the save history/restore points in Theme Builder. For example, if a user types into a field and then hits Ctrl+z, do they mean to undo the current restore point or do they just want to undo the text changes they just made to a field. It is also possible that they may have lost where their current focus is and hit Ctrl+S thinking that they are saving the Word document that they THINK has focus even though Theme Builder actually has the focus on a different monitor. I am fine if we want to support keyboard shortcuts when managing the restore points in a specific window (e.g. in a popup?). It is good accessibility to support keyboard when at all possible.
• I don't know that you can "pop" a change off of the stack. If you do that, how can you get back to it? For example, I change a color to a specific shade of orange, then I want to undo that change, but then I decide to go back to that shade. I would assume that if the app saved some changed, then those changes go to the end of the list. If I want to go back in time, then another set of changes will be applied to the design system to get me to that historical state and then THOSE changes will be added to the top of the stack. So we should support Redo as well as Undo, I would think.
• We'll need some thinking around the saving of diffs. Because if all of these changes are saved and based off of the previous history, then if any point in history fails to save or becomes corrupt or fails in some other way, then we can never replay the history to get where you want to get to

[prithviraj-chaudhuri]

@aaronreed708
In response to your points.

• I agree the keyboard shortcuts could be confusing to some people.
• In place of using diffs, we can also just store the entire theme entry. In which case if a user decides to go to a specific version it won't be impacted if the previous version failed to save. However, to support undo and redo, we have to have a strategy as to when we want to discard a version. For example I change the font size -> it saves -> i change a color -> it saves. Now when the user wants to undo the color, they would have to go back 2 changes, and then start of a new "branch" in the tree of changes. If we decide to keep all branches of all changes, I am concerned it will be confusing for the user. And if we decide to store entire history versions, it might lead to the user losing some experimental changes.
• WRT the above i have this suggestion
  1. We save entire themes instead of diff
  2. If the user decides experiment, the can create a named checkpoint. They can always go back to this version at whichever point they want.
  3. Not support redo at all for the first release of this feature, to keep the implementation simple. This can be part of a second issue.
  4. If the user goes back to a future saved checkpoint, that checkpoint gets added at the end of the history.
  5. As for triggering the saves, we can have an auto save (in some interval) which basically helps with undo. And a named save option for users to identify checkpoints.
  6. Finally, we would have to give users a list of all the saved points that they can go to, somewhere in the UI

Does this sound good to you?
If you want we can have a call to discuss this over.

[aaronreed708]

@prithviraj-chaudhuri
So would the checkpoint be an action that the user needs to take? How would that be different than just saving your design system before you experiment? We need to keep in mind that for Netlify deploys, the user will be using browser-based storage, so we should probably be conservative with the saves.

Thoughts @Chessel?

[prithviraj-chaudhuri]

1. So would the checkpoint be an action that the user needs to take?
   a. Yes, something like hitting the save button but with a textbox so that the user can put in a name
2. How would that be different than just saving your design system before you experiment?
   a. By default saves would just have timestamp.
3. We need to keep in mind that for Netlify deploys, the user will be using browser-based storage, so we should probably be conservative with the saves.
   a. We can also just either not do auto-saves on interval. Or delete old versions. Like keep only the last 20 saves maybe.

[aaronreed708]

@Chessel and @aaronreed708 to discuss, do mockups on restore points in footers

[Chessel]

The thing I'm struggling with is that I really don't know how the average user will use the theme builder. I wonder if the theme builder will be a place for experimentation or if the experimentation will take place somewhere else, such as Figma or Sketch, and they'll come to the TB with all the values they want.

I wonder if the auto-save feature has to be so granular in terms of dos/redos/versions to comeback to? Think about Google docs or even Word, what are the minimum expectations from auto save? I would assume undo/redo some actions during my session but, when working on Word do I ever want to go back to a certain point in time? I think we might be able to simplify this feature until we have more information on how the users use the tool.

But I agree with @aaronreed708 let's mock it up and take it from there

[prithviraj-chaudhuri]

@aaronreed708 I can build just the UI and send you screenshots. Will that be enough for the mockup?

[aaronreed708]

@Chessel I would say that the average user will be pretty split between designers and developers initially (I think developers experiment with new tooling quite a bit), but over time I would expect it to be more designers. But even if the designer comes with known values (like we have, ourselves, for our internal applications), there will be times when the designer needs to change the theme colors or make tweaks to existing design systems to see how they play out. So I would think that these designers would expect the undo/redo behaviors to work like they do in design tools. Which I assume is slightly different than Outlook, Word or Google Docs. Are there any obvious differences that you can itemize or are they substantially the same as any other undo/redo implementation?

@prithviraj-chaudhuri I don't want to cause you a lot of work building real UI unless you work better that way. I'd be just as happy if you scan a sketch. We just need a place to start discussions.

[Chessel]

@aaronreed708 from the designer perspective, if we talk about Figma, when I experiment in Figma im not expecting to go back to a precise point in time, although I expect to be able to do/undo. However there is a versioning capability Figma saves a version everytime they detect 30 mins of inactivity. I think that makes sense and the versions are not so overwhelming. If during a work session you need to go back you undo/redo. If you want to go back to the latest saved work of a different day, you user versioning.

Figma saves your work by adding checkpoints to the file's version history. Figma records a new checkpoint after 30 minutes of inactivity in the file. If more than one person is editing a file, both contributors will need to be inactive for 30 minutes for Figma to create a version.

Yuhki starts editing his file at 9:00am, he takes a short break at 11:00am for 15 minutes before resuming work. At 1:00pm he heads off for an hour to grab some lunch. Figma will save everything he worked on from 9:00am to 1:00pm as one version.

Later that afternoon, Yuhki and Jenny work together in the file from 2:00pm. Yuhki leaves at 4:00pm for a meeting, but Jenny continues working until 6:00pm. Figma records everything Yuhki and Jenny worked on between 2:00pm and 6:00pm as one version. As Jenny made more changes during that session, Figma lists her as the main contributor.

I do not know if engineers will expect a higher level of granuality.

[prithviraj-chaudhuri]

Hi @aaronreed708 and @Chessel
I created mockup of how i envision the auto-save to work
Please share your thoughts
Autosave Mockup.pdf

[aaronreed708]

@Chessel something to keep in mind is that there are no accounts for Theme Builder currently. https://try.a11y-theme-builder.finos.org/designSystem/sample is using static pages and local browser storage. So we may not be able to detect 30 minute of inactivity if the user closes the page or the browser. We could, of course, try to version something when these are detected, but I don't know that it is fool proof. But maybe this is another reason to consider accounts, etc. We could also have two flavors, a static version of TB and a TB server with persistence, accounts, etc.

[aaronreed708]

Hi @aaronreed708 and @Chessel I created mockup of how i envision the auto-save to work Please share your thoughts

Hi @prithviraj-chaudhuri, these are the thoughts that came to me immediately as I walked through your PDF:

• Whatever way we show the available versions, we need to include a date and time timestamp
• I kinda like the ability to name the manually saved versions. That could be really cool. But would a user give more importance to a named version than an auto-saved version? For example, would a user be ok with an auto save version to bump one of their named versions?
• Undo and Redo functionality as you have it defined in your design document would need to be renamed to something else. I would expect something named Undo and Redo to be very granular and act like those functions in an editor or an email application and allow me to undo every little change I make with each keystroke or mouse click.
  • Undo-ing and Redo-ing would be difficult to convey to the user who could be making changes in multiple panels that span the Theme Builder application
  • Maybe granular undo and redo, if available, are only available on a single panel and only for the limited lifespan of that panel? And once that panel is swapped out in favor of a new panel due to UI navigation by the user, then the ability to undo/redo for that swapped out panel goes away?

[prithviraj-chaudhuri]

@aaronreed708 Please look at my response to your points below

• We can add timestamps and dates against the list of versions in the dropdown
• I would think the limits for autosaved versions and saved versions would be different. Autosaved versions would purge old ones automatically, whereas named versions would have to be manually deleted (At lease initially)
• For undo and redo, we should (at least for now) only go to the last version or the next one (we can change the names to "Previous version" and "Next version". This will keep the initial implementation simple.

[aaronreed708]

@Chessel Thoughts?

BTW, I'm on vacation starting tomorrow - Monday. I'll try to keep up with updates, but no guarantee.

[Chessel]

@aaronreed708 @prithviraj-chaudhuri

• I agree we need time stamps for the versions
• I'm not sure if the user will understand the difference between saved and auto-saved versions. Probably the save button will need to change label to "save as a new version" or something like that
• I do agree with @aaronreed708 that the undo-redo actions usually affect at a more granular level (the individual changes that have been made) if the user can select the version to go to from the drop down, why do we need the "Previous version" and "Next version"
• If we cannot track the activity time of each user, how often are planning to create a new version?

[prithviraj-chaudhuri]

@Chessel @aaronreed708

• We can possibly format named versions a bit differently or make the drowpown similar to how github does branches and tags
  .
  And we can always change the name of the button
• For the sake of simplicity we can possibly leave out "Undo" and "Redo" for now. I think we should start implementing this and then add functionality later. This would make the initial implementation simpler
• For now we can follow google docs' lead and save after every 5 minutes.

Let me know when I can begin implementing this. I believe simple, incremental improvements to the save functionality would be better as that would help identify the pain points and improve on them rather than coming up with the perfect solution in the first go.

[aaronreed708]

@prithviraj-chaudhuri: Sorry, I'm back from vacation now and caught up on other business and getting caught up with this issue now. Looks like @Chessel is out until at least Monday. So if you want to wait for her return, we can. But these are my current thoughts:

• I'm fine with a dropdown with a tab for named saves and a tab for automatic saves and with date and timestamped entries
• I'm fine with no undo or redo support to begin with
• I'm fine with 5 minute autosaves

Further questions/suggestions:

• Just to suggest a place to start, I'd begin with keeping 20 auto saves in a circular list and writing over the oldest entry if all 20 slots are full.
• I'd suggest if no changes are detected that no autosave is done so that I don't end up with a 20 entry buffer of identical entries.

Autosave sessions:

• where would the dropdown be located? In the footer? Or another dropdown in the header?
• should we think of the versioning as tags like in gitHub? So that there is always a "latest" named tag that is always identical to the most recent autosave?
• Is there only one autosave/named-save session or will there be one for every loaded design system?
  • if I load in a new/different design system, what happens to the autosave session that was previously running?
  • what is the user experience when I go back to the previous design system that had autosaves and named tags?
    • I would assume that the "latest" named tag would still be there but all autosaves are gone?
    • keep in mind that in static versions (like on Netlify) these have to be stored in browser local storage
• Is detecting browser closing triggering a save? Or a modal asking if the user wants to save changes?
  • If it shows a modal for the user to interact with, what happens when the browser is closed/crashes and no modal can be displayed?

[Chessel]

Hi @prithviraj-chaudhuri and @aaronreed708 these are my thoughts:

• I'm also fine with a dropdown with a tab for named saves and a tab for automatic saves and with date and timestamped entries
• I'm also fine with no undo or redo support to begin with
• I think 5 minute autosave might be too many unless we know the average session time. Is it 15 minutes or is it 4 hours or something in between?

I like this suggestion by Aaron

I'd suggest if no changes are detected that no autosave is done so that I don't end up with a 20 entry buffer of identical entries.

My take on Aaron's questions:

where would the dropdown be located? In the footer? Or another dropdown in the header?

• My preference would be on the header

should we think of the versioning as tags like in gitHub? So that there is always a "latest" named tag that is always identical to the most recent autosave?

• would this version come in handy in case the user jumps to a different version and then wants to return to the latest version?

Is there only one autosave/named-save session or will there be one for every loaded design system?

• I would say that each design system has their own set of versions

Is detecting browser closing triggering a save? Or a modal asking if the user wants to save changes?

• For me the whole point of auto-saving is not to have to worry about saving you changes, so I would say that when closing a session the latest version get saved without triggering any saving action.

[prithviraj-chaudhuri]

So here is the final solution that I am starting to build

1. The save button will be renamed to "Save as a New Version" -> onclick -> opens a modal where user can enter version name and save
2. There will be a dropdown on the header with 2 tabs "Auto saved versions" and "Named versions" both will have date and timestamp against them
3. The autosaves will be around 10 mins (this can be configured to see what feels correct)
4. The saves will be done like a queue where the oldest saved version will be removed in autosaves. In case of named saves a warning will be displayed to the user saying that the oldest saved version will be removed
5. Each design system will have their own set of versions. (10 named saves and 10 auto saves). We can change this logic or find better solutions in follow up issues. I believe that would need a more complex solution (maybe user accounts to store things in the server or a user configurable path to store it). But i think it is best to keep it separate from this issue.
6. Detecting the browser close would be tough. We can do it like google and maybe give a popup if the the latest changes have not been saved
7. In my opinion, having a "Latest" version would make it more complicated, at least for the initial implementation. I would want to keep it out for this implementation and revisit it later.

Please let me know if i am good to start building the solution with these points

[aaronreed708]

should we think of the versioning as tags like in gitHub? So that there is always a "latest" named tag that is always identical to the most recent autosave?

• would this version come in handy in case the user jumps to a different version and then wants to return to the latest version?

I think I was thinking that all autosaves would disappear if the browser would close and thus there would be a saved milestone to start from the next time the design system was opened. But I'm fine not having this initially and keeping all of the autosaves even after close to see if that works well.

[aaronreed708]

6. Detecting the browser close would be tough. We can do it like google and maybe give a popup if the the latest changes have not been saved

Wouldn't you show the popup when the browser/tab closes? So if you can detect it to show the popup, then you could just do the save (as @Chessel suggested).

[aaronreed708]

4. The saves will be done like a queue where the oldest saved version will be removed in autosaves. In case of named saves a warning will be displayed to the user saying that the oldest saved version will be removed

If you are having a limit on the named saves, then you probably need to allow the user to delete specific named saves to clear up slots to store the new save.

[prithviraj-chaudhuri]

6. Detecting the browser close would be tough. We can do it like google and maybe give a popup if the the latest changes have not been saved

Wouldn't you show the popup when the browser/tab closes? So if you can detect it to show the popup, then you could just do the save (as @Chessel suggested).

I am looking into this. I have started the implementation. Would get back to you when I reach that point

4. The saves will be done like a queue where the oldest saved version will be removed in autosaves. In case of named saves a warning will be displayed to the user saying that the oldest saved version will be removed

If you are having a limit on the named saves, then you probably need to allow the user to delete specific named saves to clear up slots to store the new save.

I will try and incorporate this in the PR as well

[aaronreed708]

@Chessel has done some wireframing for post MVP work. Will post here when it is ready.

[Chessel]

@prithviraj-chaudhuri I've been working on a draft for the auto-save flow based on the new Theme Builder design. These designs ARE NOT APPROVED, but @aaronreed708 and I wanted to share with you to get feedback.
Please check them out here.

[evangk6]

No update from Prithviraj - possibly move back into No Status, and use as mentorship project / good first issue.

[evangk6]

No update from Turntabl - possibly move back into No Status, and use as mentorship project / good first issue.

[aaronreed708]

I'm fine with moving this back into a prioritized column, but probably not a "good first issue". To implement this fully will not be quick.