> The thing is, you can only offer this feature if your app's architecture is designed from the ground up to support it.
Perhaps I'm misunderstanding something, but this makes 0 sense to me. The Save button itself must be able to save the current state. So at the very, very least you should be able to just check on a schedule what the current state is and determine if it differs from the previously saved state.
There are much better ways to implement this that take more underlying work, but agree with the other comments, this has nothing to do with people not understanding files, it has to do with people expecting web editors to autosave.
Autosaving means you often save a state the user didn't want to save, sometimes one they wanted not to save, erasing one they probably wanted to keep as a savepoint.
You can give them back the point-in-time or known-state recovery with manual snapshots or history tracking, but now your data system has to support that.
Lots of apps implement this by autosaving to a different location from the manual save. So autosaves overwrite each other, but they don't overwrite the user's explicit choice. On loading a save, if they detect the autosave is more recent than the manual save, they offer the user the choice of which one to use.
Microsoft Word has had this since the 90s (with slightly different presentation from today, and definitely without sophisticated history tracking). Their computers used to fail (blue screen) much more regularly. It's not about web apps vs desktop.
Exactly. The original problem was "people are losing all of their work cause they're not saving." So you autosave every minute or so to a separate "recovery" location, then if the user exits without manually saving, on next startup you give them the option to continue from the last autosave if that autosave is more recent and not identical to the last manual save. Doesn't require full change logging, and only requires one "last autosave" at any given time. IIRC this is how your Word example from the 90s worked.
I think you are exaggerating the importance of undo/redo. Even in google docs, if you restore from a savepoint you can only go backwards. And besides, the complaints OP got were "I'm losing all my work" - I doubt someone who had some recovery point would be in a worse position to recover than someone who had no recovery point at all.
(in other words, it's not necessary at all to support this feature from the ground up - it just might be necessary in order to have a third, even better way than "no saves" and "imperfect saves")
The "files" mention in the title is misleading, the saves here are done server side, which is made clear in the explanation about version history.
And that's where I think the author either doesn't have a mental image that matches what the user sees, or they like metaphors that don't really apply to their product.
I don't think we'll have a generation that doesn't know what saving is anytime soon: gamers in particular will still be be familiar with juggling save points and restoring previous states. Even people spending most of their computing time on phones will still see commit and save buttons in photo editing applications for instance, or most edit screens.
Pushing a button to commit changes is probably familiar to everyone, the chalenge is how to convey the need to push it, and visibly making the button text orange doesn't seem to be enough.
I work with files every day, and I'm not sure I would have realised I'd needed to save manually with the original MapHub UI either. A web-based interface that looks like that, I expect it to be transparent. If it'd had three icons (the classic blank page, open folder and floppy disk) in the top left, then I'd assume it would need manual saving. (I'm not saying that's what you need to do, just analysing my own intuitions)
The interesting bit is that for years this wasn't a problem. Like for 5 years I got 0 support requests about missing Save. Also web apps were not auto-saving traditionally, many of them still don't do it today.
It's very possible that if you showed me the MapHub UI eight years ago, I'd have intuited that I'd need to save manually---I can't tell for sure. I am definitely aware that the way I engage with software nowadays is very different than when I started using computers in the early 2000s, and I don't doubt it is still evolving due to the changing conventions in UI and functionality.
I doubt it. Most school software still sends files over e-mail that you have to save as attachments, or upload your own document files. So they still learn that early, regardless of if they use it later in life.
How does that work for most people? Are they organizing the files on a traditional file system or clicking on an icon in the message to open them or picking uploads from a selector which blends cloud and and app boundaries? Based on my wife’s school and the one our son attends, a LOT of the areas which used to expose file system behavior have been removed or significantly de-emphasized.
Not the case universally. My son's school in south-central UK does everything via Google Docs or apps specially built for distance learning. If it weren't for Minecraft mods, he'd have no concept of the file system.
Well, in Google Docs you have something that looks a lot like a hierarchical filesystem (whether someone actually creates folders or not). The fact that it's not actually a filesystem as traditionally understood is sort of irrelevant. The average filesystem user didn't know about inodes, journaling, etc. either.
Author here, I'll try to collect my thoughts into one comment here about why there is no auto-save.
If you implement auto-save, users will expect every click/keystroke to be saved, like how Google Docs does it. Simply adding a 1-minute timer will make people lose work in the last minute, as they switch tabs, go offline, etc. and forget about it for days, when the browser clears tab state.
The other reason is that there is no Undo-Redo implemented on MapHub. Implementing Undo properly in a web app is not trivial if you haven't designed the whole app around a time-traveling state management. It's actually a really difficult problem to solve, even though it looks simple on the surface. Combining it with real-time collaboration is even more complex. Short story: there is no Undo-Redo.
So if you don't have Undo, then Save button plays the role of making a checkpoint, trying out something, reverting if needed. With autosave this could be ruined.
Also, you write that you expect every web app to auto-save, but this is still not the universal case today and definitely wasn't the case a few years ago. I agree that most VC-backed startups with hundred-million-dollar valuations have autosave in their web apps. Again, the proper solution is to have a time-traveling diff system implemented, which can easily get really complicated with real-time multi-user collaboration. Have a look at Figma's technical blog post about this topic [1].
You might be right in saying that it's not a generation of users, but the same users being conditioned to web apps doing auto-save. I agree this is probably the case. The point of the article is this definitely wasn't the case all the time, and how I've experienced this on my side, during my 8+ years of running MapHub.
Disclaimer: I am not familiar with the product, so created a MapHub account just to try the exact experience. I usually mostly work with hiking maps and planning hikes, so my viewpoint might be off.
I feel the base disconnect is MapHub having very few indication of a workflow: one can create a new map and start working on it in a matter of seconds, adding markers etc. is also relatively quick, with help on the right panel guiding through the option, so it all feels natural.
In contrast the Save button is next to the zoom in/zoom out button, so outside of the tools area, neither in the right or left blocks where one would focus when editing.
The button is also greyed out when starting a map, and will always be visibly present, so after a few minutes I think we learn to ignore it as a visual element. In particular I never use the zoom in/out button (right now I straight pinch on the screen, but I guess touchpad pinch to zoom also works?)
I feel like the UI is really optimized for being out of the way and not having to think about versions. If autosaves are not an option, I think the save button would benefit from being a more "actiony" button and perhaps have a more prominent sibling in one of the tools or editing panel (and probably not just "save" but "save this map" or "take snapshot" or something like that ?)
My favorite map app has a big dark "Save" in a permanent footer inside the edit lists, and I better understand the reason now.
OK, fair enough, but that doesn't have to preclude autosaving.
> If you implement auto-save, users will expect every click/keystroke to be saved. [...] Simply adding a 1-minute timer will make people lose work in the last minute.
I think a nicer compromise might be a simple debounced isDirty state. If it detects any changes, wait 5 or 10 seconds. If any more changes happen in that same time, wait again (up to some sane max, like a min or few). If no further changes, create a new automatic checkpoint.
It's usually not a big deal if someone loses 10 seconds of work. It is if they lose a few hours.
> Save button plays the role of making a checkpoint, trying out something, reverting if needed. With autosave this could be ruined.
Only if you make the autosave overwrite user checkpoints. Can't they produce their own separate bin of autosave checkpoints? Word has done that for decades, as have video games.
The user can choose to revert to "Blahblah save (10/31/24)" or "Autosave (3 min ago)".
Even if it is a generational thing, it's also just good UX IMO.
Manual save-points are still useful though if you want to go back to a previous version and branch off a different experiment.
Pretty much the same how (mostly PC-) games combine auto-save, manual quick-save and manual 'explicit' save (with a name chosen by the user), and where the last N auto- and quick-saves are preserved (where N is usually a fairly small number). It's less about not losing progress (for that, having only auto-save is fine), but being able to go back to a previous 'checkpoint' and branching off a new timeline.
Agreed, I'm seeing people of all ages not having to interact with the desktop metaphor at all any more. Typically people that manage to do all their "computing" on Android, iOS or sometimes ChromeOS (where they are email and SaaS based).
The metaphor is more of containers/projects and save slots/objects. Far more like video games than the traditional model.
Another option rather than complete rearchitecting the app is to autosave into an autosave slot. A lot of games do this to avoid the player having to choose a save name. Having many of them gives you some snapshot history every X minutes and its a reasonable trade off especially if on load you just pull the most recent save to start off again.
Some traditionalist PC users use unsaved files as sort of temporary scratch space / undo buffer.
For example, imagine you've got a template for a presentation. You open the template, you add/edit as needed, then you save it with a new filename. You don't want it to autosave over the template.
Or you need to produce a cut-down version of an internal document to send to an external stakeholder, so you load the document, cut it down, then export-as-PDF. You don't want it to auto-save the deletions atop the original.
And of course traditional PC software didn't store a rewindable document history, and exiting the software discarded the undo buffer. So if the software auto-saved a cut-down version of the document over the original, the original was gone forever.
With autosave you've got to change your way of working, making the copy before you make the changes.
Emacs auto-saves to a temporary file (#<filename>#), it won't update your actual file until you yourself save. Can't get better than that. Never lose anything, never save a change you don't want.
Just do what Microsoft does with large Word documents saved on a slow network connection: Wait until I maximize the open Word document and then immediately start auto-saving, locking up the UI exactly when I started to use it again and haven't yet made any new changes. Genius!
Hi, author here. I think it's not a good idea to auto save just at random intervals. I certainly don't want my any of my apps to auto save without me telling it to do so. Maybe I'm old fashioned in this regards.
Unfortunately, the world now wants to be autosaved. One day, you might need to look at the usage pattern and AutoSave, perhaps when idle or after a set action is done (or fall back to the default timer). Otherwise, get a checkbox/radio that turns ON/OFF the options to "Autosave."
I'm not sure I want to go back to a world where I could lose a few hours work because I didn't save my work incrementally. (That said, as others suggest, you want to have a way to say known good/useful checkpoints as well.)
If you used programs like Lotus back in the day, you'd realize that that you tended to develop muscle memory to just quit in many cases. You also had crashes that kept you from saving as well.
Can I ask why? What is the harm in saving users work unexpectedly especially when I see a version history here?
I have been working with computers for 30 years, and I would find lack of a timed autosave surprising. Autosave was common on desktop applications in the mid 1990s. See: Everything in the MS Office suite.
The simple reason is that MapHub doesn't have a Google Docs like "time-traveling" version control nor Undo implemented. Undo is _really_ complicated if you don't start your app with that in mind. So the way to work is Save, try something and if you want to revert then you just reload the page.
Of course there is the "Previous versions" feature, but it still breaks my logic of Checkpoint-Experiment-Revert cycle. But I might be alone in this and users would be happier with autosave.
I expect web apps to auto-save because writing text in browsers is historically brittle, because browsers don't naturally persist the things you type into them anywhere. So if you don't create some layer of persistence, there is no natural point at which the user expectably saves things. Auto-save is just part of creating reliable, persisted data in web apps (regardless of whether that is local or remote) without expecting the user to do anything. There is no standard for manual saves to rely on, like there is for native applications that save to files.
So yes, you're old fashioned.
I still hit "Save" in every single offline or online app every time I've made a minimal change, because of old-timer PTSD reflexes: I used to edit files in vi over modem and telnet without screen (tmux), and if the connection had a hiccup, the connection died, my editor died, and the changes died with it. So saving (extremely) frequently was just a way to not lose your changes.
I started with Windows XP and things were so unreliable, with power cuts and software crashing that I saved everytime I took a break from actively working (switching programs, looking away, from the screen,…)
You could implement automatic saves on each change then, instead of regular intervals. You can also have a toggle, enabled by default, I guess, so the elderlies will have the option to make it like the good old times.
Yes, but the author (probably) implemented their save system where the client sends the entirety of the save data to the backend; meaning a lot of redundant information is sent.
Ideally, the client should only push changes to the backend and thus avoid the issue of sending redundant data entirely. This means re-implementing their saving solution, which is probably not trivial to do as you also have to deal with the issue of migrating existing save data to your new solution (which might mean some significant upfront costs).
The author didn't address this directly, but what they could do is just implement the autosave anyways and just deal with sending redundant data. But... this probably is quite expensive as the cost incurred per user is proportional to the size of the save data multiplied by the frequency of auto save.
Great question! Looking around, I notice that younger generations seem to assume ‘everything is stored’ automatically, without needing to do anything beyond creating content. For instance, in Google Docs, there’s no need to click ‘save’, that feels counterintuitive to the ‘save generation’ but works brilliantly!
On the other hand, I find it frustrating that every popular OS and web app now offers multiple options when working with files: save to the branded cloud (e.g., Google Drive), the filesystem, external URLs, ‘share-to’ options, etc. While intended to add flexibility, this approach introduces unnecessary complexity and indirection to what used to be a simple load/save feature.
> The thing is, you can only offer this feature if your app's architecture is designed from the ground up to support it.
Perhaps I'm misunderstanding something, but this makes 0 sense to me. The Save button itself must be able to save the current state. So at the very, very least you should be able to just check on a schedule what the current state is and determine if it differs from the previously saved state.
There are much better ways to implement this that take more underlying work, but agree with the other comments, this has nothing to do with people not understanding files, it has to do with people expecting web editors to autosave.
Autosaving means you often save a state the user didn't want to save, sometimes one they wanted not to save, erasing one they probably wanted to keep as a savepoint.
You can give them back the point-in-time or known-state recovery with manual snapshots or history tracking, but now your data system has to support that.
Lots of apps implement this by autosaving to a different location from the manual save. So autosaves overwrite each other, but they don't overwrite the user's explicit choice. On loading a save, if they detect the autosave is more recent than the manual save, they offer the user the choice of which one to use.
Microsoft Word has had this since the 90s (with slightly different presentation from today, and definitely without sophisticated history tracking). Their computers used to fail (blue screen) much more regularly. It's not about web apps vs desktop.
Exactly. The original problem was "people are losing all of their work cause they're not saving." So you autosave every minute or so to a separate "recovery" location, then if the user exits without manually saving, on next startup you give them the option to continue from the last autosave if that autosave is more recent and not identical to the last manual save. Doesn't require full change logging, and only requires one "last autosave" at any given time. IIRC this is how your Word example from the 90s worked.
But the article explicitly shows a „version history“ button, so going back when autosave saves something bad shouldn’t be a problem.
The key is Undo-Redo information is lost. On Google Docs you can "time-travel" almost on a keystroke level, so that's when auto-save makes sense.
Update, answered in detail here: https://news.ycombinator.com/item?id=42016231
I think you are exaggerating the importance of undo/redo. Even in google docs, if you restore from a savepoint you can only go backwards. And besides, the complaints OP got were "I'm losing all my work" - I doubt someone who had some recovery point would be in a worse position to recover than someone who had no recovery point at all.
(in other words, it's not necessary at all to support this feature from the ground up - it just might be necessary in order to have a third, even better way than "no saves" and "imperfect saves")
The "files" mention in the title is misleading, the saves here are done server side, which is made clear in the explanation about version history.
And that's where I think the author either doesn't have a mental image that matches what the user sees, or they like metaphors that don't really apply to their product.
I don't think we'll have a generation that doesn't know what saving is anytime soon: gamers in particular will still be be familiar with juggling save points and restoring previous states. Even people spending most of their computing time on phones will still see commit and save buttons in photo editing applications for instance, or most edit screens.
Pushing a button to commit changes is probably familiar to everyone, the chalenge is how to convey the need to push it, and visibly making the button text orange doesn't seem to be enough.
I work with files every day, and I'm not sure I would have realised I'd needed to save manually with the original MapHub UI either. A web-based interface that looks like that, I expect it to be transparent. If it'd had three icons (the classic blank page, open folder and floppy disk) in the top left, then I'd assume it would need manual saving. (I'm not saying that's what you need to do, just analysing my own intuitions)
The interesting bit is that for years this wasn't a problem. Like for 5 years I got 0 support requests about missing Save. Also web apps were not auto-saving traditionally, many of them still don't do it today.
Update, answered in detail here: https://news.ycombinator.com/item?id=42016231
It's very possible that if you showed me the MapHub UI eight years ago, I'd have intuited that I'd need to save manually---I can't tell for sure. I am definitely aware that the way I engage with software nowadays is very different than when I started using computers in the early 2000s, and I don't doubt it is still evolving due to the changing conventions in UI and functionality.
I 100% agree. This has nothing to do with files, but rather with expectations of how web apps work.
Maybe current web apps implement auto-saving with bad feedback, sure, but this factor should be taken into consideration when building new web apps.
I doubt it. Most school software still sends files over e-mail that you have to save as attachments, or upload your own document files. So they still learn that early, regardless of if they use it later in life.
How does that work for most people? Are they organizing the files on a traditional file system or clicking on an icon in the message to open them or picking uploads from a selector which blends cloud and and app boundaries? Based on my wife’s school and the one our son attends, a LOT of the areas which used to expose file system behavior have been removed or significantly de-emphasized.
Not the case universally. My son's school in south-central UK does everything via Google Docs or apps specially built for distance learning. If it weren't for Minecraft mods, he'd have no concept of the file system.
Well, in Google Docs you have something that looks a lot like a hierarchical filesystem (whether someone actually creates folders or not). The fact that it's not actually a filesystem as traditionally understood is sort of irrelevant. The average filesystem user didn't know about inodes, journaling, etc. either.
Author here, I'll try to collect my thoughts into one comment here about why there is no auto-save.
If you implement auto-save, users will expect every click/keystroke to be saved, like how Google Docs does it. Simply adding a 1-minute timer will make people lose work in the last minute, as they switch tabs, go offline, etc. and forget about it for days, when the browser clears tab state.
The other reason is that there is no Undo-Redo implemented on MapHub. Implementing Undo properly in a web app is not trivial if you haven't designed the whole app around a time-traveling state management. It's actually a really difficult problem to solve, even though it looks simple on the surface. Combining it with real-time collaboration is even more complex. Short story: there is no Undo-Redo.
So if you don't have Undo, then Save button plays the role of making a checkpoint, trying out something, reverting if needed. With autosave this could be ruined.
Also, you write that you expect every web app to auto-save, but this is still not the universal case today and definitely wasn't the case a few years ago. I agree that most VC-backed startups with hundred-million-dollar valuations have autosave in their web apps. Again, the proper solution is to have a time-traveling diff system implemented, which can easily get really complicated with real-time multi-user collaboration. Have a look at Figma's technical blog post about this topic [1].
You might be right in saying that it's not a generation of users, but the same users being conditioned to web apps doing auto-save. I agree this is probably the case. The point of the article is this definitely wasn't the case all the time, and how I've experienced this on my side, during my 8+ years of running MapHub.
[1] https://www.figma.com/blog/how-figmas-multiplayer-technology...
Disclaimer: I am not familiar with the product, so created a MapHub account just to try the exact experience. I usually mostly work with hiking maps and planning hikes, so my viewpoint might be off.
I feel the base disconnect is MapHub having very few indication of a workflow: one can create a new map and start working on it in a matter of seconds, adding markers etc. is also relatively quick, with help on the right panel guiding through the option, so it all feels natural.
In contrast the Save button is next to the zoom in/zoom out button, so outside of the tools area, neither in the right or left blocks where one would focus when editing.
The button is also greyed out when starting a map, and will always be visibly present, so after a few minutes I think we learn to ignore it as a visual element. In particular I never use the zoom in/out button (right now I straight pinch on the screen, but I guess touchpad pinch to zoom also works?)
I feel like the UI is really optimized for being out of the way and not having to think about versions. If autosaves are not an option, I think the save button would benefit from being a more "actiony" button and perhaps have a more prominent sibling in one of the tools or editing panel (and probably not just "save" but "save this map" or "take snapshot" or something like that ?)
My favorite map app has a big dark "Save" in a permanent footer inside the edit lists, and I better understand the reason now.
> Short story: there is no Undo-Redo.
OK, fair enough, but that doesn't have to preclude autosaving.
> If you implement auto-save, users will expect every click/keystroke to be saved. [...] Simply adding a 1-minute timer will make people lose work in the last minute.
I think a nicer compromise might be a simple debounced isDirty state. If it detects any changes, wait 5 or 10 seconds. If any more changes happen in that same time, wait again (up to some sane max, like a min or few). If no further changes, create a new automatic checkpoint.
It's usually not a big deal if someone loses 10 seconds of work. It is if they lose a few hours.
> Save button plays the role of making a checkpoint, trying out something, reverting if needed. With autosave this could be ruined.
Only if you make the autosave overwrite user checkpoints. Can't they produce their own separate bin of autosave checkpoints? Word has done that for decades, as have video games.
The user can choose to revert to "Blahblah save (10/31/24)" or "Autosave (3 min ago)".
Even if it is a generational thing, it's also just good UX IMO.
You are right, having two buckets is probably the easiest way to solve this. Then when loading the page it'd ask what to do with the autosave version.
Thanks for considering it!
Nothing to do with generations.
I simply expect a webapp to autosave. Period.
Manual save-points are still useful though if you want to go back to a previous version and branch off a different experiment.
Pretty much the same how (mostly PC-) games combine auto-save, manual quick-save and manual 'explicit' save (with a name chosen by the user), and where the last N auto- and quick-saves are preserved (where N is usually a fairly small number). It's less about not losing progress (for that, having only auto-save is fine), but being able to go back to a previous 'checkpoint' and branching off a new timeline.
Agreed, I'm seeing people of all ages not having to interact with the desktop metaphor at all any more. Typically people that manage to do all their "computing" on Android, iOS or sometimes ChromeOS (where they are email and SaaS based).
The metaphor is more of containers/projects and save slots/objects. Far more like video games than the traditional model.
Another option rather than complete rearchitecting the app is to autosave into an autosave slot. A lot of games do this to avoid the player having to choose a save name. Having many of them gives you some snapshot history every X minutes and its a reasonable trade off especially if on load you just pull the most recent save to start off again.
I don't understand why the author believes auto save would be so difficult to implement.
Just automatically click the save button for the user on a one minute timer. Done.
Some traditionalist PC users use unsaved files as sort of temporary scratch space / undo buffer.
For example, imagine you've got a template for a presentation. You open the template, you add/edit as needed, then you save it with a new filename. You don't want it to autosave over the template.
Or you need to produce a cut-down version of an internal document to send to an external stakeholder, so you load the document, cut it down, then export-as-PDF. You don't want it to auto-save the deletions atop the original.
And of course traditional PC software didn't store a rewindable document history, and exiting the software discarded the undo buffer. So if the software auto-saved a cut-down version of the document over the original, the original was gone forever.
With autosave you've got to change your way of working, making the copy before you make the changes.
Answered in detail here: https://news.ycombinator.com/item?id=42016231
Emacs auto-saves to a temporary file (#<filename>#), it won't update your actual file until you yourself save. Can't get better than that. Never lose anything, never save a change you don't want.
Just do what Microsoft does with large Word documents saved on a slow network connection: Wait until I maximize the open Word document and then immediately start auto-saving, locking up the UI exactly when I started to use it again and haven't yet made any new changes. Genius!
Hi, author here. I think it's not a good idea to auto save just at random intervals. I certainly don't want my any of my apps to auto save without me telling it to do so. Maybe I'm old fashioned in this regards.
Update, answered in detail here: https://news.ycombinator.com/item?id=42016231
Unfortunately, the world now wants to be autosaved. One day, you might need to look at the usage pattern and AutoSave, perhaps when idle or after a set action is done (or fall back to the default timer). Otherwise, get a checkbox/radio that turns ON/OFF the options to "Autosave."
I'm not sure I want to go back to a world where I could lose a few hours work because I didn't save my work incrementally. (That said, as others suggest, you want to have a way to say known good/useful checkpoints as well.)
There's a dialog asking if you really want to quit without saving your work.
If you used programs like Lotus back in the day, you'd realize that that you tended to develop muscle memory to just quit in many cases. You also had crashes that kept you from saving as well.
Yes, I agree, it might be a thing now.
Update, answered in detail here: https://news.ycombinator.com/item?id=42016231
Can I ask why? What is the harm in saving users work unexpectedly especially when I see a version history here?
I have been working with computers for 30 years, and I would find lack of a timed autosave surprising. Autosave was common on desktop applications in the mid 1990s. See: Everything in the MS Office suite.
The simple reason is that MapHub doesn't have a Google Docs like "time-traveling" version control nor Undo implemented. Undo is _really_ complicated if you don't start your app with that in mind. So the way to work is Save, try something and if you want to revert then you just reload the page.
Of course there is the "Previous versions" feature, but it still breaks my logic of Checkpoint-Experiment-Revert cycle. But I might be alone in this and users would be happier with autosave.
Update, answered in detail here: https://news.ycombinator.com/item?id=42016231
I expect web apps to auto-save because writing text in browsers is historically brittle, because browsers don't naturally persist the things you type into them anywhere. So if you don't create some layer of persistence, there is no natural point at which the user expectably saves things. Auto-save is just part of creating reliable, persisted data in web apps (regardless of whether that is local or remote) without expecting the user to do anything. There is no standard for manual saves to rely on, like there is for native applications that save to files.
So yes, you're old fashioned.
I still hit "Save" in every single offline or online app every time I've made a minimal change, because of old-timer PTSD reflexes: I used to edit files in vi over modem and telnet without screen (tmux), and if the connection had a hiccup, the connection died, my editor died, and the changes died with it. So saving (extremely) frequently was just a way to not lose your changes.
I started with Windows XP and things were so unreliable, with power cuts and software crashing that I saved everytime I took a break from actively working (switching programs, looking away, from the screen,…)
You could implement automatic saves on each change then, instead of regular intervals. You can also have a toggle, enabled by default, I guess, so the elderlies will have the option to make it like the good old times.
This is a classic xkcd workflow comic moment: https://xkcd.com/1172/
Mightn't it be better to actually just autosave?
Yes, but the author (probably) implemented their save system where the client sends the entirety of the save data to the backend; meaning a lot of redundant information is sent.
Ideally, the client should only push changes to the backend and thus avoid the issue of sending redundant data entirely. This means re-implementing their saving solution, which is probably not trivial to do as you also have to deal with the issue of migrating existing save data to your new solution (which might mean some significant upfront costs).
The author didn't address this directly, but what they could do is just implement the autosave anyways and just deal with sending redundant data. But... this probably is quite expensive as the cost incurred per user is proportional to the size of the save data multiplied by the frequency of auto save.
Where?
What do you mean, where? It's just saved right? Right?
Great question! Looking around, I notice that younger generations seem to assume ‘everything is stored’ automatically, without needing to do anything beyond creating content. For instance, in Google Docs, there’s no need to click ‘save’, that feels counterintuitive to the ‘save generation’ but works brilliantly!
On the other hand, I find it frustrating that every popular OS and web app now offers multiple options when working with files: save to the branded cloud (e.g., Google Drive), the filesystem, external URLs, ‘share-to’ options, etc. While intended to add flexibility, this approach introduces unnecessary complexity and indirection to what used to be a simple load/save feature.