As an interface designer, I never fall into the trap of believing that an app has too many features. Usually when people say this, what they actually mean is that the features are not intuitively accessible. And what that means isn’t actually usually the result of a cleaner interface, but instead how the features are hierarchically organized. Mostly, a good application is one that automates almost everything, but also allows a user to intuitively modify that automation. Scrivener is feature rich, but many of the features are similar and or offered up as different in different situations. The other problem with Scrivener is that it claims to integrate and automate the entire book writing and publishing process, but it does so largely by making features and functions previously only available in professional (read, intractable) book pre-press layout software. This isn’t automation. This is handing writers tools thay don’t and shouldn’t have to understand, and they do this handing off of pre-press tools in an extremely complicated way. Just wade into Litterature and Latte’s own Scrivener “Compile” tutorial videos to see exactly how awkward is the workflow required to take advantage of Scrivener’s pre-press “automation”. Not only is the process unintuitive, but it requires an impossible to understand underlying architecture. Doesn’t matter how many times a user goes through the ordeal, both the process and the underlying mechanism remain inscrutable. Best one can hope for as a user is putting it to wrote memory. This ism’t because there are too many elements or functions offered, it’s that these elements and functions have little or no relationship to what a writer care about when preparing a book for publication. Yes a writer cares about layout. No a writer should not have to know anything about how a particular piece of software is going about accomplishing any of this under the hood. Imagine if your car’s dashboard presented a giant touchscreen interactive diagram of the electrical and mechanical layout of your vehicle’s engine and drive train, and that this was how you were expected to drive the thing down the road. All of that functionality must of course exist, but none of it has anything at all to do with what a driver should have to know or do while guiding the vehicle down the road. An auto manfucturerer doesn’t announce that it is going too make driving more intuitive by strategically eleminating parts from the car’s structure or drivetrain. That would be insane and lazy and ultimately dangerous and frankly impossible. Same with software design. And then there is the fact that for all this complexity, Scrivener really doesn’t offer much in the way of options. There really is only one basic page layout available in Scrivener… just a header, a footer, and a single column of body text. There is no way to set up double or triple columns. There is no way to set up magins that can hold photos or illustrations or diagrams or pull quotes or asides or author notes or examples or reader exercises. When, asked, the people at Scrivener get entirely defensive and make ridiculous statements like “Scrivener was never ment to be a layout tool!” even while their own promotional material ALWAYS brags that Scrivener is exactly that.
When I am designing software, when I am prototyping applications, I start with general user layout, but I also expose the data model upon which I am building up the application. That data model and the tools I write to provide access to and manipulation of the data as the user interacts with the application, well none of that should ever be apparent to the user. Almost all of Scrivener acts, looks, and feels like the data model armature that a programmer builds so that he or she can keep track of the application’s mechanicals under the hood. That sort of thing should never be exposed to the user. Yet so much of the software I see being sold to the public never seems to make it past this preliminary stage of development. Putting pretty icons on a programmer’s armature doesn’t cut it. Yet that is what Scrivener is even now after three iterations.
Anyone want to build an actual solution for writers? Here is how you would do so. Make the thing WYSIWYG! Allow the writer to instantly toggle between views, and let those views be user defined. Let the views be exactly what the output would be once exported to Txt, PDF, print, E-Book, etc. Let all the views be where a writer goes about their writing. There should be zero difference between where someone writes and where someone sets up the layout for export. Swapping formats should be instantaneous and not at all interrupt the writing process or the content of what is being written. Setting up layouts should be as easy as dragging text box boundaries and dragging gutters edges and dragging elements. All changes should be a part of a hierarchical history that can be walked backed and re-branched at any time. Get rid of all the endless settings panels. Layout edits should be in-situ. Want to make a font bigger? Hold the optionKey down and drag up or down. Want to change a font? Hold down the commandKey and choose from a menu of fonts. Want to switch to another layout, one you’ve made for writing or one you’ve set up for output, just click on the layout button and choose from a list of default and custom layouts. Boom! Your writing never cares what layout you are in, only the layout changes around it. Changing the target page size of a layout? The software should automatically resize elements and fonts and text size to optimize to that new page size. Sure you can make adjustments, but the process should be automatic and simple and in-situ and optimized. Then create a marketplace for layouts, for styles, and allow users to share their layouts and for free or profit. Allow a user to choose two layouts and with a slider control, choose to mix the two layouts.
No separate writing mode, and layout mode, and output modes. You can write and create in any layout and you can just a layout while you write. The user is always in the same mode. Just with different veiws into the content they are creating. Yes there should be meta-data, but the user shouldn’t have to go to another removed interface to adjust or edit or browse it. The user decides what meta-data to include in what layouts. But the metadata is always available because any layout is available at any time. The user can choose to see hidden meta-data in the same way that a word processor allows the user to see or un-see hidden characters.
All of the functions and elements available in Scrivener should remain. Many more should be made available. But the interface should present these functions in a simple WYSIWIG mannor consistent with what a writer wants. No writer wants a seperate output or setup mode. No writer wants endless preferences pains stored and accessed in separate preference windows.
I believe that the problems I have mentioned here are common because most software is designed by geeks and dweebs, by people with cognitive issues that don’t at all map to the user’s they hope to attract. An ADHD ASD geek doesn’t think like the user’s they market to. Geeks make software for other geeks. Geeks are a small part of any market. Don’t design software for geeks.
