Interaction between Binder, Corkboard, and Outliner

There are a few situations in the current UI that feel just a bit awkward, in my opinion. First I’ll address the consistency of double-clicking. In the Corkboard, and most of the Mac world, double-clicking on an icon either opens the item it represents, or toggles the state of its function in whatever list it currently inhabits (such as a checkbox). For example, double-clicking an icon in Finder opens the represented item in the default application (Finder, in the case of folders). In many outliners, double clicking a folder icon will collapse or un-collapse a container, revealing its children. In the Corkboard, it descends into the selected container and displays its contents.

This appears to be the only case where this method works. In the Binder, double-clicking prepares the rename function. I can see double-clicking the text doing that, but the icon should un/collapse, or simply open a document. While it does open a document, it appears to be an artefact from the first click, and the second click enables rename.

In the Outliner, double-clicking does nothing. Again, un/collapse on groups/documents with contents, and at the least, silently selecting a chosen document in the background, so that when Outliner is closed, that document is now open underneath it.

Likewise with Corkboard.

Next comes a second issue that feels awkward to me. The interaction between the Corkboard, Outliner, and the rest of the application feels like there is little integration beyond sorting and setting meta-data. Here are a few paths of action and their results; the way they are, and the way I expect them to work as a user of other applications.

  1. I open Corkboard or Outliner at the Draft level, double-click on a group, double-click on a document, and the Corkboard goes away with the pane now displaying the selected document. The way it works now – nothing happens.

  2. Using Binder to navigate with the Corkboard or Outliner open, I select a document. The pane displays the document’s current context, i.e. the same thing it would display if you had clicked on the document’s parent. Why is this important? With an un-collapsed area in the Binder view, the list of documents offers a much larger target for the mouse than the parent container, and conceptually both actions have the same intention (in my mind at any rate). The way it works now – Corkboard and Outliner display a completely empty screen. This is kind of confusing, and leaves the user with seemingly nowhere to go. Now, I understand that this is a way to enter new documents beneath the document you just selected, and you very likely made it work this way intentionally, but I do not think that will be happening as often as wanting to see a document in the context of its peers. Of course, if you select a container, it would still display its children This is something that would only happen if you selected an document that had no contents. As for selecting an empty group – well that could go either way in my opinion, because that would be a more natural “now I am going to enter some new children” action.

  3. In either Corkboard or Outliner, I drill down to a document and simply select it (no double-clicking). I press the shortcut to put away the respective mode, and find that my current selection is dismissed in favour of whatever document/group was selected before starting the navigation process in C/O. Now, I understand that neither are for navigation, however they feel as if that is precisely what you are doing. This is part of the lack of integration I mentioned. Should movement in either view change the Binder selection? No, for the same reason that using the Forward/Back buttons in document view does not.

  4. In either C. or O. I have “Part 4:…” selected in the Tutorial. With Part 1 uncollapsed in the Binder, I drag “Step 3” into the current view to add it to Part 4. This works perfectly, but I decide I’d rather leave Part 3 back in its proper section, so I drag it back to where it came from. The screen remains with Part 4 selected. The way it works – the screen suddenly goes blank! Why? Step 3 is now selected in the Binder post-drag. This is jarring, and probably not the behaviour anyone would want. If problem (2) were resolved to display context, it would be a bit better, but I still think the selection should remain in Part 4.

  5. With either C. or O. open, I click on the background of the Binder to select the top level of the project. The screen now displays the top level documents, groups, and draft. The way it works now – the last selection remains visible, even though it is no longer actually selected in the Binder. This is a behavioural contradiction with the non-navigation stance exhibited in (3), where the Binder selection is respected over the Corkboard/Outliner selection.

  6. This one is a bit more preferential than the others. If I select multiple items in the Binder, and invoke C. or O. the screen displays the last selection. Fine, this is the way the document screen works, too. But if I choose to Edit Scrivenings [ED], and then invoke C./O. the selection is still on the last document. It would be über-nice if this created an ad hoc display of those selected documents, much like the Table did in SG. Leaving either mode and returning to document display would retain the ED state that you left it in. Currently, it becomes disbanded. This could be taken a step further so that any multiple selection in Binder shows an ad hoc view, precisely as Table did. This would be very useful for searches where you wish to quickly review meta-data for a number of returned results. Currently, there is no good way to do that. This represents a fairly large functionality hole between SG and S1. In SG, I could search for RWRI, open the Table, and make sure all of those documents at the “Rewrite” status set correctly.

Ugh… I can’t really handle this right now, and am going to bed, but here are some initial thoughts, beyond “it’s an imperfect world”:

The whole double-clicking thing. I just don’t think it’s a big deal. It’s something you get used to. Even Apple apps don’t behave with perfect consistency. Sorry.

Do you mean that when you double-click on a document icon in an index card in the corboard view, you think it should not only open the document but also toggle to the document view rather than continue to show the corkboard? But what if the document has contents? Should it act differently then? Anything can have children, now, remember… I could see that maybe working for the corkboard, but for the outline view, too? Hmm… Maybe. Dunno.
2) Using Binder to navigate with the Corkboard or Outliner open, I select a document. The pane displays the document’s current context, i.e. the same thing it would display if you had clicked on the document’s parent.
Maybe I’m just tired, but I’m finding these hard to follow. I think your expectations come first and what actually happens comes after. If that is the case, you think that when you click on a document in the binder, the corkboard or outliner should just show its parent’s contents? What other app acts like that? Not Mori, that’s for sure; not Xcode… None that I can think of. And if it behaved like that, suddenly the corkboard and outliner are no longer in sync with the underlying document. The whole idea is that the corkboard, outliner and document view are all just different views on the same document. True, the outliner and corkboard views have no meaning for documents without any children. But you can assign children to any document, so they are there should you decide to do so.

Again, this means big conceptual changes in the design of Scrivener. The corkboard and outliner are organisational tools. They are not for selecting documents. Personally, I would be more confused if the selected document suddenly became the main document when I switched out of one of these views. Suddenly the distinction between folders and documents becomes bigger, and the learning curve is actually steeper, I think… Again, I ask you to think of the corkboard and outliner as ways of looking at an organisting a given item’s contents. If it doesn’t have any, you don’t need to use them for that document.

Wow. You really do hate clicking, don’t you? :slight_smile: This is standard behavour in every Cocoa app; if you drag an item into a view, it gets selected in that view.

You cannot view top-level items in the corkboard or outlner. That limitation is intentional. I don’t see why you would ever need to. There are some good conceptual and technical reasons for this limitation, but right now my brain is scrambled and I’ll have to get back to you on that one.

I seriously considerd this, but decided against it. The reason being that things get very tricky - suddenly you have to disallow drops in the corkboard or outliner (because the contents are ad hoc and dropping would have no meaning), which would be confusing. Dunno. You have a point about the meta-data thing.

No software is going to work for everyone; and no software aimed at helping with the writing process is going to fit into the way everyone writes. There’s not much I can do about that. Right. I’m off to bed now.

Got to respect AmberV’s rigour. Follow the logic and it makes sense. I just think it all seems OK for now, pretty much as it is. I humbly had a go at this and most of the issues were resolved - for me, by using vertical split just setting up two adjacent documents.

I put RESEARCH on the left pane and my working text as DRAFT in the right pane.

I then switched the left pane stuff in and out of OUTLINE and CORKBOARD.

This seemed to enable the editing process in my DRAFT, which was visible all the time in the right pane.

This worked for me. It may not for you.

  1. Yes, that is what would make sense to me. You double-click on a document, it opens. If it is a group-based document it (opens) shows the children in Corkboard. The only time it would open a document and actually switch the pane is if it is something without contents beneath it. I meant to express that, but I must have forgotten to clarify. The “feeling” that something should open is stronger for me in Corkboard than Outliner, that is true.

  2. The empty viewing pane situation is actually something that I find awkward with Mori, too. Awkward enough that I’ve stopped using it much anymore. I think with Scrivener it would not be so much of an issue, it is a much more minor aspect of the application. With Mori, that is a fundamental aspect of it, and if you don’t “get” it, the whole thing is just a novelty. You ask what other applications act this way, but honestly there are not many applications that have a corkboard-like function out there. One app that acts this way is Mindola’s SuperNotecard, which is essentially one big corkboard application. I never much cared for the application for other reasons, but I do think it got navigating through card sets down pretty good. There are no “groups”, but it does have “stacks of cards” which is pretty much the same thing. Double-clicking a stack descends into it, showing its children. Double-clicking a regular card replaces the current view with the card editor. The back button goes back to the last viewed card set. When using the Explorer feature (Binder), contexts of the selected card are always shown. An empty screen with no cards is never shown (except, maybe the first time you start a new project). (But yes, a “stack of cards” look might be nice in the Corkboard view to make it very obvious which cards have contents beneath them)

Perhaps I am just too tempted to navigate around in Outliner/Corkboard. They feel more like different views of the project to me, rather than the document. Maybe I am just weird on that score. I will make an effort to use them entirely as document level aids, not project tools.

  1. I do not understand your rebuttal – how it defeats the folder/document division. But I do see further how they are not intended to be project organiser/navigators. Perhaps (3) would be a bit strong. While double-click opening a document makes all kinds of sense to me, this would is a bit vague, and you are right, if you use it the way it is intended to be used, it would be awfully confusing – so forget this. :slight_smile:

  2. Actually, the model I was most thinking of is Finder, which isn’t Cocoa I understand, but this type of action of moving bits of your work around in a tree feels like Finder to me. When you drag an item from one window into another, the dragged item is not selected, actually – but the context (parent) is, via the target window.

  3. All right, I see your point on this one.

  4. True with having to disable drops. With Corkboard this whole bit doesn’t make as much sense, but I think it really does with Outliner. Hmm. Perhaps some visual distinction could help here. Maybe the normal Outliner shows the “root” item, the selected document, at the top. This is similar behaviour to any outliner with “hoisting.” An ad hoc Outliner would, of course, not have a root element, and would just be a straight list of results. Attempted drops would just be ignored. But on this score, does revealing the “contents” of an ED view make any sense at all anyway under the current setup (without an ad hoc arrangment, that is)? Perhaps access to them should just be disabled – as all they do right now is disband your ED selection. Just a thought.

Well, out of all of these, I think six is the most important because of the meta-data thing. I just might be off my rocker with the others. You are right, nothing works for everyone. Fortunately these are just very minor interface “oddities” on top of an extremely solid application. I have a few quibbles here and there, perhaps the biggest thing being the meta-data, and some exporter problems, but other than that there is nothing else out there that even comes close to what you’ve got done here. Sorry if I came across as negative on the project as a whole! This whole list was just some things that I figured would be relatively easy to tweak, and would help reduce how many times a blank Corkboard or Outliner shows up.

This is pretty much the same setup that I’ve been gravitating towards as well. Essentially, I am replicating to a degree what SG had. I leave the horizontal split open, and the Outliner view in the top, precisely where the Table sat. The only difference is that it is not quite as flexible as the Table in some regards, and definately more interesting in other areas.

We’ll see. This is the kind of thing that takes time to accustom oneself to.

AmberV comments on both Mori and other corkboard apps.

We think alike. I used AppZapper on Mori, Jer, WriteRoom, CopyWrite and myNotes yesterday, after KB released this beta 1 version of Scrivener. I don’t need them anymore. I kept Journler and the very beautiful MacJournal. I have a much cleaner system now and Scrivener has jumped to the front of the cue for day to day writing. I actually found myself dreaming story material as it typed itself in Scrivener. How is that for an application seeping into the ample spaces in my brain? Both brain cells were fully engaged.

A great use of the corkboard idea (multiple linear corkboards) is in Storylines.

It’s the writing part of Writer’s Cafe (which is the Research and chunking part of the twin application).

I yearn for a later release of Scrivener that allows BOTH corkboard spread like the current one, where you can index card your document any way you like, by just clicking on the little + set of icons at the bottom of the screen - and a linear adaptation of that so you can run plot-lines, as in Storylines.

This idea is probably best seen in PowerStructure Pro (Index Cards) for the Mac:

However, that said, I am still more impressed with Scrivener’s card/corkboad system than I ever hoped to be. I keep saying to myself, let KB get this one out just making sure all the functions that are there now work without bugs and leave the aspirational stuff for when he recovers some of his costs and can see the market demand over a few months.

AmberV - sorry if I was a little snappy and defensive in my reply last night. It came at the end of a very long day of trying to track down bugs and reply to a gazillion e-mails, and my morale was low by that point. :slight_smile:

I’ll just address Lord Lightning’s last point before returning to the points you made:

Storylines. I am aware of it - a lot of people have mentioned it. In fact, I have it on my hard drive. I don’t use it, but I looked at it when re-implementing Scrivener. I like it, and I have a good idea of how I could create a similar view in Cocoa (although it would be a lot of work - the Corkboard view alone is over 2000 lines of code, as it has to do most of what Cocoa’s NSTableView does but in a completely different way…). However, I have - for now - ruled it out of being something I would incorporate into Scrivener. Reason being, it just wouldn’t fit into the way Scrivener structures things. Think about the following situation:

In Corkboard, you can assign a different label to each index card. You can drag the index cards around howsoever you wish. Now think about how that would translate to a Storylines-style view. Presumably, you would want each label on a different row with the cards that are associated with each label sitting horizontally, so that you might have a row of cards associated with “Dave”, a row associated with the character “Derek” and so on and so forth. Now, in Storylines - and you would expect this behaviour from any program that provided such a view - you can place two (or more) cards so that they are one above the other, to indicate that these events happen at exactly the same time. That is a cool feature, but it has no meaning in Scrivener: two cards cannot exist in exactly the same place. How would Scrivener know which card to place first internally, and which one to show first in, say, the outliner or binder views? “Ah,” you say, “Well, actually, Storylines does this already.” True, Storylines has a very basic, quasi-outliner above the storyboarding view. And, quite naturally, the item displayed first in the list is the one whose label appears first in the label list. So, in this event, Scrivener could choose to place the the item with the first label above the other item. But now, what about when the view is next displayed? How does Scrivener know whether the two items were placed at the same time or adjacently? And what about if you change the order of the labels? Scrivener would have to go through ever single item in your project and try to decided whether or not it needs reordering. And what if you switch back to normal corkboard mode and start dragging your documents around. You would never know where things would end up when you switched back to storylines view. The core difference here is that Scrivener just holds lists of items inside each group. Lists are one-dimensional. Storylines requires two dimensions. It can show that in the list at the top because it doesn’t have to worry about interacting with a greater outline or anything else. It is a dedicated program. In short, I am afraid to say, in Scrivener you will just have to make do with the coloured pins. :slight_smile:

Right, onto AmberV’s suggestions:

  1. On reflection, this idea isn’t so bad; in fact, it does make sense. The problem is that both approaches make equal sense, I think. The issue is really that there is no other application that tries to do quite the same thing, so there is really no precedent. In which case, I think I will make it a preference, so that users can decide for themselves. I won’t know which I prefer myself until I really get to work with the program on my own project.

  2. I’m still not convinced about this one. It basically means that either: a) clicking on a document with no children in the binder does nothing when the outliner or corkboard has focus, so that the parent retains focus; or b) clicking on a document switches to document mode, which then has to switch back to outliner or corkboard mode when a group is selected. Either is more awkward than the current solution. I think corkboard and outliner modes should be used for focussed work: you know you want to do some work on that particular part of the outline, so you select it in the binder and switch to that view. Navigation in the binder will generally be done when you are in document view mode, unless you want to see what is inside all of your items… So I’m holding out on this one, I’m afraid. Sorry to hear you gave up Mori because of this - Mori is a lovely app.

  3. Phew!

  4. I thought about this again when I woke up again and decided that, on reflection, I actually agree with you. I thought about what I would be using corkboard for. One of the main things I am going to use it for is to try to organise my project whilst looking at synopses of documents. In that case, I will want to select a group, look at the contents in the corkboard and then be able to drag things in and out without the corkboard suddenly switching to another document. So you are right; I will change this.

  5. And I didn’t even make a good one. :slight_smile:

  6. This is something I need to think about. Perhaps your original idea, that it should work alongside Edit Scrivenings, is the way to go. I don’t know. The meta-data situation in the case of a search was certainly an oversight; leave it with me.

No need to apologise. Like I say, I was just a little cranky last night as I realised how much work I had still got to do. :slight_smile: Your input is greatly valued; it has already helped improve Scrivener greatly, and I do very much appreciate the fact that you care enough about the program to take the time to post such eloquent and thoughtful explanations of your ideas.


Oh, how I love a good debate. Okay:

  1. There is another option, © clicking on a document with no children in the Binder highlights that card in the Corkboard. This way, you retain that document centric quality. You are editing Step 12, press Cmd-2, and Step 12 is highlighted in the Corkboard with its siblings. There is no reason to show Step 12’s content-less board, really. You are probably most interested in seeing how Step 12 fits in with the pieces around it. Here is the thing that would really make it work: New shortcut, DownArrow, descends into a contentless card. So, if you really do want to add things beneath it, it is a simple keystroke away. I do not see how this does anything but enhance the focussed organisational properties of the Corkboard. In point 4 you stated that one of the primary uses is to organise a project with a simple, visual representation of synopsis. It is beautiful, and I don’t see how eschewing context in favour of a blank Corkboard does anything to forward that primary intention.

It is indeed a shame with Mori. I really like the application, and I really like and respect what Hog Bay is doing for community centric development. There are a lot of things to really like, but navigation woes really killed it for me. It never does what I feel it should be doing, even after having spent a lot of time in it. I just never clicked for me. Same thing happened with DevonThink. I never “got” that application either. I prefer Boswell’s philosophy by a long shot. Anyway…

  1. Well, a technical “no” is all I need to hear. Conceptually, I still disagree. Primarily because it breaks the Corkboard-follows-Binder-to-the-ends-of-the-earth behaviour exhibited everywhere else. But it is one of those things that you get confused on the first time it happens; then you realise it simply doesn’t work, and you stop trying it.

Okay, glad I’m not on your hate list or anything. :wink: And you’ve got me pegged, I probably come across as extremely critical at first blush because I dispense reams of faults, but it is seriously because I dig the app. I spent nearly the entire yesterday testing the app because I believe in it like few other apps out there. Not only that, I believe in your skills and vision. And honestly I simply just haven’t had the time to gush yet but believe me I’ve got gushes. I’m saving up a bit of that for MacUpdate/VersionTracker when the day arrives.

Now this I like. I need a clear few hours to reorganise the code to get it working, but it’s not massive work. Essentially, it would make a clearer distinction between folders and documents, too:

  • With folders (including the root folders), even empty ones, clicking on the corkboard or outliner would show their contents.
  • For documents, clicking on the corkboard or outliner would show that item selected in its parent folder.

Does that sound intuitive? It means they would work in opposite directions… And what about documents that have subdocuments? Should they act like folders? That is perhaps the toughest question.

I’ll have a crack at it as soon as I get chance, though there are a few things on the list first.

It is good to know that you like the new version - and I’m certainly not complaining if you want to save the praises for VersionTracker and MacUpdate! :slight_smile:

Huh, another problem just occurred to me: what happens if the user makes a multiple-selection in the binder? Especially one that spans across multiple parents…?

Whether or not document containers show their contents is indeed a tough one. On one hand, they and groups are pretty much the same thing, so they should be treated the same way. On the other hand, if you come to expect items with the document icon to act a certain way, would be it confusing to have it suddenly act another way?

From the Binder, I think it is intuitive. The difference between a node and a parent is very clear. The area where it could get confusing is when pressing Cmd-2 from a document container versus a node, and wondering where its siblings are.

For Outliner, the solution is much easier, I think. With the exception of groups, Outliner would always show context, with the difference being if a document container is selected, it is selected and un-collapsed.

Two arguments:

I) Here is the issue with separation between the to, the way I see it. The way you’ve got it set up is perfect. It allows for fluid outlining and brainstorming without the restriction of deciding what something is before creating it. However, once an item has established itself as being a container or a node, the distinction becomes closer to a dichotomy in the mind of the user. At that point, the fluid aspect is less important, and what it actually is is of greater relevance. A container document is a group at that point, conceptually speaking, and so perhaps it should then be treated as one.

Look at it this way, if you’ve placed documents beneath it, it has probably ceased to be a integral part of its siblings as a solitary unit. The contents of it are now, conceptually, a part of its siblings more than it is, because the sum of their parts create it.

II) Here is a different workflow: Somebody uses documents beneath documents as ancillary or supporting facts, rather than narrative flow. At that point, the container document is more important to the siblings than the parts beneath it. A user of this method will not agree with much of what was said in point (I) after the fluid outlining bit (and perhaps not even some of that).

In either case, there does become a point where fluidity ceases and the outline becomes concrete. The trick is allowing the user to reach that point, and allowing the application to understand that the user has reached that point, in a manner that is completely natural and requires very little thought on the part of the user. We already have one tool to facilitate this: Convert to File/Convert to Group. This, in my mind, is a very clear way for the user to say: Okay, I am done brainstorming, and this is how my narrative structure is.

At that point, I do not believe it is a detriment to the fluid philosophy for the application to express certain functional differences between types. After all, there would be no need for types at all if it did nothing different. So how about that? Group type items always show contents, even if empty. Document type contents, even containers, always show context. And once again, if the desired view is contents (blank or not) it is a simple DownArrow away.

Actually, if you read the first post again, I did address that along with E.S. style invocations. Multiple Binder selections would create an ad hoc session, just as the Table did in SG. In such scenarios, the whole context versus contents issue would be entirely dismissed and only the selected items would be shown. Drops would, of course, have to be disabled at that point.

Should this happen in Corkboard, I think not. In Outliner, it definitely makes a lot of sense, and it would solve the meta-data/search problem. Search, select-all, Cmd-1. It makes no sense with Corkboard, because all that view is for is for analysing data in relation to its neighbours. There are no neighbours in an ad hoc session.

Intuition: Corkboard is disabled in an E.S. session, it simply makes no sense in that context. With multiple Binder selections, Cmd-2 functions as it currently does, with the last selected item being displayed however it should be displayed as per the above discussion.

Actually, I can see a need for this. Suppose you run a search on all documents with a specific label - say where “Label” has been renamed “POV” and you want to search for all documents that have Jack as the the point of view character. When you do, you select all, cmd-2, and now you can see a synopsis of that character’s story so far. If you want to add a document, the corkboard selection will have to switch to the parent of the item after which you are inserting your new item - just as binder does…

This will take some work, mind.

Not sure quite what you mean here. But maybe the corkboard and outliner should be completely disabled during an Edit Scrivenings session.

I mean that, in an E.S. session having the Outliner available would be very handy. You could view the combined documents in two different fashions, as a list, and as a combined draft. You could, as you edited, tick off status/label as you worked, negating the need to keep a laundry list on the side for all of the edits you have made. Plus, synopsis would be visible for all documents in the E.S. draft, another boost.

This is off the wall, and would break with everything established, but what if you could right-click in the Outliner during an E.S. session, and had the option to “Jump to,” which skipped you down to that point in the combined draft. It could then function as a mini-TOC, too. Eh, yeah. :slight_smile:

Okay, I just realised that I answered the wrong question. What I meant was: During E.S. Cmd-2 does nothing, however you say that you would find use for that, so nevermind that part. The second part is that when you have a multiple selection in Binder, where Outliner would reveal these items like Table did, Corkboard would simply function the way it does now: It only shows the last item selected. And by “as per the above discussion” relates to the “context versus contents” discussion, that is all.

Ah… Right, I see what you mean. Okay, I’ll see about all this. :slight_smile:

You know you already have a TOC by clicking on icon in the header view, right? This acts differently depending on whether you are in E.S. or not…

Right, just trying to get all of these ideas down into a few simple lines so that I can start breaking it down into the necessary logic. This is how I see it:

  1. During edit scrivenings, flicking to Corkboard or Outliner shows the selected items and does NOT clear E.S. Drop is disabled, obviously. Adding a new document just adds it to the binder, below the selected document.

  2. When in corkboard or outliner mode: if a GROUP document is selected, its children are displayed; if a DOCUMENT is selected, its parent is shown and the document is selected and thus shown in context.

  3. When toggling OUT of corkboard or outliner: if there is a selection, the first selected document becomes the document displayed; if there is no selection, the parent becomes the document.

  4. When selecting items in the binder: if document view is displayed, then things remain as they are; if the outliner or corkboard are displayed: if an item that has children is selected, it shows its contents just as it does now; if a childless document is displayed, all that happens is that the selection in the outliner or corkboard is changed.

  5. If multiple items are selected in the binder when outliner or corkboard are visible, an ad-hoc list of documents representing the selection is displayed in O or C. Obviously, drop is disabled in this situation, and adding adds to the binder (which will, unavoidably, change the selection).

  6. If multiple items are selected when the document is visible, behaviour is as it is now.

Not sure about the whole down-arrow thing, given that the down-arrow already has meaning in all these views.

No, I had not noticed that yet. Very swank, yet quite hidden. I wonder if a little downward pointing triangle like the one under icons that have options, would be of benefit during E.S.?

  1. Check. Though, as you were describing that, I had an idea: What if you could drag something from the Binder into the E.S.S. Corkboard (That sounds like a naval vessel in some slapstick irony show) and it would be added to the current session, in the position that it was dropped?

  2. Wait, I thought you decided against that, as it would be too confusing?

Everything else looks right.

Re: DownArrow. That’s fine, maybe Ctrl-DownArrow? It is an easy combination to press, at least on the Mac standard keyboard. I don’t know, I just think there should be some way to get into an empty screen if you do want it. Plopping down concept cards on a fresh container is a beautiful way to brainstorm.

That’s certainly a good idea, but I think this is one for a post 1.0 release. Can you wait until after 1.0 and post a suggestion then? Right now I’m just hacking my way through everything that needs to get done; once 1.0 is done, I’ll start compiling a proper list and maybe look into going the Hog Bay route of letting users vote for it. The only thing I don’t like about this suggestion is that suddenly the meaning of dragging to the corkboard changes. Something to be discussed in the future, I think!

I did, given the current set up, but I think this would be necessary. For instance, imagine this situation:

You are viewing a document, hit Corkboard and now the corkboard displays the PARENT of the given document with that document selected.

So you hit Corkboard again without changing anything - but now you are looking at the text of the parent document rather than the original document. That would be even more confusing… So I think this is necessary given the other changes. I think I really need to see how this all works.