I am a new almost-user of Storyist--I say "almost-user" because I haven't purchased it yet. I'm on Day 5 of my 15 day trial period, and I'm currently in the process of (very slowly) getting my manuscript formatted into chapters and sections in Storyist so that I can continue working on it.
While going through this process, several things have come up that have made me worry that Storyist might not be reliable enough to trust my precious baby to its care. However, my son (a software developer who also writes fiction) has spent some time exploring the program and convincing me not to worry. Almost. So my plan right now is to continue the formatting process and assume that along the way I will learn enough about how Storyist works to feel completely comfortable with it--hopefully well before the trial runs out!
I'd like to explain the things that I find a bit disconcerting (in hopes that some of them might be considered as changes in the future), but I think a little background might help so you'll know where I'm coming from. I am a full-time writer. My current work-in-progress is far from my first book--I have ten novels published with Penguin (Signet Books), so I am pretty set in my ways as far as my writing process is concerned. All but my first book were written in WriteWay Pro, a Windows-only novel-writing application. I *love* WriteWay, but I switched to a Mac about a year and a half ago, and I have recently come to the realization that if I have to work in Parallels even one more week, I am going to become certifiably insane. ;-) Since I don't want to go back to working on a Windows computer (ever!), I decided to look around and see which Mac novel-writing application might suit me best. After downloading a few and playing with them, I decided that Storyist is the closest fit to my writing style.
My current project (written in WriteWay up to now) is a historical trilogy spanning 40 years with lots of research and characters in common. I am writing all three books at once, and the fact that Storyist will allow me to keep all three books in the same project--where I can share the research, settings, and characters--was a big part of my decision to choose your software.
I also really like the fact that I can design my own workspace. My preferred workspace setup won't work the way I want it to, however, which I will explain below.
So here (at long last!) are the things that I'd like to see added or changed. This first one is by far the most important.
--In WriteWay, I didn't have to number my chapters--the program did it for me. If I moved chapters around or added a new chapter in the middle, the chapters automatically got renumbered. As part of my process it is *very* common for me to take a long chapter and split it into two--in Storyist, as it stands, this will mean having to manually renumber every chapter that comes after it. One suggestion my son had was to allow users to title a chapter something like "Chapter <#>" with the <#> indicating that Storyist should use auto-numbering to fill it in. Apparently Scrivener (his personal app of choice for novels) does something similar. This way when chapters are moved around, or more are added in the middle, the user doesn't have to go through the long process of renumbering over and over (and over!). My novels average 70 chapters, so this is pretty important to me.
The rest of them are not as important, but would be nice. :-)
--When I switch to a different Main View area in my workspace, the item selected in the Project View doesn't necessarily change to match. I find this very confusing. After working with Storyist and having my son explain how it works, I now *do* understand it, but this is one of the things that originally led me to worry Storyist isn't stable. Maybe it's just because I've worked with WriteWay for so many years, but it seems intuitive to me that the Project View, which is essentially an outline of my book, should show me which item I am currently working on. The current behavior makes the Project View seem unreliable (i.e. not a safe place to store all the many, many sections of my manuscript with confidence that I can easily navigate to all parts of it).
-- I can see that blue text in the navigation bar indicates which view is active, but it is easy to overlook. In addition, clicking into the Project View does not change the blue text in the Main View navigation bar to black. This leads me to make mistakes, such as…
--…deleting whole sections and a couple of times even deleting my whole book! I think a user should need to do more than simply hit the Delete key to delete something as large and important as a section or a whole book. The problem happens when I don't realize I'm in the Project View (see above) and think I'm in the Main View editing text . . . I hit backspace (Delete), and--bam!--my whole book might be gone. Yes, I can find it in the Trash or click "Undo," but recovering from the near heart-attack is not so easy. ;-)
--My preferred workspace setup is the Project View on the left, with the Main View split into three parts--text in the middle, plus a third column split horizontally with the notecard for the text displayed in the top half (linked to the text so it automatically switches when I switch sections), and whatever bit of research I want at the moment (setting, character, historical stuff) displayed in the bottom half. This, however, is very hard to accomplish, because if I link the text and notecard views, the text shows up again in the bottom half of the third column. The only way to get my research there is to unlink, but that means the next time I switch sections, the notecard won't change to match. If you could make it so that each of the third column views locks to the text separately (so I can leave one locked and one unlocked), the whole system would be much better for me personally as well as more versatile for everyone else.
--I find the Trash icon confusing. I managed to find the Trash early on, then forgot where it was and had to hunt all over again. I've got it memorized now, but I think if you put a little picture of a trash can in place of the panel slide-up icon, that would be very helpful for new users.
And this is really, really picky--more a question, really . . .
--Why do you call them sections rather than scenes? Every novel-writing book and every working novelist I know (which is hundreds) calls them scenes. It took me two full days to really get it in my head that a section was a scene. At this point it's not throwing me anymore, but you might want to consider changing this, because I think it will make your app more approachable for novelists. Just a thought. :-)
Okay, that is the end of my feedback for now (about time, huh?). I hope you'll take all of this in the friendly spirit it was intended. I wanted to get my thoughts typed up quickly, because I have a feeling that as I get to know the program, most of these annoyances (other than the chapter numbering) will become invisible to me. They are the sorts of things only a new, confused user would notice and be bothered by, but I think that making things easier for new users would shorten the learning curve and probably help convert more trial users to permanent users.
My son typed up a few observations and suggestions as well, some of which is developer-to-developer stuff that's way too technical for me to fully understand. I'm going to paste his message below this in case you might find it useful.
It is my belief that as Mac novel-writing options go, Storyist is the best I am going to find. So I am crossing my fingers I will (quickly) learn to use it well and comfortably!
Thanks for listening!
My name is Brent Royal-Gordon. I am an independent iPhone and iPad developer with a fairly strong focus on usability. I am also, like any dutiful computer-literate son, the family "computer guy."
While helping my mother move her books from WriteWay into Storyist, I noticed a few usability-related issues I'd like to explain in more detail. They probably sound quite nit-picky when you just read them briefly described, so I thought it best to explain why I consider them problematic.
First of all, I should say that Storyist is an impressive piece of software. With a little more polish, I think it could dominate the authoring market. However, I noticed a few usability issues that make Storyist seem much less reliable than it actually is.
When starting to use a new piece of software, users construct a "mental model" of how it works. Deviation from this mental model, especially when the reason for the deviation isn't clear, makes the software seem buggy or confusing.
In Storyist, because there is one Project View for two panels, the obvious mental model is that the two panels display different views of the same item, which is whatever is selected in the Project View. The reality, however, is that the Project View controls only the active pane, and whatever you last clicked in the Project View stays selected, even if you switch active panes or move around in the document.
Careful experimentation will reveal that this is the way Storyist works, but for a writer who's just trying to get their work done (rather than a programmer trying to figure out an application that's confusing his mother), the behavior seems random and buggy because it doesn't match their model, and it's not clear that the model is wrong.
This actually encompasses three issues, all of which I'd suggest you address to make Storyist more understandable.
The Project View's selection should always reflect the current contents of the active pane. If you switch panes, the selection should change; if you put the insertion point in a different section, the selection should change. That way, the selection is always meaningful, and it's always possible to select a different part of the document to jump to it. (Or you could do as iTunes does, and leave the selection intact but mark the current item in some other way. In any case, though, the Project View needs to have some indication of what's currently being displayed.)
It is not obvious enough which pane is active, so it's hard for users to predict what will happen when they select an item in the Project View. (I know the text turns blue, but that's a fairly subtle change.) I would suggest that you darken the top "navigation strip" above the active pane, similar to the way OS X indicates active vs. inactive windows. This is not distracting (like a red dot, which Mom has told me someone else suggested, might be) but still obvious when you're looking for it.
When you select an item in the Project View, it's not obvious which panes have actually changed. The Mac Human Interface Guidelines suggest that tasteful animation can be used to draw the eye to content that's changing, and I think that would be a great fit for this purpose.
(Begin geeky details only an Apple programmer could understand…)
If it works the same way it does on the iPhone, the CATransition class in the QuartzCore framework makes fading and sliding transitions very easy to program. (Remember to turn on layer backing for any view you want to animate with Core Animation, though.)
(Okay, back to talking like regular human beings.)
Additionally, you *may* want to consider having locked panes be the default, because I think it's what users will naïvely expect from Storyist. However, these three corrections together should make the actual behavior obvious enough that users will quickly understand that the two panes aren't linked, so if you'd prefer they be unlocked by default, that's fine.
Another issue is that the pane-locking behavior isn't very obvious. Because each pane has a lock button, users assume that each pane's locking can be turned on independently from the others. However, as far as I can tell, the reality is that there is one global "locked" variable, and clicking any of the lock buttons toggles that global variable. It should either be possible to lock and unlock panes independently, or there should only be one lock button.
A third problem is that it's very easy to accidentally delete large portions of a project (like whole manuscripts)--all you have to do is hit the Delete key, thinking that you're deleting text, while in the Project View. This is of course recoverable by using Undo or retrieving the item from the (well-hidden) Trash, and my mother did figure this out on her own; nevertheless, thinking you've deleted your entire book is a nerve-wracking event, even if you can easily fix it, so it shouldn't be so easy to do accidentally. Please think of your poor users' hearts!
Mom's immediate suggestion was that it should ask for confirmation before deleting chapters or manuscripts, but the HIG rightly recommends against confirmations for undoable actions, and indeed other Mac apps like the Finder don't do that no matter how much data you're deleting. Instead, I would simply recommend using a keyboard shortcut that users aren't likely to activate by accident. Specifically, I'd suggest that Cmd-Delete (the same shortcut the Finder uses) be used instead of a plain Delete to delete an item from the Project View.
One more thing, and this is a little more marketing-oriented than the last two: the very first thing a new user will do (after playing around a bit) is try to import their manuscript, so the importing experience is very important.
I noticed that the import system tends to assume that your manuscript is in a single file. It doesn't seem to contemplate that you might be switching from a similar program, or even from a one-document-per-chapter setup. At a minimum, dragging a directory full of importable files into a project ought to import all the files in it into a single manuscript and recreate the directory structure. It would be even better, though, if Storyist could import files from similar applications.
(Dense technical details follow…)
I know that WriteWay files are basically collections of RTF documents wrapped in straightforward XML; importing from that program shouldn't be that difficult. Scrivener would be harder, as the binder file is an NSCoding archive of Scrivener's internal model objects, but at least a partial import ought to be doable. I don't know much about your other competitors' file formats (I only know about WriteWay and Scrivener because I once had to convert the former to the latter), but it might be worth looking into.
(We now return to your previously scheduled English text.)
Many imported flat files will not have a style that can be used to detect section breaks. You may want to consider adding an importing option that splits on a text string instead. This would save Mom tons of work.
Finally, sometimes users will have to import files where Storyist simply cannot detect the section breaks at all. For cases like that, a command to split a section in half at the insertion point would be very useful. Right now Mom is picking through a 400-page manuscript, manually copying and pasting each scene into a Storyist section; if she could split sections instead, that would dramatically speed up this work.
Best of luck with your business, and thanks for writing an app that might finally get my mother to stop complaining about Parallels!
Architechies Touch Software