Q: Disable autosave

Sooner or later every software on Lion will be adapted for Autosave and Versions.

Ha, not in my lifetime. Plus you won't have to update something like BBEDIT for a good long time. Right now you can't disable those features so why fight what you can't change. That's the definition of insanity.

AndreasSt wrote:

 

coocooforcocoapuffs wrote:

 

The solution there of course is to use another editor. I am surprised to see so many people using textedit and preview for serious work...learn something new everyday eh?

 

No it's not. Sooner or later every software on Lion will be adapted for Autosave and Versions. That's why I need an option to fully disable those features. At least I need an option to lock the files automatically when closing them. A whole day is way to much time to accidentally currupt them.

What are you talking about - cant you see from previous posts that autosave and versions is the most majestic piece of os feature implementation that has truly revolutionized operating systems and user experience by taking the user sensibility out of the equation and replacing it with Apple's idea of what a user needs to do .

The problem is not whether or not to use textedit but whether or not to continue using mac osx as any kind of serious os. I have abandoned it, abandoned development on mac - just dropped apple. Keep a copy of my waste of money paid version of Lion around just to show clients why not to choose apple.

I say, learn something new everyday eh? - dont waste your money on other people's (Apples's) flawed ideas and lack or responsibility.

Just think developers - if you would have submitted a sub-par application like lion to the app store - do you think it would have gotten through review?

papalapapp wrote:

 

The solution I would prefer is to make the "Save" command as a kind of snapshot. Closing the window (cmd-W) of the document would automatically save the work but also having the coice of closing it without saving since the last snapshot-save by hitting for instance alt-cmd-W.

Actually, this is exactly what the save command (now called "Save a Version") does now. It is a snapshot of the file. Also, if you don't want any of the work you're doing a file to be Auto Saved, then you can lock the file using the pull-down menu in the document title. <http://www.apple.com/macosx/whats-new/features.html#autosave>

I think if you learn more about how AutoSave and Versions work you might see how useful and powerful it can be. I realize you want to be able to have more control over the features, and I agree that would be a good thing, but as they are now I can see how they might not seem very useful until you learn how to work them into your workflow.

tim ferris wrote:

 

I have a theroy, It might not be the auto save thats bad, its the explination of it and how to use it maybe? It took me ages to find out where auto save was and how to "go back in time" on a document. In the end i called Apple only to find out its hidden in a drop down menu on the doc name. Not very user freindly or clear

It's also in the File menu, the item called "Revert to Saved."

Michael Allbritton wrote:

 

papalapapp wrote:

 

The solution I would prefer is to make the "Save" command as a kind of snapshot. Closing the window (cmd-W) of the document would automatically save the work but also having the coice of closing it without saving since the last snapshot-save by hitting for instance alt-cmd-W.

 

Actually, this is exactly what the save command (now called "Save a Version") does now. It is a snapshot of the file. Also, if you don't want any of the work you're doing a file to be Auto Saved, then you can lock the file using the pull-down menu in the document title. <http://www.apple.com/macosx/whats-new/features.html#autosave>

 

I think if you learn more about how AutoSave and Versions work you might see how useful and powerful it can be. I realize you want to be able to have more control over the features, and I agree that would be a good thing, but as they are now I can see how they might not seem very useful until you learn how to work them into your workflow.

And there you have listed every reason why this mechanism is so utterly wrong. What Apple here has done was to replicate every mistake literally the early versioning systems did. Again a proof that no software engineer hat a serious word at the design of this, or not a single one with a serious versioning system experience.

Mistake

a) hide the lock unlock semi undocumented in an area where no user expects a menu

b) Take away from the user the ability to have control over his actions

c) Lock the documents automatically after a while, I will see the discussions in 2-3 weeks when the users start to complain that hundreds of their documents got suddenly locked

d) Use a locking mechanism at all, which is absolutely idiotic given the experiences software engineers had in the last 20 years with locked versioning (believe me they have been really bad)

Sorry to repeat myself but given all the experiences from the one field which really has a lot of experience with versioning the Apple implementation is broken in every corner of its existence.

What apple did basically was to replicate all mistakes old versioning systems like rcs or vss did, but even worse it took the entire control away from the users. So what you get is an RCS with big brother trying to enforce your workflow.

If you want to see this mechanism working properly and well implemented download a copy of Intellij IDEA, Netbeans or Eclipse and check out their local history mechanisms (which they have had for years btw...), no locks, full control, works seamlessly but does not get in the way of the workflow of the users.

The reason why this works so well there is that the local versioning is only activated on save, there is no locking and unlocking. The entire locking and unlocking is pointless in the first place and was sort of tacked on due to the problem of autosaving. The problem with locking and unlocking is basically that it is a pain and causes more problems especially with group work and if you have to handle lots of files than it solves.

Werner P. wrote:

 

...

 

The entire locking and unlocking is pointless in the first place and was sort of tacked on due to the problem of autosaving. The problem with locking and unlocking is basically that it is a pain and ... .

That was also my first impression as I met my first autolocked file. A quick (and dirty) fix for a concept that is not yet woking propperly.

Eliminating the dialogue whether to save or not on closing the document is a step towards iOS behaviour. Well, I understand the wish to have a clean and lean mac with only the minimal amount of menus, dialogue boxes and stuff. But then, it must be consequent and also be able to "undo" all the steps previous to the last closing of the document like in iOS. The way it is now one can only use the menu to go back to the last saved status. It feels a bit like getting new disadvantiges and at the same time losing the good stuff.

