1. Start Page
I had to open AS to remind myself what’s on the start page, because I never use it.
I see some utility in the contents of Recent, but not on the Start Page. I’d rather see Recent being fairly comprehensive and living on the Project toolbar, perhaps in the group containing Document | Fragments | Research | Find | Recent.
The Get Started links are perhaps useful for the first few sessions, after which I think most users will know how to find them. All three links would be “expected” on the Help About panel, or the Help submenu. Hey! They are already there! Except the Blog link, which could be added (and it contains some good reading material).
The Actions section, again, seems redundant, but could be part of the help toolbar, perhaps a dropdown of a dozen “common tasks” that would help newbies, and might also highlight those less-often used facilities or operations one tends to forget.
For me, having the Start Page force itself into the tab bar is definitely more annoying than helpful.
Bookmarks, Images, Notes
Your second question is especially interesting in light of the overall GUI strategy. One problem I’ve always had with Scrivener is their use of the word “Document” to refer to what amounts to any chunk of text (any node on the tree). That prevents us from using that word in its ultra-common meaning — the Thing I have just opened and am working on.
In AS we learn to call this Thing a Project (which at least doesn’t contradict decades of computer usage), and the topmost nodes Chapters, all of which I find much easier to do. But the underlying GUI strategy is that the app is defining what all these elemental things are, while at the same time encouraging users to freely re-define their purpose in a given document (Project). To me, that’s a contradiction, and I think it adds confusion for users until they get used to the idea that the nomenclature isn’t meant to be taken seriously. But maybe it’s unavoidable, because the purpose of each node element may change significantly from Project to Project.
I should have been able to say that more simply . . . .
The tradeoff seems to be flexibility vs guidance. And I readily acknowledge that the field of writing hasn’t spawned much terminology for referring to the parts of a manuscript. I was surprised, back in the 90’s, when the excellent editor Lotus Manuscript offered a paradigm where a “paragraph” was called a “block,” and it became apparent that every document could be designed as a hierarchy of blocks – some contained sentences, and others contained headings. Using this model, one could build any common document structure without any other kind of element: a hierarchy of heading + content blocks (with optional Graphics blocks wherever a text block might go). Modern graphical text apps now use essentially the same kind of thing – text blocks (and often graphic blocks). in InDesign, for example, calling a paragraph Style a “heading” is just the user’s preference. Structurally a heading is no different from a paragraph.
So this “orthogonal” thinking leads to the observation that pre-defining structural elements may not be all that helpful. (Of course, suggesting initial uses for elements may be very helpful.)
So I suspect that removing restrictions on the three trees is usually going to be a better approach. Let me decide how I’m going to use each tree. Offer a suggested function for each tree (Document, Fragments, Research), but allow me to use them any way I like. Allowing me to add a Scene to the Fragments and Research trees, but not allowing me to add an Image or a Link to the Document tree, seems arbitrary. (Although I imagine some additional export settings will be required.) Besides, users always come up with clever ways of using an app that the developer never thought of. (At least that was my experience as a developer.)
And speaking of export – why not let us treat any tree as the source of an export? If they all contain all the same types of elements, then we could end up with the bulk of some project in Fragments or Research – so why not export that, “as if” it were the Document? One might actually need to export the Research…
However, this putative principle of orthogonality can get confusing. Why not let me insert anything into anything? Put a folder into a Scene? Put references and links into a Note? In fact, now I am confused.
So there do need to be limits. If I had more time, I’d try to offer an overall set of elements, defining what could be useful within other elements, but fortunately that’s what you’re doing, o esteemed developer!
So yes, I would definitely like to be able to add links and figures to a Scene or anywhere in the Document tree. And, as Mike reiterated, I would sorely like to have bookmarks that point to Scenes (or, in fact, to any element in AS). For now, just these two expansions would be extremely useful, and probably wouldn’t add enough complexity to confound the newbies.
And thanks for asking. That’s one thing that really sets AS apart.