general comments, two suggestions

[jan]

First, some words of praise. It was a joy to follow your tutorial and explore the many great features and subtle details of this program. So far, this is the most impressive thing I’ve found in my long quest for the ideal writing tool.

I'm sure I tried out all Mac programs aimed at writers, including other fascinating beta projects like Jer’s Novel Writer and strange, clunky beasts like Writer’s Café, and finally settled with Ulysses and Hog Bay Notebook; but Scrivener rules them all. In its current stage of development, it still has too many shortcomings to be considered "ideal" (more on that in a minute), but it’s close. You took the best features of Ulysses, CopyWrite, SuperNotecard and notebook programs like HBN, rethought and improved them, added some innovative ideas of your own and wrapped it all in a clean, intuitive interface. Well done.

Obviously, Ulysses inspired many parts of your program, from full-screen mode down to the layout of the preferences and the export window – makes me feel a bit sorry for the developers who invented all this stuff only to be outrun by a total newcomer. Luckily, there's the Channel between you and their ire.
Scrivener seems to be as much inspired by Ulysses itself as by the feature requests and complaints on their forum, and that's great. However, some interface details like the start panel are a bit too reminiscent of the original. I'm not sure if it would be wise to keep these in the final version. Scrivener proves in many ways that you can come up with clever ideas of your own, so why would you want to give the impression that you're imitating Ulysses?

As for my wish list, it mainly consists of general interface suggestions. My biggest problem with Scrivener is the very restrictive and inflexible implementation of categories. But I see that you're already aware of this problem, so I'll post my comments in the "root folders" thread instead. Which leaves me with two suggestions:

Binder / Compose mode
While the differences between Compose, Draft, and Storyboard mode are very clear – and very useful – I don't see much difference between Binder mode and Compose mode. It's hard to decide which one to use because they are so similar. Compose mode has more options for viewing and editing documents and a more flexible interface because it puts the notes pane in a drawer that you can hide if you find it distracting. The only exclusive and compelling feature of Binder mode is the Table view. Compose mode is just Binder mode minus the Table, plus some clever features like side-by side comparison of documents. Couldn’t these two modes be merged into a single mode? This would make Scrivener’s interface less cluttered and redundant.

My suggestion: Add Table view to Compose mode and get rid of the redundant Binder mode.


Switching between view modes
Say you work on a document in Compose mode. You switch to Draft mode to view it in its context, choose another document from the outline structure, then switch to Storyboard mode, shuffle the cards a bit, then switch to Binder mode to import a new file. At this point, your project has become a mess - or a maze – because whenever you switch to another view mode, you'll be in a different document.

This is illogical and puzzling. When you work on a document and then switch to another view mode, you'd expect to see the same document from a different angle, in a different working environment. Instead, you switch to a totally different document – the one you selected the last time you used this view mode – and have to find your way back to the one you are editing now. This is a serious workflow interruption.

I thought that the whole point of implementing different view modes was to give users the option to view a file in different contexts, with different options to arrange and edit it. But in its current implementation, this feature works like a document switcher, on top of being a view mode switcher. This can be very confusing, and it doesn't make sense. (I'm sorry if this long-winded explanation doesn't make sense either, English is not my first language.)

My suggestion: When switching to another view mode, Scrivener should keep the focus on the selected file. (If the file you are working on is not in the Draft category, none is selected when you switch to Draft view.)

Thoughts?

---
Disclaimer:
Yes, I do have a life. But this post is so insanely long that I don't mind if you doubt this claim

[KB]

Thanks for your comments - I'm glad you like the app. To address your suggestions:

1) The start panel.
I completely agree that this is waaay too much of a rip off of Ulysses' panel to go into the final release. I implemented it rather quickly as a user suggestion. Frankly, I can't think of what to put in there instead of "What do you want to do?" Any suggestions? So yes, it will change...

2) Binder vs Compose modes
I won't be merging these. Although the difference is subtle, I think it is important. As their titles suggest, Binder mode is for organising your files whereas Compose mode is for writing. The table in Binder mode is essential, as it can be filtered by label, status or by a search keyword (and in the next beta, by tags that may indicate themes or characters or anything you wish). But if I put the table in Compose mode, then there is not much room for other views. I created Scrivener on a 12" iBook, and want to ensure it is as friendly to users of such small screens as it is to those who have 21" screens. That means ensuring that there aren't too many things on screen at once. Compose mode allows you to have nothing but the outline view and a document, or you can compare documents and edit their notes and metadata. Binder mode is where you import your documents, add quick synopses as you do, etc. I hope that goes some way to explaining why I think these two modes shouldn't be merged.

