Upgrade to Lion

Tue May 29 02:21:04 EDT 2012

So... previously I was free to do whatever I wanted and at some point I chose "Save As..." if I wanted to keep my current version next to my new version. Simple.

Now I no longer have the freedom to do whatever I want, as Apple forces me to use their and exactly their workflow and nothing but their workflow. To replace the Save As... command with the Duplicate... command, Apple had to add a hugely complex system to my computer that uses a considerable amount of processing resources and hard disk space. MY processing resources and hard disk space. If I accidentally forget that I'm using a "current version", I have to hack my way through Apple's versioning system, find the right version and restore it, which takes a lot of time and effort compared to a simple "Save As...". 

And then all those other things such as a Dock you can't get rid of, useless Spaces, slow Exposé, processor time consuming Dashboard, slow Spotlight, expensive and slow Time Machine,... No thanks. My next laptop will run Linux and my next Mac will be a Mac Mini for testing only and I will postpone buying a new Mac for as long as possible.

--
Best regards,

Mark Schonewille

Economy-x-Talk Consulting and Software Engineering
Homepage: http://economy-x-talk.com
Twitter: http://twitter.com/xtalkprogrammer
KvK: 50277553

We will have room for new projects after 1 June. Contact me now and be first in line.

On 29 mei 2012, at 02:14, Igor de Oliveira Couto wrote:

> ------------------------------------------------------------------------------
> Understanding Old "Save + Save As..." x New "Autosave Versions + Duplicate"
> ------------------------------------------------------------------------------
> 
> When I first upgraded to Lion, I, too, became irritated and grumpy about the lack of a "Save As..." command. After many years of using a certain workflow, it becomes mechanical, intuitive, second-nature, part of you. I could not seem to understand WHY oh WHY did Apple have to change one of the basic methodologies for using documents in computers, which had over the years become entrenched in our computer culture, and in our minds.
> 
> As much as I tried, I could not get my head around this new way of working. It seemed more cumbersome and clumsy than the old one. Until one day, quite by accident, I found an article on the web explaining the rationale of it all. I wanted to post a link to the article here, but try as I might, I can't find it anymore - I seem to be running low on Google juice today...
> 
> So, as a poor alternative, I'll try to post my own version of that explanation, hoping that it may help others.
> 
> THE PROBLEM
> 
> The "Save" and "Save As..." commands always posed some workflow problems - and these were specially noticeable in newbie computer users. Starting from the fact that there are people that have been using the computer for decades, and still don't know the difference between them, resorting to just "Save As..." every single time. Kid you not.
> 
> The main problem with "Save As...", however, is that it presupposes that if you want to make a copy of a certain document, you will open it, then EDIT IT first, then afterwards remember to "Save As...". We all know, that when you first start using the computer, it takes several 'accidents' of saving over a valuable old document, for you to remember to do the "Save As..." FIRST.
> 
> And "Save" had a major problem, too: people simply forget to do it. Again, it usually takes several events of losing the work you've been doing for the last few hours, for a newbie to learn that they must SAVE ALL THE TIME as they work.
> 
> THE SOLUTION
> 
> Apple's solution to the "Save As..." problem was simple: get rid of the "Save As..." command, and replace it with a "Duplicate" command. The "Duplicate" command forces the user to make a copy of the document FIRST. If you open a document and start hacking at it before duplicating it, you always know that you are hacking at your ORIGINAL. As hard a concept as this might be for us, 'oldies', who were used to doing things the other way around, trust me when I say, that new users find this *a lot* more intuitive.
> 
> And the solution to the "Save" problem is also quite neat: after the user has saved the document the first time, just AUTOSAVE the document as the user works, all the time. Simple, and it avoids many, many hassles with data loss. 
> 
> -"But, wait there..." - you say. "When I work I like to 'try things out'! I don't my work 'automagically' saved all the time, because not even *I* know if I will want to keep it!"
> 
> That's where VERSIONS come in. As you work, each automatic save to your document is stored away as a 'version' of it. At any moment, you can 'roll back' to any previous versions, if you don't like what you've done. 
> 
> Now, these 'versions' are automatically created as you work, and stored away for you. So, if you have a long project, with a document on which you work day after day, month after month, that document will end up with a *very long* list of 'versions' in the system - which will take up *a lot* of storage space. To avoid that. your 'versions' are also automatically 'culled': it keeps lots of 'recent' versions - ie., for the last few hours/days of change - and then it starts deleting the older ones. Once it reaches the 2-month mark - if I remember correctly - it start erasing everything, as it thinks it's too old and probably irrelevant. So, in short: the system is deciding for you what it considers are the 'relevant' versions it should keep... Can you see how this could become a problem, too? 
> 
> Of course, there will be times when you want to tell the system to KEEP a certain 'version' of your document, and not throw it out. For instance, when you reach a certain point in your work which you think is 'stable', or a 'milestone', and before you start making any more changes. That is where the "Save a Version" command fits in. It forces the system to save a version of your document at that precise point in time, and tells it that it is relevant for you, so not to throw it out later.
> 
> CONCLUSION
> 
> Once I understood the reasoning behind these changes, I was a bit more emotionally prepared to give it a fair go. I must admit, although it took me a while to get used to it, I actually have come no just to like it, but to rely and depend on it. Recently, I was trying something out with LiveCode, and after almost 5 hours of programming, I had a system freeze. Once I restarted the computer, and then LiveCode, I had the sickening realisation that, now used to Lion's autosave, I had - like a newbie - simply not saved my work for all those hours... Had LiveCode supported autosave, my work would not have been lost.
> 
> I have also been caught doing progressive modifications to a stack, trying things out, and then realising that because LiveCode does not support versions, there was no 'easy way' for me to roll back those changes incrementally.
> 
> So, in my experience, although the change may be somewhat painful for those who are fossilised into our old working habits, it is ultimately a good thing, and something I hope that LiveCode will not only support in the future in its own IDE, but also something it will help us provide to our users.
> 
> 
> I hope this information helps others! :-)
> 
> Kind regards to all,
> 
> --
> Igor Couto
> Sydney, Australia