A greater functional difference between folders and document

I know you’ve said before that the difference between folders and documents is supposed to be largely aesthetic—or at least for the user to use them however he pleases—but I will confess that my deeply-learned expectations for interface design trip that particular intention up, right out of the gate.

That is: The fact that folders are simply documents with blue icons is 1) confusing as hell, and 2) a waste of functionality. I could imagine, after all, why someone would want to have a document which is also capable of hierarchy (though myself, I am not one of those people)—but there is also value in hierarchy itself. The expectations of hierarchy are very deep-set in a computer user’s experience.

An example: if I want to commit a bulk Convert Format to Default command (something I find myself doing rather often, due to frustrations detailed elsewhere), I click on my ‘Vintras’ folder and select the menu item. This does not work, of course. It does not work because Vintras isn’t actually a folder, in the sense most users understand it: it is not a container or superior concept which possess children. It is (not to sound disdainful) a document with a blue icon. It is capable of containing text, and thus it can’t do anything useful in terms of acting on its children.

But we already have something that can do that—our stack-of-papers document—so presumably, it would be much more useful if we had something that acted as an actual folder. When I click on this actual folder, for instance, instead of a blank and confusing white in the main text area, I might see a listing of what’s in it, with more detail than the Binder, like, say, in DevonTHINK:
It might not even be clickable, to begin with. Just the fact that the interface understands that it is depicting a hierarchy to the user would be infinitely reassuring. I understand that you’d like to keep Edit Scrivenings in its own mode, elsewhere, so it’s not necessary to flow any arbitrary group of scrivenings together depending on the scope we’re looking at. But about a thousand times a day (slight exaggeration) I find myself expecting Scrivener to respect the hierarchies it depicts.

For instance: tags. You’ve said you don’t see any value in having bulk/parent tags, so for instance if I had a tag called ‘Pirates’ and it contained {Bluebeard, One-Eyed Pete, DVD Jon}, that clicking on ‘Pirates’ would show me everything that contained its three children. I won’t argue the point, though I disagree, mostly because I haven’t found tags very useful in their current implementation, anyway. But you must concede that that expectation is exactly what you are creating by allowing the user to create a hierarchy of tags! If you’re not interested in mirroring the appearance on the backend, at least, I beg you, choose a different metaphor. If the only use of tag hierarchy is aesthetic, then maybe, I dunno: code folding.

As I said, there are quite a few places here where 1) My computer-using brain is tricked into believing that it is acting on an n+1 level of file hierarchy, and where 2) I think that functionality (ie, essentially, folders being actual, non-text-document folders) would be very beneficial, at a very low ‘cost’ (‘cost’ being defined in terms of interface clutter, bloat, and user assimilation rather than coding effort, of course). Let me know if you’re interested.

DevonTHINK looks similar to Scrivener. I hadn’t seen it before.

My opinions on this issue, and I am very opinionated – apologies if I get under your skin, I mean only to discuss.

Personally, I am loving the way it works. Right, I had to establish a way of using the system to best benefit the book, but once I got a system going it works great. I consider the different icon styles as a form of meta-data. When I see a group icon, I know that means it is a container of documents not meant to be combined – a collection of chapters would be a good example. Whereas a document stack icon would be a document that has sub-sections, but is meant to be viewed as a single document – and that is where Edit Scrivenings comes in handy. I know from a glance that a group icon document is not going to be exported in the Draft, and that it is safe to add whatever section related notes I wish, into the text editor. It is a place to keep large scale notes, and without that place, there would no readily convenient area to do so. I would have to create a document expressly for notes, and store that underneath the group with the export flag turned off. That is what I had to do in SG, and I didn’t like it.

But, to say that groups are just blue icon documents is not precisely true, especially in the export phase. The exporter allows distinction between the two types, and options for exporting various types of data. Here you can export group text if you wish, but if you use an information model similar to the one described above, you probably would not want that, preferring only the title get placed in to the draft.

Regarding the notion that actions enacted upon a group should cascade to its children: I guess I simply do not think that way. I never once thought to select a parent and expect format to default to work on everything below it. If anything that philosophy, would apply to the document stack, where a document stack really does represent a document that has been split up with an established hierarchy of sections. Telling the top-level document to go to default would make sense to cascade to the children, which are only parts of the document stack. A group more represents a collection of documents, which may or may not have their own formatting requirements. But, that said, I would still argue against that ability, as it conflicts with the actual terminology. Technically, I have only selected one document (document stack or no), not the document and everything below it. To each their own, I guess. :slight_smile:

The primary thing is to separate the notion of “Folders and Files,” as is the Finder metaphor, and to see it more as “Groups and Documents,” a writing metaphor. Having sub-documents in Finder is confusing enough that Apple has essentially hidden this ability behind the Bundle concept. A single thing posing as a file, but actually containing many functional sub-file parts. In a file management setting, it would be too confusing to have this as easily accessible as Folders and their contents (even though technically that is all that is going on). In a writing context, however, is it all that confusing once you divorce from it the Finder/DEVONThink way of conceptualising hierarchy? A real file folder is not an abstract container which takes up no space – as it is in Finder – it is a physical paper object that, along with holding sheets of paper, can be written on itself – and I do this frequently. So it does not at all feel weird to write a paragraph or ten “on the cover” of a document group in Scrivener.

What we have not addressed yet at all is what this ability provides for you during the planning phases of the book. It turns Scrivener into something more like OmniOutliner than DEVONThink. You can rapidly move ideas around, place them above or under other ideas – all without the cerebral overhead of having to decide what type of object this thought parcel should be. All parts are equal until the hierarchy settles down and then they assume the roles they have settled in. Then you can rapidly convert what once was a single scene five hours ago, into the chapter group it has become. This type of flexibility is a royal pain in something like DEVONThink. What if I had already written part of that scene in a burst of inspiration, but now I need it to be a “Folder?” I have to somehow convert this information node into a “Folder”, transfer the internal data somewhere transient until the contents get fleshed out, and only then can I proceed. It totally breaks up the flow of thought. With Scrivener I can do this in a flash and even keep on writing narrative in the other split.

I guess, in the end, Scrivener allows (for the most part) many different design and work philosophies to co-exist. If you are the strict segregationist type, you can keep Groups devoid of content. If you are the fluid ThisMightBeASceneSomeDay type, no problem just store your scene ideas/narrative right in the text field. The place where it falters are the areas you pointed out, but if these areas were made into a strong distinction, you would cut right into the fluidity side of Scrivener. Forcing a Corkboard/Outliner view and stripping the text field from groups would put a huge crutch in that design ethic. Besides, I just don’t find <click;Cmd-2> all that difficult of a manoeuvre to view my group as a container of documents. Why force a behaviour when it is that simple to access?


Well, I’m sorry that Scrivener doesn’t quite work for you in some ways, but - obvioulsy :slight_smile: - I don’t agree. The way folders and documents would worked was discussed with users to quite an extent back when I was redesigning Scrivener, and I am really happy with the current solution.

This is exactly how this is designed. On thing that I see as being very important (and that several users also felt was important and lacking in SG) is that you should not have to decide whether a document is actually a document or a folder when you create it. You may, for instance, sketch out several chapters in text files, and then decide that some of them would be better suited as folders with the actual text contained as subdocuments. (Note that when creating a folder, it is set not to be exported by default, whereas text is exported by default - this can be changed on a per-document level, though.)

Also, note that as of beta 3, the default behaviour will be slightly different - you will not be confronted by blank corkboards or text or such, although you can choose the old default behaviour of betas 1 & 2 should you want. And, via preferences, you can decide whether document groups should act the same as blue groups (by default, they will have different behaviour). Anyway, I don’t really want to go in to this too much, as I would rather wait until beta 3 comes out as it will make more sense then.

Well, for a start, I never said that I didn’t see any value in this, I merely said that it wouldn’t be happening any time soon - not for 1.0. I quite like this idea (which I believe AmberV also suggested), but it will be more of a 2.0 thing. I cannot implement every single user suggestion right now, no matter how good they may be. That said, I don’t agree that I am creating this expectation at all. Maybe, if you have used Aperture, you might expect this, but this is a different program. You need a way to organise keywords hierarchically, and this is what you are allowed to do.

To most of this, though, I hope that beta 3 will provide a compromise that will work for most users (though, of course, it won’t be DevonTHINK :slight_smile: ).

As for everything else, I think AmberV has said it all a lot more elegantly than I can (again). :slight_smile:

All the best,