We use an internal group of known testers, sorry. Actually, the way we do it is we just keep an eye out for users on the forums or who write to us and who seem to be good at finding and explaining bugs, or who seem particularly knowledgable about the program and help other users out a fair bit. We then invite such users to the beta list whenever we need more beta testers (although I’m certain we miss a lot of users like that, too, and don’t mean to slight anyone). This way we know we have beta-testers who know what to expect from the program and who are fairly good at reporting bugs and who aren’t likely to shout at us when they lose data during early beta-testing stages (although obviously we try to avoid such things!).
A few years ago, my team decided to try to widen the beta group. I loved bug reports sounding like this: “This thing doesn’t work!!! You should fix it!!! This thing stinks!!!”. And then, we found new features discussed in our competitor’s forums, sometimes accompanied by detailed photos.
Well, I don’t post a lot, but I do use Scrivener on a daily basis and am a professional QA Test Lead in my non-writing life, so if you find you need another… I do have two ipads (4 and A2) and an iphone (5s) at my disposal.
Been a web developer for years, so I certainly now how it goes with bug reports. I find it VERY annoying when people say “this doesn’t work” . The more details, the better to track these down.
It’s funny when I go in for a Genius Bar appointment for my Mac. I’ll explain the problem, including under what conditions it was reproduced and not reproduced, providing log files, outlining research done on the InterWebs & the Google, basically anticipating 75-80% of their questions. Then I explain that I develop software for a living and I know what it takes to fix a problem.
It’s a huge improvement over V2, and is compatible with Dropbox and iCloud.
That said, Storyist is clunky to say the least compared to Scrivener. I have to reset my mind each time I work in Storyist, and find the novel I’m working on there takes longer to achieve results than Scrivener, which for me has become second nature. I am using Storyist on this project because I have to be able to do most of the work remotely and lugging a laptop isn’t an option. I looked at Ulysses, but their minimalist approach just doesn’t suit me.
Based on the descriptions given by Kevin and other staff, I’m hanging out for the iOS version of Scrivener. Alpha, Beta, ANY version!
We should have solid news on the iOS version (with screenshots and everything) soon. I don’t want to talk too much about it, or post screenshots, until it is feature-complete and in proper testing. Right now, Tammy is finishing off the all-important sync code (the back-end of which I wrote and tested last year for Mac and iOS - the Windows team still has to write that code, which will take about a month, during testing, once we know the sync code is working well between Mac and iOS, Mac being the guinea pig here). Once that’s done, it’s on to testing… Lots and lots of testing, and lots and lots of bug-fixing, now doubt.
[I’m ducking as I’m writing this. lol]
Now that we are in the new year, is there a launch date for Beta testing Scrivener for iPad?
I’m not a techie. I’m assuming when Beta testing is done, some regular users of Scrivener are chosen, correct? I would be lousy at it. However, knowing that Scrivener for iPad is that far along to be in ‘beta testing’ would be just awesome and I know the right people will be providing constructive feedback.
Please don’t anyone make any suggestions for me to use other apps.
There’s not a set date, but we’re close. We expect the app to be complete at the end of this month (yes, a week away) and to enter internal (within L&L) beta-testing early February - although I hasten to add that it has been in alpha testing throughout the past few months of development, with Ioa weeding out as many bugs as he could for Tammy to squash along the way. It won’t go out to a wider beta-testing group until we are happy we have fixed all of the bugs we can find ourselves. The biggest part of that will be testing the all-important sync code - that needs extensive testing as it’s the area that can potentially cause data loss (although it’s set up not to, of course!). It’s impossible to say how long that will take, because it’s not something we can set a time limit on - it will take as long as it takes to fix any issues that arise. It will then go out to a wider beta-testing group, at which point we’ll write the tutorial for it and get everything ready for release. It will then be released once we are happy it has proven stable among the larger beta-tester group. I will post something more detailed on the blog - including some screenshots - once we’re getting towards the end of internal beta-testing.