Refactor file management pattern

[dabreegster]

We have a few places where the user can manipulate "files":

• map edits in the main traffic sim
• named routes in the bike network tool
• bike network extensions (really just map edits, but presented in a different UI)
• story maps (niche/experimental tool but still)
• soon, the modal filter edits in the LTN tool (maybe that'll be map edits underneath, maybe not)

We have no consistent handling today. Some shared concerns / features for these things:

• creating a new / blank file
• saving / autosaving
• naming them (and when do we force a name? and how to assign automatic names?)
• renaming files
• making copies of files
• deleting files
• prompting to save / delete before you navigate away and lose the state
• sharing - a new in-progress feature needed ~immediately for #743
• browsing files
  • and in the route tool, we even have a quick way of scrolling through all the routes

Step 1 is figure out what the ideal UX of file management even should be. Possible inspirations:

• figma
• excalidraw
• streetmix

Then it'd be awesome to refactor code to handle this stuff consistently!

[dabreegster]

Not to increase scope here, but potentially this should also handle undo / redo / listing each change to a model. We really only have one implementation of that today in the main sim's edit mode, but it'd be useful everywhere.

[dabreegster]

save_dialog.excalidraw.txt This is roughly how the LTN tool does it today, drawn with excalidraw

Crazy idea: as soon as you click some proposal and make a change, add a little "3 edits to above" button below the proposal. Have a button to save/overwrite, and a button to save as / fork

[dabreegster]

1083 related too

[michaelkirk]

Just some drive by commentary...

one common pattern in applications that manage document is to present the user first with quick access to a "recents" list with the option to "browse" to dig deeper - expanding the scope to explore the entire file system. Variants of this might be presented at application startup, or if the user manually selects some kind of "load" action. This is nice because the user doesn't have to decide up front that they want to "quick load" then realize they need to back out and "load from file system".

If reasonably possible, orienting the design around familiar notions like "load", "recents", and "browse" might help the user guess how things work.

I'm not sure exactly how to reconcile all that with the notion of undo/redo though, if that's still something you're hoping to tackle.

Going with the document mgmt paradigm, a couple of undo/redo patterns that I can think of:

• occasional "autosaves" that appear in the filesystem with an intuitive name like "My Proposal - autosave 2023-04-12-16:00.json". If you had a notion of "autosaves" like this, I'm not sure if they should automatically appear in "recents" or not - it'd be more discoverable if they appear in recents, but it might quickly crowd out the recents list, so you'd then maybe need some kind of pruning.

• have the version browsing not as part of the file picker, but as a separate step once the document is loaded, a la google docs version history.

[dabreegster]

If reasonably possible, orienting the design around familiar notions like "load", "recents", and "browse" might help the user guess how things work.

Thank you for this writeup! I was considering getting rid of the custom document management UIs entirely and just using native file dialogs (which have a "sort by modified time" control already that should be familiar). But the built-in UI is faster and can potentially summarize more info about the proposal. (rfd has slight lag before showing the dialog.) More recent feedback in #1082 from a regular user was asking for an app start screen that emphasizes recently opened projects. So I think in the short term, I'll take your suggestion and nest the full file loaders underneath the existing load/save dialogs, and re-word them a bit. Then as a next step, try a new start screen emphasizing recent files.

Going with the document mgmt paradigm, a couple of undo/redo patterns that I can think of:

These both seem reasonable, with the first being easier to implement. I'm trying to first simplify internal implementation of the edits in the LTN tool in #1079 and reduce the save file size by not including all boundary areas (even when they're unmodified). That'd partly give version history for free (if the saved files were not compacted, like they currently are) and make the cost of auto-saving copies less intense (especially in browsers, with that ~5MB local storage limit).