Drawers versus Panes

[amberv]

I am not a huge fan of drawers, to be honest about it. One of my main problems with it is how they act with small screens. I am on a small 15" clunker that I desperately need to upgrade, but until I do, I am stuck. Consequently, I am operating Scrivener in a maximised state. Now, when things are like this, opening a drawer invokes some fancy animation routine to resize the window, and then extrudes the drawer from the side of the application. This has a jarring effect, on me at any rate, and is slow on older systems. The alternative is a realizable pane, which when hidden appears simply as a line with a dot in it, like the Table.

Another problem with all of this resizing is that Apple has a problem with pushing the app into the Dock if you store the Dock on the sides of the screen. Also, intereface elements in the main part of the application shift about when this happens. One place where this is annoying is if you just want to glance quickly at the contents of the drawer. If it were a pane which opened below the toolbar, I could click the button, and then re-click it nearly immediately. With the re-size the drawer button actually moves away from the mouse pointer, slowing down the process of closing it.

There are perhaps fewer issues with drawers on a large screen, but I still feel they are a UI problem all by themselves. Bits of the application which are thematically tied to the main window should not just randomly extend outside the border of the application. What if you have a reference document open beside Scrivener, only a few pixels away? Opening a drawn obscures the reference material. They take up more screen space. Sure, you do get to take advantage of the full height of the application, but the application window has now effectively increased its width by a large amount. It is more unweildy, and if you have already resized it to fit in with your workflow, it is now outside of the bounds of your workflow. Do you resize to accomodate the drawer, or just live with it until you are done with it. What if you always need a drawer open, they tend to appear and disappear between application uses at seemingly random points. These are just a few issues.

What are your thoughts on converting drawers, especially in Composer, to this model?

[KB]

I knew there would be users who didn't appreciate the drawers. However, I thought long and hard about this, and my opinion is this: drawers are a much-maligned feature of Mac OS X, mainly because they are often used for things they shouldn't be - essential components of the app, for instance. Mail.app was a good example of this - having the inbox list in a drawer was silly, because it generally meant that you had the drawer open all the time. Apple rethought this for Tiger. However, I think drawers are great for interface elements that you don't need all the time. I think I've got this right in Scrivener. The only times you have a drawer is in Compose mode and in separate editors. In these modes the focus is on editing your text rather than on making notes or outlining - but the notes and synopsis are there whenever you want them. I think a pane is wrong in this situation because it actually takes up *more* room when you don't want it. Moreover, from an implementation perspective split panes are problematic. If you let them get too small, for instance, the views inside it can get screwed up.

What I like is that separate editors just look like TextEdit - familiar and friendly - when the drawer isn't open. If it had a split pane it would be indistinguishable from the binder view - and you may as well just stick to binder view.

And actually, I had small screens partly in mind when I came up with this. Scrivener was developed for the main part on a 12" iBook, so screen space is at a premium for me, too.

So I'm sorry to say that the drawers will stay.
Thanks,
KB

[amberv]

I tentatively agree with you on whether or not they are appropriate for seldom used data. What I definitely agree with is that they should never be used for data you always need, like good old Mail used to be. That was hideous. Another example of bad usage, in my opinion, was MacJournal. I never liked how that app seemed to have wings. Perhaps I navigated more than the average user, but I never closed them, and I thought it just looked silly with wings. Anyway. Returning to the beginning of the paragraph, I do think -- in certain situations -- drawers can be all right.

So.

I think the source of our disagreement is in the importance of the notes. I will agree that the Synopsis Card is something you would not want frequent access to when writing. You might set it up initially, and revise it a few times during the course of writing a section, but frequent referencing and changing of it is not likely.

However! Notes are much more important to my work-flow. I use them to hold snippets of prose which popped into my head, and haven't been integrated with the narrative, for example. It works as a scratch board for me, when I'm writing. Plus, when doing full re-writes, I like to paste the entire first draft into the notes. Now, that is a Ulysses work-flow, I will admit that freely. With Scrivener's multi-document split, it is very likely that I will not need to use notes when re-writing. I haven't decided yet. One of the reasons why I put it into the notes section is so that I could mark-up the text with editing thoughts, without having to worry about damaging the original (I am a bit of an archival nut). So, I could duplicate a document and use a temporary working copy, I suppose. We'll see.

There are still plenty of ways I use notes on such a frequent basis, that I am relatively sure that if I use Composer mode a lot for writing -- that drawer is going to be constantly open -- putting it in league with Necessary Data models.

So, with it always open on a small screen, when you change modes, that means Scrivener is always jumping about -- ducking behind the Dock -- et cetera. I could just go into Composer, open the drawer, tap the Zoom button and thus freeze the base application window size, but that means roughly 210 wasted pixels (by default drawer width on my setup), in all other views -- really wasted in some views, like StoryBoard.

A point about pixel waste with panes. Yes, a closed pane does consume 16 or so pixels when closed. It also does cause content problems when shrunk to a small size (though I am not sure how that is a problem specific to panes, as you can make a drawer really tiny, too, and cause these same exact format problems). But, big but, if you are composing and you do not need notes or anything, and you just want to write -- isn't that what full screen is for?

For some reason, I do not have a problem with a drawer in the TextEdit style window. Perhaps because it is smaller, and even on my itty screen, it does not toss the window all over the place. I don't know. Perhaps the philosophy of having a separate window open is different, too. I feel as if I just need to be editing text, and not doing full composition? Whatever the case, I have less of an issue with it.

I do think that in Composer mode, notes are of sufficient important to put it into the "necessary data" realm.

This is the last I will rant about drawers, promise.

[KB]

I do see your point, but another problem here is that if there are panes in Compose view, then it would make no sense to have only one pane on the right - rather, you should have a pane for each document. This would be *very* easy to implement, but would look a mess. Two index cards and two sets of notes would be visible all in one screen, so we would actually have less space. By having a drawer, I think it makes it more obvious that this is supporting material for the selected document.

I will consider your idea, and think about it seriously, but no promises.

In the meantime, you bring up another issue which is more easily fixed: you are right, when opening the drawer, it should not cover the dock. This was an oversight on my part - I was using the whole screen width rather than the visible screen width (which takes account of the dock) in my resizing calculations. I have just fixed it, so in the next beta, when you open the drawer, it won't slide behind your dock.

Thanks,
Keith

[amberv]

I see your point about the way it would act once splits are in use. I suppose, in my head, I was just imagining the pane as extending from just below the view buttons, all the way down to the status bar, as it does in Binder view, and then reproducing the functionality of the drawer: Only showing data from the focussed document, and not the reference document. I am not sure I like the way multiple note panes would look, either. That would be awfully messy, and unnecessary in my opinion.

I just realised why I have less of a problem with it in the separate window: Because, in the main view, you have already established a pane model in Binder, and suddenly in Compose that model is discarded and a drawer is used. Thus, the main application window lacks consistency in the functional presentation identical information. This is less of a problem in Draft and StoryBoard, because their editing function is so radically different from the rest. Binder and Composer, however, are extremely similar in basic layout and function.

Glad to hear the Dock conflict is something you can fix, and not an Apple problem. I guess most developers do not know of that trick, because I've seen it happen plenty of times. Just figured it was an Apple bug.

[KB]

That's another reason hate drawers - they are often sloppily implemented. I hate it when I open a drawer and find that it slides off the screen because the developer hasn't bothered with any resizing code... At any rates, like I say, I will consider the compose view thing. Maybe you could start a poll? You should see the fixed drawer resizing code soon, as I'm hoping to release a very slightly updated beta tonight or tomorrow, as I've just fixed the index card/drawer editing bug that was crashing the app, and want to get that out ASAP.

[amberv]

admin said:

I have just fixed it, so in the next beta, when you open the drawer, it won't slide behind your dock.

The application still ducks under the Dock for me. It now re-sizes to allow for the width of the Dock on the left, but moves under it, leaving a blank space the size of the dock on the right of the application. So it would work if the Dock is on the right, which is where, I'm guessing, you keep yours.

[KB]

D'oh! Thanks - and sorry about that. I tested it at the right and at the bottom, but not at the left. The problem is that my code checks the width of the visible area, but then makes the assumption that the visible area always starts right at the left. I will fix this for the next beta.
Thanks,
Keith