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.

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.

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...

I simply expect a webapp to autosave. Period.

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.

Just automatically click the save button for the user on a one minute timer. Done.

    setInterval(() => {
        document.getElementById("save-button")?.click();
    }, 60000);

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.

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.

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.

Update, answered in detail here: https://news.ycombinator.com/item?id=42016231