Hacker News new | past | comments | ask | show | jobs | submit login

You should be glad that you still have any save menu, as they wanted to scrap that in favor of autosave.

Everything coming out of MS the last 5 years has been thoroughly underwhelming, but the UI development and user infantilization takes the cake.

Just image everyone in your company saves any document they opened automatically. How would these even look like after 1-2 weeks?

The decision processes at Microsoft cannot be explained by cocaine alone anymore...

Sorry for the rant, let's just say I understand your frustration...




Autosave is a safe and recommended UI practice; it has been widely implemented and validated by mobile UIs, where whatever you're doing is recorded when you close the app without having to explicitly save the document (a half written Whatsapp message, a mail draft...)

> Just image everyone in your company saves any document they opened automatically. How would these even look like after 1-2 weeks?

The essence of using autosave is separating storing from sharing the information. In an office suite, autosave should save your changes locally, so that a power outage won't wipe your edits.

This doesn't mean that other people will see those changes as soon as they're made; that's why you also create a "share" or "publish" command that will make them available. Developers got it and enjoy it in their version control systems, so why is it so difficult for them to understand that end users would benefit from the same safeguards? The first commandment of UI design is "treat all user input as sacred", yet so few developers respect it.

[1] http://quoteitup.com/quote/beUH/jef-raskin-the-system-should...


Autosave is a good feature, not only since mobile UIs. But not the way it is currently implemented that any change in the document is immediately committed to the original file if you didn't preemptively made a copy. Totally different to any version control system.

For example, we have a traveling expense document that is exported as pdf after people made their input. Since quite some time people can see what the last employee has been up to. Don't get me wrong, that can get quite funny. Possibly ad breach of confidential information, but meh...

We have no backend to publish to for these documents. It is just the boring file server.

There are certainly weaknesses in this particular workflow, but I would argue that it is quite common.


Committing instantly to the file is perfectly fine, as long as you have infinite undo (preferably with version history) and local drafts - i.e. exactly what VCS provide.

A shared folder in a server doesn't separate saving from sharing, but that's a fault of shared folders, not autosave. The popular storage models for end users are utterly broken, but developers don't care because they don't need to endure it, they've got their superior tools that they keep to themselves.


I don't really know if that is in the interest of the user. Just copying a file universally works with any file format and is a concept that users can understand.

A file has a name and a path, analogous to conventional storage systems. Putting it in a proprietary system like SharePoint or a Teams channel, to stay in the MS world, has other disadvantages.

I am giving them the benefit of the doubt, but sometimes I think the main goal for these "improvements" is vendor lock in, especially if the topic is around blurring file locations or URLs.

Access rights and relevancy of files is indeed something most alternatives organize better, but content tagging doesn't really work in my experience, because users just don't do it. So the only information about a files content remains the filename and the path.

Since those are fundamental concepts for data organization in most computer systems, it is advantageous to convey these ideas to the user and from my experience this is not that much of a hurdle.

Sure, a network share has disadvantages and without a competent clean up crew it quickly gets convoluted. But that is a problem all other systems have as well. So to improve the current situation, solutions should build upon file systems.

And asking the user if he really wants to save the file is probably just a good idea. If he ignores the message and throws away some work, he has learned a valuable lesson. Users on every knowledge level go through that experience at some point anyway. I think users suffer far more from most proprietary solutions for data exchange that is distinct from copying some files from A to B.


Copying a file so as to get intermediate drafts is an inferior solution to proper versioning, as any developer using a version control system will tell you (moreso if, like me, they started programming before VCSs were a widely used industry standard).

I agree proprietary lock-in is a pain and a huge risk, but I'm talking about fundamental storage models here, not particular implementations (where the problem is lack of interoperability, not the storage model; a proprietary file system doesn't create lock-in, because there are open standards to get your data out of it).

The best content storage model for end users I've seen is the wiki, where you get content versioning for free, although it doesn't separate storage from publication. A wiki where you could keep local separate branches of content would be ideal, but a.f.a.i.k. the only wiki system using that model (shareable local copies) is the Smallest Federated Wiki[1], and it hasn't gained much tracktion.

[1] https://github.com/WardCunningham/Smallest-Federated-Wiki

> And asking the user if he really wants to save the file is probably just a good idea. If he ignores the message and throws away some work, he has learned a valuable lesson

See, that's the kind of comment explaining why users secretly (or openly!) hate computers and think they go after them. Too many developers creating their software are actively disrespecting user's work and their time, even decades after human-computer interaction specialists found the best practices for caring about the user and making their life easier.


No. Autosave is the correct approach.

We computer people invented the concept of saving as an abstraction over the fact that unless what is in RAM gets written to disk, it is at risk of being lost once the computer is turned off or the program closes. The end user should never, ever have to worry about what is in RAM or on disk. The end user should expect computer documents to behave the way physical documents behave. Physical documents, and the changes people make to them, persist even after you stop working with them. We should go one better than the real world and autosave not just the document, but a complete undo history for that document.

It's not infantilizing to make your program conform to the expectations of real-world logic. It's bewildering to the user when your program does not.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: