Niggles, rants and recommendations

(I posted an earlier version of this on the Google+ Scrivener community. It was suggested I post here as well, for feedback from the developers.)

Let me start by saying that I’ve written three books in Scrivener and I love it. And also, I hate it.

I love it because it gets so much right. The binder gives a great high-level view of your work, the writing area is easy to use without being over-burdened with Word-style formatting fireworks, and compiling to different targets is a godsend.

But sometimes it annoys the biscuits out of me.

I know how hard it is to read criticism without feeling personally slighted. Believe me, this is not my intent with what follows: I want to help make Scrivener better.

Fundamentally I believe it needs attention from a dedicated UX designer: someone who considers the product entirely from the user’s perspective and, crucially, has no coding responsibilities. I realise this is difficult.

The issues I have with Scrivener range from nitpicks to full-on conceptual rants. Here’s a few off the top of my head (all on the Mac, version 2.4), in no particular order:

Confusing icons. The icons for “enter full screen composition mode” and “open QuickReference panels”, two very different actions, are conceptually identical: a box with arrows pointing to top-left and bottom-right corners. Possible alternative for QuickReference: a document icon with a prominent “floating” shadow. The icon for “keywords” is a key, which is no more logical than using a musical note symbol as the icon for “notepad”. Possible alternative: a luggage tag (as used for the same feature in Apple’s Aperture software).

Clunky inspector. The inspector has six views — accessed using icons at the bottom — but four of these merely change the bottom half of the inspector. I can’t resize any of the inspector panels individually, so (for example) my usually empty Document Notes box grabs half the space and my usually non-empty Synopsis has to be scrolled in the tiny space it’s been allocated (I don’t want to make the inspector wider). The Snapshots feature is great, but in my view doesn’t belong in the inspector: it deserves a dedicated space.

Odd locations for essentials. The title and author of a project — pretty fundamental settings — are hidden inside Project > Meta-Data Settings > Project Properties, on the rightmost tab of a bunch that includes Labels and Status text. Conceptually the title and author seem more important than label and status text and should be easier to find.

“Scrivenings”. I have a real thing about unnecessary jargon, and the word “scrivening” is inaccessible to new and casual users. The manual mentions “scrivenings mode” and says that scrivenings are “temporary editing sessions” (how are they different from “editing sessions”?), but this isn’t reflected in the user interface. (Are manual and software out of sync? Worrying!) A key indicator that “scrivenings” confuses people is the tooltip for the toolbar icon: “View the group’s subdocuments as scrivenings (a composite of all the text documents).” Compare the hypothetical “Enable Hobgoblin mode and select the Ultraflange” and “Enter Group Edit mode and click Show Document Titles”. The first is unguessable. The second is pretty much self-descriptive and hence more easily discoverable (and usable). And crucially it simplifies documentation and can reduce support costs.

Confounding user expectations. For example, users are conditioned to the difference between a file and a folder. Folders contain files. Files are leaves on a tree, and folders indicate branches. When someone sees a tree structure with folder and file icons they expect that behaviour. It’s discombobulating that in Scrivener “folders” and “files” are interchangeable. I can include text directly inside a folder item in the binder, and I can also have folders inside a document item. This melts brains. My recommendation: in this case, interchangeability is a bug not a feature. Add new, cleanly defined structural concepts that make sense for the target audience — such as “part”, “act”, “chapter”, and “scene” — and enforce logical containment restrictions. This would also help with compilation formatting.

Formatting confusion. The ability to define formatting inside the compilation step is a great feature. But it’s complicated to get to grips with, and easily confused with formatting within the editor as they share the same toolbar, complete with presets. Adding structural concepts as above would help here, I think (instead of seeing Folder Level 1 and Folder Level 2+, you could see Part and Chapter, for example). A fanatical policing of terminology would also help: compilation formatting vs editor formatting. Finally, it would help tremendously if compilation formatting showed you how your own text will look instead of using lorem ipsum.

Annoyances with split editor windows. It’s great you can do this, but what I suspect is a common use case doesn’t work. If you have an “unsplit” editor open on document A and right-click document B in the binder because you want to choose Open > in Other Editor, it plonks document B into the unsplit editor first, replacing document A, and now you have a split editor with two views on document B.

Niggles. Some of the keyboard shortcuts seem odd, such as Escape to edit text: usually, Escape ends something rather than starts it. Also, whereas the “typewriter scrolling” mode is configured in Editor preferences, it is enabled/disabled using the Format > Options submenu rather than the more appropriate View > Editor submenu (in fact, I find all the menus confusing).

Preferences. These need simplification. The user doesn’t need to be able to configure everything: does anyone care whether the binder uses source list style, or which colours the target progress bars use? (Aside: whenever I see this level of configurability I’m reminded of Basil Fawlty asking a guest: “Rosewood, mahogany, teak? Just wondering what you’d like your breakfast tray made out of.”) The danger is that important and useful settings become lost. One way to improve this might be to move some settings to a more specific settings panel — for example, a settings cog icon on the corkboard could show you all corkboard settings.

Anyway. That’s enough. I know I’m coming across as pedantic and critical but when you use a tool daily the little problems wear away at you like a boot on a blister. I love Scrivener really.

Thanks for listening.

Thanks for your feedback. I’m the designer and developer, and I disagree with pretty much everything on your list, but you are of course entitled to your opinion. :slight_smile: For the record, I taught myself coding to build Scrivener, so it is not something built from a programmer’s perspective at all, but from the perspective of a writer who wanted an app just like Scrivener - so you can understand why I disagree, as I have put a lot of thought into how everything fits together to make the program I want. Is everything perfect? Of course not, there’s always room for improvement, and I’m always striving to make it better.

Your suggestion to have cleanly defined structural concepts and do away with file and folder flexibility is fundamentally against why I designed Scrivener, for instance - I hate programs that force me to use predefined structures. The whole point of Scrivener is that it can accommodate any.

Anyway, that’s a long list, and I have read through it all. Scrivener is a huge and powerful program and so it is necessarily complex in certain areas - often to allow the flexibility it is designed for - and as I say, I will continue to strive to improve it, although I wouldn’t hold your breath for the sort of fundamental changes you are hoping for. :slight_smile:

Thanks and all the best,

I agree with Keith, though always interesting to read different ideas and opinions.

A couple of quick notes (sorry I haven’t got time to reply in-depth at the moment - with 2.4 being out and the registration issues some users are experiencing, we’re a bit snowed under at the moment):

I actually agree with you here. The Retina display version of Scrivener has an updated icon that is more individual:

The non-Retina version will get that icon soon too.

You’ll find that Apple have used keys for keyword icons in many places over the years too. A luggage tag would make more sense if the terminology used was “tags”, and we already use the luggage tag icon elsewhere to denote meta-data tags (e.g. in Compile).

I disagree it’s “clunky”. It contains a lot of data, true, and I don’t rule out rethinking it in the future, but with regard to the synopsis, that is intentionally kept small as the synopsis area is not intended for swathes of text. Long synopses won’t play too well in the corkboard or outliner, either - thus the metaphor of an index card.

I disagree. Having it in the inspector makes it readily available from the main window (in version 1.0 it had its own window and was moved to the inspector for version 2.0 after consideration). It makes it easy to view your snapshots alongside the text, compare differences, and drag them to the header bar of the editor.

This is more the result of evolution than anything else. The “Project Properties” tab was added to this panel last, and it is in fact less important than the other panes for the every day use of the project, since those properties only have any effect on the compile procedure, whereas the other panes are used for actual composition and editing. I can see your point, though, so have experimented with moving the “Project Properties” forward to being the first tab for now.

Truthfully, this is the first time in eight years that this has come up as an issue, to the best of my recollection. It’s explained pretty well in the tutorial. I’m not a big fan of unnecessary jargon, either, but there really isn’t a great succinct word for saying what “scrivenings” mode does. It’s plain, if slightly quirky, English to understand that “scrivenings” means “writings”, though, so I don’t think the terminology is particularly bad. It’s not at all comparable to “ultraflange”, since “scrivenings” is not without meaning, so that is a poor analogy. Once learned, it’s better than “Composite editing mode”, which equally needs learning. The fact is that it’s not something many apps do, so we needed to come up with some term for it, and you’re the first to complain. :slight_smile:

Does it? It also provides ultimate flexibility. Hog Bay Notebooks used to work like this, too, and I absolutely loved that flexibility. It is key to flexibility in Scrivener. It allows all sorts of structures and experimentation. Not everyone starts a writing project knowing exactly how their draft and research is going to be structured. Given that this is a key element of Scrivener, I wonder why you use Scrivener at all if you don’t like this?

Did you hear that? That was the sound of me running away and shrieking. As mentioned above, this is absolute anathema to me, sorry. It’s exactly the sort of thing I was trying to get away from when I designed Scrivener. When I was looking for a writing app, every one that I tried either forced you to start out with some structure of “Part”, “Act”, “Chapter” and “Scene” (and remember that Scrivener isn’t just for novelists, so that structure would ostracise about 60% of our users) or allowed no structure at all. That’s why I didn’t use them. That’s a huge part of the reason I wrote Scrivener.

I agree it can be difficult to get to grips with, and you are right in recognising that the large problem faced by Compile is the absolute freeform structure allowed by the binder. If we made the binder rigid, allowing only for “Part”, “Act”, “Chapter”, “Scene” and suchlike, then we could easily simply Compile and make it a comparative doddle to use. But the flexibility is key to Scrivener, and complexity of Compile’s formatting pane is the payoff. Again, we have worked hard over the years to simplify this and to make it easier to use, but there is only so much simplifying we can do before it stops being useful - but we will continue to think about it.

Well, there are only so many words you can use for “formatting”. :slight_smile:

But that would involve pretty much compiling the whole text every time you made a change, which would be costly. I have been thinking about some form of preview pane (for 3.0), but there are some major hurdles - Scrivener can never show you exactly how your text is going to look in the vast range for formats to which it can export, because so much is dependent on the external program used to open the file. I couldn’t show you exactly how an e-book is going to look, exactly how a Word file will look, and suchlike. Some rough preview might be possible, but as I say, it would need to compile at least some of the text to show this.

That’s just a necessity of how ctrl-click works in the binder. It’s not ideal for the situation you highlight, though, true.

I am surprised you use Scrivener at all! There are an abundance of keyboard shortcuts, so some are necessarily convoluted. In the first years of developing Scrivener, one of the most common cries from users was for more keyboard shortcuts - and I listened. We don’t get many complaints about them now. And you can change any you don’t like yourself via the System Preferences. As for menu item placement, with so many options it is always difficult to get them 100% right, and we continually try to improve them without confusing users by moving them around too much. The Format > Options menu items probably could equally be in the View > Editor menu; part of the reasoning was to avoid cluttering the View menu.

My guess is that you’ve never developed an application and interacted with its users - yes, users really do want to configure everything. You have no idea how many users emailed us or posted to the forums asking for control over the progress bar colours, for instance. I’d be happy to take away every single option and have everything work the way I like it, but I’d have a mutiny on my hands. Whenever someone asks us to simplify our preferences, I’m reminded of the lament of an MS Word developer, complaining that everyone was always writing to them telling them how Word 5.1 was the best word processor ever, and they should return to its simplicity - but, of course, they should include X, Y and Z features that have been added since, as those are vital. But when they added up all the different X, Y and Z features that everyone wanted them to keep, it amounted to Word 2008.

Oh look, I managed a long and waffling reply after all - it shows how desperate I am to get away from the iOS syncing code…

Thanks for your detailed response. It’s great to hear from the developer of a program like this. I’m not going to argue point-by-point as you have your reasons and I doubt I can change your mind. I just want to say a few things, though.

“I’m surprised you use Scrivener at all!”

I’m kind of disappointed by this response. I’m a huge fan of Scrivener and I want to help you make more money by making Scrivener better. Sometimes the biggest fans are also the biggest critics, as they encounter rough edges more regularly than more casual, less fanatical users. By highlighting problems I have with the software and suggesting improvements, I’m showing that — cue schmaltzy music — I care. If I didn’t care, I wouldn’t be posting. It’s far easier for me to say nothing.

“Users really do want to configure everything”

Well, as you say yourself elsewhere, quite rightly, you’re not obliged to implement every suggestion on the forum. This is not a democracy. Let me point you to a great book by Alan Cooper called About Face, on user interaction design. One of his recommendations is the strangely worded but memorable “don’t put might on will” — essentially, there’s a difference between want and need. Blurry in places, sure, but a difference nonetheless.

My point about clearly defined structural concepts was not to force the user to work a certain way: but to allow the user to choose to work in ways that are familiar to them and to avoid unwanted confusion and complexity. I’m not saying that you should force the user to use parts, scenes, etc, or that you should remove your interchangeable folders and documents (you’d have to keep those for backwards compatibility anyhow). But a good user experience is built on user goals and the user’s mental model — not the software’s. Make the software work the way the user works, not the other way around.

I think adding structural concepts could actually increase flexibility and usability. Let me give a brief example.

Problem: When compiling I want to format front matter differently to the main body text, and differently to back matter. (Perhaps I want front matter to be smaller text, and back matter to use a different font.)

In the current (2.4) compiler formatting panel, I think the only way I can do this is by using different levels of nesting, to allow me to apply different formatting to the different levels. Front matter might be nested two folders deep, back matter three folders deep, and main body text one folder deep (for example). Then I could build different formatting rules for those nesting levels. This isn’t very intuitive, or usable.

Imagine I could state that a given folder contains front matter — perhaps by selecting that as a container instead of a plain folder, and perhaps (but not necessarily) gaining other semantics too, such as “you can’t place a ‘back matter folder’ inside a ‘front matter folder’”. Then in the formatting panel I could choose how text documents within ‘front matter folders’ appear, and bingo! Increased flexibility, increased usability.

I hope that better explains my thinking, even if you still disagree.

That sentence had a smiley face after it originally, which was only removed because there were too many smileys in my post already - it really was meant lightly.

True, but preferences is one place, being tucked away, that I feel should allow an abundance of options, especially in a program such as Scrivener, which is designed to be used by writers for many hours a day. Consider the number of criticisms you have, as only one user, based on your own preferences. Whilst I cannot - or will not - change the underpinnings of the program because of user suggestions or votes, I feel it is not a bad thing to allow users to customise Scrivener to a large extent given that it is a program for “living in”, to an extent. Whilst I have strong feelings about not having Scrivener force structure on users, I don’t see why I should allow a user to be using a yellow font against a black background with a green binder and Post-It-note style index cards with giant margins around the text and a Zapfino font if that is the environment the user wants to work in.

You have been reading Mr Cooper. :slight_smile:

Scrivener works the way I work, as the first user; if it works for others (and apparently it does), then great.

We have some plans for extra structural features in 3.0, although I doubt it will be exactly what you are suggesting.

Problem: When compiling I want to format front matter differently to the main body text, and differently to back matter. (Perhaps I want front matter to be smaller text, and back matter to use a different font.)

This approach would just replace one set of complexity with another, as it suddenly entails having different rules for different folders. Even if you could apply this formatting to multiple folders in Compile, it would mean telling Compile which formatting each folder required, meaning manipulation each time you added a folder.