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

In Lion, Apple changed the File model completely (everything is saved automatically by default. you no longer have any "in-flight" changes that aren't saved), but they haven't properly educated the users, causing people to assume it's "broken".

With the new model, if you want to edit a copy of a file instead of the original file, you need to Duplicate first. I've been bit by this a few times as well, since it's hard to break 20 years of habit, but from an outside perspective I think the new model is less technical and could be more intuitive to new users (real life has no equivalent to "unsaved changes").




"With the new model, if you want to edit a copy of a file instead of the original file, you need to Duplicate first. "

And this is why I think it's broken. There are times when I don't know ahead of time if I want to keep the edits in the document I've worked on, or 'fork' it and give it a completely separate name. Making me decide up front is forcing me to do more of the work instead of the computer, which is not how it should be.

I will probably bite the bullet and upgrade to ML this year - still on Snow Leopard right now, because I really don't like these sorts of mental model changes.


Apple's answer to this is that you if you made changes you don't want to keep, you should revert them. In Lion you had to use Versions for this, but Mountain Lion can revert to the last opened version.


That's an answer to the wrong question. I want to keep the changes I'm working on, under a new name, and keep the original untouched. Or maybe I made 5 edits to the original but the 6th edit I want in a new file (happens all the time). It just seems unnecessarily complicated. Having documents automatically save is great but it should require taking away so many other features.


You think the question is wrong because you aren't in the new model. Again- everything is continuously saved. There are no "in-flight" changes.

What you want to do is keep your the changes you made today and save a copy of an old version from earlier today. The way you do that is to revert the file to the beginning of the day, duplicate this "original" version, then revert back to the version with all your changes from today.

It's more steps, but hey, you retroactively decided a past version was important enough to save a copy of.


The problem with both the new model and the old model is they combine two concepts: storing your work so it isn't lost by act of God or stupidity and permanently committing those changes to a specific named file and version.

I want my work continually saved so that I never lose anything but that doesn't necessary mean I want it committed every minute. What I really want to do is commit my current work to a new name leaving the original document unchanged. Duplicating then reverting achieves the same result but feels much more like I'm doing something to please the machine instead of the machine fitting to what is a common work style.


Well put. Again, we're being forced to do the work for the machine. Having multiple automatic commits happening in another area that is something we can pull back in between actual manual 'commits' ('saves') would have been a much better alternative.

Once I 'save' to a different file name, from what I understand, automatic saves are still happening to the original file and filename - why? That makes no sense however you slice it.


Indeed, real life has no equivalent to "unsaved changes". And it sucks.

Thats why a smart entrepeneur developed the eraser.


And why OS X Lion/ML has Versions and Time Machine


That is not an eraser, thats making a copy of your current work every minute, try something new, and if you don't like it, stop what you're doing and retrieve the old one from the filing cabinet.

So now every program needs an infinite, crash and restart resistant, fine grained revert option.

I applaud Apple for their braveness in changing such a core functionality, but I don't want to imagine the trouble this brings when accessing data on network shares (or even the lifespan of your SSD cells).


> So now every program needs an infinite, crash and restart resistant, fine grained revert option.

Yeah, which is why Apple added that in Lion so anything using NSDocument get it for free http://support.apple.com/kb/HT4753


Interesting. So they didn't really take away "save as" snapshots, just the ability to name them and get to them through the filesystem.


So that whenever I want to do exploratory work that I probably want to either fork or toss, I have to go into time machine to do it, rather than simply not saving, or saving under a new name.

Apple is quickly losing touch with reality.


Or choose Duplicate on the old file, don't save the copy/give it a name, and do the work in there.

Since Lion, OS X also internally autosaves files that have yet to be saved. I've had 3-4 "Untitled" TextEdit files that I haven't saved hanging around for months, across reboots.


I don't mind some internal backup-copy (including undo/redo state) being made of what's currently on the screen so that it can recover from a crash, but actually modifying the file I loaded from when I never told it to save is just bad, bad, bad.


Known to Mac users as Command-Z for "Undo".


That is broken. Unsaved changes should be committed to a file that is likely your current file. This would allow them to properly implement save as.

They're leaving state management up to the end user which is almost always a bad idea.


>real life has no equivalent to "unsaved changes"

Yes it does. In my real life, the computers I have been using most of my life had the concept of unsaved changes.

This reasoning is ridiculous. I don't want my computer to behave like some other thing, including arbitrary limitations. I want it to implement the features of a computer, constrained only by the limitations of a computer.

"You can't do X because this other old fashioned thing you never use nowadays couldn't do X in the old days" is a pretty piss poor excuse.




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

Search: