This already happens in Scrivener. If you have a short autosave time you have probably never seen it. I think the default auto save time is every two seconds.
A manual save can be quickly achieved by using the CTRL + S keyboard shortcut.
This is unlikely to be needed unless you decide to increase the time to autosaves to something like a couple of minutes.
Click on an existing card, then hit the new text button in the bottom of the Corkboard View. This will create a new card in Corkboard View and not shift you into the Text View.
I don’t know if Lee is planning for the same thing on Windows, but on the Mac the project is marked as “dirty” if it has unsaved changes, but if you leave the default auto-save time at two seconds, you have to be looking in the right place just at the right time to see it.
As Stacey says, I’m sure you must be able to do a manual save at any time. Doing a manual save on the Mac also does a back-up just as you get when closing the program.
Again, if the Windows version is going to follow the way the Mac version works, it will not only autosave before closing, but also do an automatic back-up to whatever location you have set in the preferences or whatever the equivalent is called.
Auto save shouldn’t be overwriting my main project file, since that means I can’t go back to my original version if I need to. It should save to a separate temp file. It should be my choice whether or not to commit changes to my main project files.
There are always choices to make in implementing functionality. Some of the current choices don’t follow “standard” Windows usability guidelines, making the program unnecessarily difficult to learn. Sure, you can save files a number of ways, but one way almost everyone implements is via a toolbar button.
The same goes for the corkboard. I expected the app to add a new card when I’m looking at cards. The apps didn’t do what I expected. So it’s not a “bug”, but it’s something you might want to reconsider.
Only if you took an actual snapshot at the time. I like the value that Scriv provides with this, but it’s been a difficult road adjusting to it, and I for one would feel more comfortable with a future version of Scriv offering me a bit more control over the autosave behavior.
There is a pertinent discussion of this in another thread, though I can’t find it at the moment. The point is that a Scrivener project is NOT a file, it’s a whole folder full of files which can easily run into hundreds — on the Mac it looks like a file, but is actually a package … a special kind of folder; the project I use every day is not that big compared with many people’s but it has some 1,200 separate files in it. Think of a Scrivener project more as a form of database, and what really functional database doesn’t save automatically as you’re working.
When you make a change in what looks like a file to you, other files are also being changed to bring them into line with the one you know you have changed. In order to keep the thing running smoothly, Scrivener is only loading into memory those document files that you are actually working on, not all the others in your binder, inspector, notes …
Hence the need for the autosave; without it things would easily and soon risk going haywire. But you have, or you should eventually have, a number of options: you can extend the autosave period, though that carries risks … especially with a beta; you can take a snapshot — I assume that’s working — before you embark on a major editing session, which you can always go back to; you can set the back-up routine to save a back-up copy of the project, compressed or uncompressed as you prefer, on opening as well as on closing; you can do a manual save, which if you have the back-up preferences set will save a copy of the file at the beginning of a session, in the middle of a session whenever you wish, which will also do a back-up save; and you can do a “Save As” to save the project under another name and/or in another location.
I must admit that I don’t know how many of those possibilities are fully functional in the current state of the Windows beta, but as you can see, there are plenty of options for saving your project in its current state at all stages during an editing session, so you have an “original version” to go back to. In the meantime, the autosave keeps everything in sync.
The developers have a choice. They can make a version of the program that mimics the Mac version as closely as possible, or they can make a version that keeps the core functionality (basically, the editing UI) and implements the other details in a way that’s “natural” for Windows users.
One way makes it easier for existing Mac/Scrivener users who want to move to Windows. The other makes it easier for existing Windows uses to start using Scrivener. If the developers are interested in making huge gobs of money, it’s obvious which potential market is larger.
That being said, it might be easier to maintain the code down the road if the two versions are as similar as possible, and that can be a major factor in design choices too. But it’s a choice that will impose limits on sales. Windows’ standards may not be “better” but potential users are turned off by change.
And writing this note is just a way for me to procrastinate
One of the key features for the developers is that projects should be immediately transferrable for people who use both platforms, and that means identical architectures. Furthermore, I don’t think that there are UI differences between Windows and the Mac that should change the underlying philosophy behind the structure.
If you want it all as a single file, that can have temporary back-up files until you do a manual save, use Word. I don’t personally think it would be a good idea to have to be saving all my 1,200 files each time I did a manual save. But then, I’m a Mac user and your mileage may differ.
Given that many other Windows programs that do things similar to Scrivener - such as Liquid Story Binder and PageFour, for instance - use a folder structure for their file format, I don’t agree that this is going to be a massive issue for the majority of users. The file format is best for both platforms, given that a Scrivener file could contain videos, many images, many PDF files and thus grow very large. Having all of that read into memory would be slow, and with projects as sensitive as novels, scripts and academic theses, there is a distinct advantage in the folder format - if there is a single file storing everything and it becomes corrupted, there goes your work; if there is a folder of files and the project file or another single file becomes corrupted, you can still extract everything else and you haven’t lost all your valuable writing. We redesigned the file format from the ground up so that it would be suitable for both platforms, in fact (the old, Scrivener for Mac 1.0 format wouldn’t have worked on Windows at all), and we considered many options.
Oh, and by now I’m rather used to being told that our sales will suffer unless we do [insert-user’s-request-here], so that old chestnut is like water off a duck’s back, I’m afraid (yes, it’s that mixed-metaphor time of the evening).