3) Document retention between view modes
This one has been discussed on these forums several times before. Some users feel as you do, that the document should be maintained between view modes, and others - myself included - feel that the program would be assuming too much if this were the case. The solution is already on the "to do" list. In a future beta (that is, before official release), there will be a "Track document between views" preference that will allow you to choose this behaviour. It will be off by default, but you will be able to change it so that the document follows you between views. I don't expect that this will make 0.20b, but it should make it in somewhere between that and 0.30b.

Thanks again,
Keith

[jan]

I completely agree that this is waaay too much of a rip off of Ulysses' panel to go into the final release. I implemented it rather quickly as a user suggestion. Frankly, I can't think of what to put in there instead of "What do you want to do?" Any suggestions?

To be honest, I don't really see the need for a start panel. I disabled it in Ulysses because I found it redundant. It only reproduces commands that are easily available in the File menu so it wouldn't be a loss if you – or the Ulysses guys, for that matter – got rid of this panel altogether.

If you really want to implement a start panel, it should have some clever extra features that can't be reproduced via the File menu. At the moment, I can't think of anything useful either. (Hey, what about a template gallery à la MS Word? --- I'm kidding!)

I think it would be more useful to allow users to set Scrivener's startup behaviour in the Preferences ("On program startup, create new project / open last project / show list of recently used projects / do nothing").

But if I put the table in Compose mode, then there is not much room for other views. I created Scrivener on a 12" iBook, and want to ensure it is as friendly to users of such small screens as it is to those who have 21" screens.

OK, good point. I also have a 12" PB, but I thought that the limited screen space would not be much of a problem since the table can be hidden if it's not needed.
I still think that the differentiation between Binder and Compose mode is not clear and plausible enough compared to the distinctive features of the other view modes. But I admit that simply adding the table to Compose mode would probably not solve this problem.

In a future beta (that is, before official release), there will be a "Track document between views" preference that will allow you to choose this behaviour. It will be off by default, but you will be able to change it so that the document follows you between views.

Great. I'm looking forward to it.

[KB]

Well...

1) Users *wanted* the start panel, so it just goes to show that you can't please all of the people all of the time. Anyway, in the next beta you can turn it off via preferences, so no one should have cause for complaint. (Except the Ulysses guys, until I change it, of course.)

2) I think we'll just have to disagree on this one. I thought long and hard about the Binder and Compose modes. Their titles really give the clue as to their difference. In an earlier version you could replace the table view with another document for split views, but I actually found this less intuitive than separating them out into separate modes. It meant that you had to have extra controls to bring back the table view if you wanted it, for instance, and the user could end up thinking, "Hey, where has the table gone?" Better for the user to know that a click on the binder icon (or a simple Cmd-1 will take them straight to the view with the table.

3) I'm such a nice guy that I implemented this today. So from the next beta, you will be able to select "Track document between view modes" in the preferences. Like I said before, it is off by default, as I still prefer the other way, but there seems to be a 50/50 divide on this.

Thanks,
Keith

[shorn]

Just one small comment on this. I tend to be in the 50% that says you should be able to switch views and find yourself at the same place. I can understand the other point of view, however, and I guess it depends what you are doing at the time.

But there is one behavior I do find very annoying: if you are in any mode and then activate full screen, you always find yourself at the beginning of the full screen display. Conversely, and this is worse, if I am working in, say, the binder in full screen and then I want to pop back to check something in the synopsis or notes, I exit fullscreen but find my insertion point back where it was when I first opened fullscreen. I scroll to where I just was in full screen, I consult my notes, I reactivate fullscreen and again I am at the start of the document.

I can't think of any reason why that behavior would be useful.

[janra]

The second item kind of makes sense, in terms of switching modes putting you back where you were when you left that mode, just like it does with any two other modes. It's not the behaviour I'd want, but it seems like the kind of thing that's easier to code for :-)

I think that fullscreen should take its scroll & cursor position from the document that had the focus when you start fullscreen, and give those two positions back to the document when you exit fullscreen. But I don't know how hard that would be to do, or even if it's already been done as part of the state saving that's been promised for the next beta.

[KB]

As I have stated many times before, state-saving is something that will come quite late - it is getting added gradually. No, this behaviour is not helpful, but it is part of state-saving: something that has not been added yet. Remembering where you were in the document in and out of full screen falls under this category. It's just beta-behaviour, and will be fixed before release.

[janra]

Sorry, the state-saving that's been promised for release :-)