I use TextEdit 1.6 from Snow Leopard and iWork 08 in Lion to avoid of the horrible autosave feature. I guess Preview is lost case though...

I think if you learn more about how AutoSave and Versions work you might see how useful and powerful it can be.

I think there are even more hidden powers we are not seeing yet (fully). I've written about one power here, but I have not found another to verify my findings:

https://discussions.apple.com/message/15776009#15776009

Any help is appreciated. Thx!

To all who don't like Autosave and Versions to any degree:

This isn't a direct fix, but one tip is to send Apple feedback and ask them if they could possibly make Autosave and Versions optional. After all, there's a chance that Apple will read it and seriously consider it. After all, while I think that Autosave and Versions are excellent, very useful features, it simply doesn't work all the time and for everyone and so should simply be optional.

Tiff

After all, while I think that Autosave and Versions are excellent, very useful features, it simply doesn't work all the time and for everyone and so should simply be optional.

Tiff, I think there are underlying reasons for this change (if interested read here). For the grand plan to succeed, as it has already been put into place with FCPX, it can't be optional. Apple does this all the time, and is one of the things that makes it stand out from other like-companies. Just one example mentioned in this thread already is the move from floppies to CDs. They lead. We follow. Cheers

Wow... This makes me want to go back to Windows after 5-years with Apple

Lion = Vista

RegimeChanger wrote:

 

The problem is not whether or not to use textedit but whether or not to continue using mac osx as any kind of serious os. I have abandoned it, abandoned development on mac - just dropped apple. Keep a copy of my waste of money paid version of Lion around just to show clients why not to choose apple.

 

I say, learn something new everyday eh? - dont waste your money on other people's (Apples's) flawed ideas and lack or responsibility.

That's correct. I already stopped recommending Apple products to other people.

Now have any of you users up above, and to put it lightly - no I wont say that - complaining about a new feature in a *.0 release of an OS...

Have any of you even tried to see what would happen if you set the permissions on .DocumentRevisions-V100 to 000?

I don't feel like attempting this myself, as I used to use a third party program called "Forever Save" which let me add applications I always use and force it to save every 5 mins, every x application swaps etc and to keep x versions of the document.

Now of course, because this wasn't an OS level change, I had to opt-in to this, but every major application I used, iWork, Office etc had this enabled.

One thing I have found is that while saved state is useful on many apps - a similiar level change to auto save, you can prevent it running for x app by changing the permissions on that folder to 000.   Or to do it cleanly defaults write com.apple.Preview NSQuitAlwaysKeepsWindows -bool NO”

Working IT one of my biggest headaches is users who ring up and ask..  My computer crashed, can you get my document back..

My question - did you save?    Yeah - but it was yesterday when I finished working, not today...

Does the implementation need work - yes, but is this a needed feature - yes.

On any system, there are always users that need to be protected from themselves.

Does the implementation need work - yes, but is this a needed feature - yes.

On any system, there are always users that need to be protected from themselves.

The problem here is the assumption, for any systems there is a certain percentage of 1-5% of cannot cope with a system, but does the rest of the users who are just fine have to suffer from 5% dumbwits who are eather uneager to learn how to use a computer or unwilling to learn it.

Thats the biggest issue modern design has, they try to settle down to the lowest common denominator instead of trying to settle down on what the average is fine with.

Now back to the topic, first, apple has reproduced every mistake versioning systems have gone throught the last 30 years without having had learned from their mistakes.

Second by trying to gather to the 5% being as dumb as a toilet seat crowed they made life miserable for 95% of their other users by not allowing to turn the mechanism off.

So did they achieve what they obviously tried, yes, they hit the bottom and helped those

Is their implementation good, no, they follow a workflow which basically has been seen as broken workflow since 20 years in software development

And yet you make the assumption that its 95% of the user base that currently has lion that are miserable.

Judging a userbase by this forum, isn't ideal.

I would say that its the same percentage as ever with new change - the very vocal minority - that are unhappy with the changes and are doing nothing to change it (I would guess that out of this entire thread, only one or two people have submitted official feedback/bug reports, or are prepared to debate this logically) and the rest are merely getting up on a soap box to expess their displeasure.

I plan to sit down and spend some time experiementing with versioning soon, and yes it does need a lot of work.   But they took the iOS implementation of it which does work on iOS - but isn't flexible enough when you get to a full fledged OS and expect users to be able to go back through the versions.

Many of the issues I see when a versioning system isn't used, is not being unable to undo enough (Hence why I like Adobe's history from Open to Close - assuming it has sufficient memory etc).

I will have to see how it handles large media myself when I am dealing with the keynotes and movies next time, and that is when I think I will be looking at some issues in my own work flows.

I can also see, how the improvements demonstrated in FCPX as indicated above will be integrated into the iLife Suite in particular, and how it will benefit users down the track.

Perhaps a dual layer approach to versioning - with a "last save" in the right column, and multiple versions of the last save - with each save having all the changes made since that save in a middle column, and the current version in the left.

Then on opening a versioned document, provide two previews and give the user a choice - open last saved, or last modified version...

That still doesn't cover how they could get around large media items, but I am sure someone else has an idea about that.

Perhaps if each document or app had two check boxes in the upper right - the left one pertaining to the active state of versioning - on/off and the right one - the active state of saved states - on/off.

It would let you use versionng in smaller documents, but in rich media docs - turn it off, or turn automatic versioning off, but allow saved versioning.

If nothing else, between auto save and saved state - text edit has turned into a glorified notebook - its quick and easy to take notes, and then quit.

For any serious text work I have always used, and will probably continue to use coda.