Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is there now a generation of users who never worked with files?

blog.hyperknot.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Is there now a generation of users who never worked with files?

#31

Post by echoangle »

bulatb wrote: post #21
hn_throwaway_99 wrote: post #11

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

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.

But the article explicitly shows a „version history“ button, so going back when autosave saves something bad shouldn’t be a problem.

Re: Is there now a generation of users who never worked with files?

#32

Post by makeitdouble »

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.

Re: Is there now a generation of users who never worked with files?

#34

Post by carwyn »

crazygringo wrote: post #7

Nothing to do with generations. I simply expect a webapp to autosave. Period.

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.

Re: Is there now a generation of users who never worked with files?

#35

Post by skydhash »

sshine wrote: post #20
hyperknot wrote: post #10

Earlier quoted context omitted.

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

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 exp…

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,…)

Re: Is there now a generation of users who never worked with files?

#36

Post by reginald78 »

donatj wrote: post #8

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. setInterval(() => { document.getElementById("save-button")?.click(); }, 60000);

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!

Re: Is there now a generation of users who never worked with files?

#37

Post by tempfile »

hyperknot wrote: post #17
hn_throwaway_99 wrote: post #11

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

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")

Re: Is there now a generation of users who never worked with files?

#38

Post by wslh »

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.

Re: Is there now a generation of users who never worked with files?

#39

Post by dmurray »

bulatb wrote: post #21
hn_throwaway_99 wrote: post #11

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

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.

Re: Is there now a generation of users who never worked with files?

#40

Post by hyperknot »

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

Post reply on HN