Criticism on default settings

In the Options > General > Startup window, the first item “Reopen projects that were open on quit” is selected by default, so when I installed this new beta ( the 64bit version ) and ran it for the first time, it automatically opened the project I was working on in the 32bit version ( 1.9 ) … which was unexpected, and it immediately converted this to your new form for the v.3.0beta … now fortunately you have it created a backup, and I had also created a copy, but my desire was to use the copy I made, and I had no idea this option would be selected by default, which I think is a pretty bad idea if the program is capable of picking up what was last used by what should have been treated as a completely separate program given that v 1.9 is the 32bit version installed in C:\Program Files ( x86 ), whereas the 64bit beta is installed to C:\Program Files … would it not have been better to NOT have that option selected by default given that this is a beta and it’s going to do that with people’s existing file/folder structure? Sure it’s no big deal in the respect that I can clean the mess up later, but why would you cause an unnecessary extra workload, when you can just avoid it by not having that option selected by default in the beta?

Hi galacticpresident,

Prior to converting your project to v3 format, the beta should have presented you with a message, “Project created with older version, convert to latest version?” or something like that, giving you control over the conversion.

Did it not do that?


yes it gave that message, but it didn’t tell me what it was referring to, so I assumed it was referring to some other default document it was going to open ( like the tutorial ) … I had no idea it was going to do it to my existing document, because it didnt tell me which document it was referring to, and there was also no warning that setting was selected by default.

Understood. I asked because your OP description of what happened made it seem as if the beta converted your project without first giving you a choice to cancel, which to my mind would have been a definite bug.

It is possible that the beta picks up your current Scrivener 1.9 options, and hence tried to open your most recent project, but I’m not sure about that. I’ll let L&L answer. But it seems to me that picking up the user’s current Scrivener 1.9 options would be the desired behavior when a user is actually migrating to the prod version 3, so it would make sense for the beta to work that way too.

Just my $.02.

The way we handled this on the Mac was by giving v3 a clean break from all previous preferences. In fact to get your settings copied over, you’d have to use the mechanism for saving your settings to a file from v2, and then load that file in v3. So the notion of having previous documents opening automatically was never an issue.

You’re reporting on one aspect of how that can be a negative, but consider the other side: from our experience in how things went with the v3 upgrade on the Mac, one of our top repeated tech support questions was: “PANIC: I upgraded and all of my books are completely gone!”. Of course they weren’t, but the Recent Files list was empty (preferences) and if a user solely relied upon Scrivener opening their project and maybe doesn’t even know where that project is saved on the disk (or indeed that it even uses the disk and isn’t some ethereal thing stored in a “cloud” at their behest), they could not be blamed for thinking all of their old work was lost.

So the question to my mind is which of these two outcomes is worse:

  • Your previous work loads in v3 and you are asked if the project should be updated.

[list][*] If yes: you get a v2 backup created on the spot, so the decision can be reversed.

  • If no: it doesn’t load and you move on.
    ] Nothing loads, it’s like installing a new program from scratch. It’s up to you to figure out how to access the work you had readily available a few minutes ago.[/*:m][/list:u]

I understand you are mainly looking at this from a standpoint of whether or not it is good for a beta to do this. Maybe not, I’m not sure—I’m more of the mind that a beta should aim toward its final functioning in every way, rather than having concessionary code added to it. Otherwise once that is removed you have to test its final fitness all over again in these areas.

This rumination aside, it does sound like we need to mark the upgrade dialogue a bit better. I’ll take a look into that for sure. It should at least say the name of the project that it is asking about.

Amber I understand what you’re saying, but the problem is as easy to solve as this:

– make the message window tell me the full path and filename it is referring to when it tells me that it is going to upgrade the file << problem solved allowing for all concerns – ie: I think your “which is worse” is a false dichotomy, as we do not need to put up with either scenario if the message simply provides more detail ( it currently provides no detail at all ).

Indeed, as I noted at the end of my post. :slight_smile: