Hello Scrivener Team,
Yesterday, while writing with Scrivener, I had an idea for a possible (fictitious) further development of the app (version 4 and beyond), which I would simply like to share as feedback.
It may be complete nonsense, but it may also be an evolutionary step.
I’ve been using Scrivener from the beginning and although I create large writing projects and project files, I still don’t use all the features Scrivener offers. I often hear from new users that they feel overwhelmed by the range of features at first and find the learning curve steep. The new writing app under development shows that there is a need for a simpler app, so why not rewrite Scrivener into a modular app where certain features can be added or activated as you need them?
I envision a basic version that might have the functionality of the new Writing app, so that you can write, organize and output your texts. But if you don’t need collections, for example, you don’t need to activate the module. If the compiler, with its comprehensive functions, is too powerful for some users, then perhaps a simpler function that you can choose between is enough. Why not make certain functions modular so that, for example, AI functions or text checking algorithms can be added or activated? If you prefer to use Markdown instead of styles for the editor, why not give users the choice?
I mean that you don’t just change a setting, but that entire blocks of code are then not active or can be added.
Wouldn’t the app be more manageable, customizable and, above all, easier to maintain in terms of the code base? Bugs would be fixed in the code of the modules, not in the entire app.
I know I’m fantasizing a little creatively here, but I’ve often thought that the development of new functions might be quicker and easier to implement if you only had to concentrate on one module.
That way, every user could decide for themselves whether they prefer Scrivener “light” or the complete package.
So much for my Sunday morning brainstorming session.
Wish you all a happy Sunday and a great writing flow.
Kind regards,
Thomas
Interesting idea.
Another way to approach is organize a learning Scrivener manual. The learning manual would teach you the basics on the binder, editor and inspector at simple levels similar to the new app, to get you up and running. Then you could have learing modules for the deeper dives on the editor, corkboard, and outliner. then finally turn people loose.
The advantage would be no software rewrite, just a different approach to introducing the program with an introductory manual, intermediate and then full manual. There would be less to face initially to get started, but the option to increase at your own pace without changing the software.
If you figure that one out it might be worth a computer science Nobel prize.
If you don’t need Collections, don’t use them.
Using the “Default” Compile format already greatly simplifies matters. (Although it also demonstrates why the Compile function is as complex as it is. It turns out that every user has a slightly different idea of what a “simpler” function should include.)
Both modularity and code reuse have been hot topics for both hardware and software developers for decades. It turns out that actually implementing that approach is much more difficult than it looks.
I can’t speak for Keith, but I’m pretty sure that a ground-up rewrite of Scrivener is not in the cards.
My take on this is, “Wait to see what the new app is like.” I see no point in speculating about how Scrivener might be simplified for new users when there is a new app, which from what has been said, is less complex (a scalpel to a Swiss Army Knife) in the offing.
Mark
Of course I was aware that some replys were joking about my thoughts, but that’s always the case in forums. And I really do not reach for the Nobel prize.
For example, saying that those who don’t need collections shouldn’t use them is a different approach to saying: Program the app modularly and don’t even load the “Collections” module at all, because the latter means that the code executed on the Mac will run with significantly less overhead than if you load the whole app and just ignore part of it. By modular approach I also meant that there would be a possibility to use third-party modules, for example grammar checker or spell checker from LanguageTool or others, as it is well known that these functions only work rudimentarily on the Mac (English maybe excluded). In addition, functions that are not included would not be confusing for beginners.
As a former UX shell programmer, I understand that developers have been optimizing code for eons. I wasn’t even interested in optimizing the code within the app, but actually breaking the app down into individual modules or plug-ins. It works in a similar way with Obsidian, even if that is a completely different application.
But as I wrote at the beginning, maybe it was just Nonsenses, so if the feedback has contributed to the general amusement, then that’s okay with me. 
I love Scrivener as is and this since years, so I hope nobody felt bothered.
Greetings,
Thomas
Well, believe it or not, I actually like your idea. In principle. But. I don’t think it would play out this way.
All of these hypothetical mini-modules would still have to work together to make any sense, and on top of that be aware that any of them could be disabled, and then work around this fact (alternatively: triggering a cascade of auto-loading dependencies).
You’re adding a lot more complexity, just somewhere else. And imagine sending your project to someone else without knowing “how much” Scrivener (on top of OS, version, fonts, etc.) is available on the other side.
Obsidian is not sufficiently complex as a good example. At the end of the day it’s just a plain text editor. It’s pretty good at keeping track of and updating all the internal links, though. You can turn off most of the first-party addons because they’re conveniences for the most part. You could even ditch Obsidian and still keep going. When it comes to
you’ll notice that they don’t all play well together, are often abandoned and require exactly the level of complexity you try to avoid. How many Scrivener users who hardly can tell what program version they’e using are going to dig around on Github? (The number is certainly higher when it comes to Obsidian users.)
That’s not per se an argument against very modular systems, but it needs to be said. How many musicians stay on basically “museum piece” OSs, just because there will never be an update for plugin X or Y?
Okay, I got the point. 
Obsidian and its plug-ins are also free. People are much less willing to tolerate integration issues when they are paying for the application’s claimed functionality.
Just as a general note on forum culture here: please do expect your feature requests to be discussed, and maybe even torn apart, but also sometimes avidly supported, by other peers. This is not the sort of place where only project maintainers are allowed or encouraged to respond—and often feature requests morph into support or usage discussions, as Scrivener does an awful lot of stuff already.
I love Scrivener as is and this since years, so I hope nobody felt bothered.
So to that: recognise it as a bunch of other people that feel the same way, and that’s why there is a tendency to speak up. And we like it that way, otherwise we would moderate accordingly, or make the wishlist tag trigger locked threads.
Okay, as to the issue itself, I can only join in and agree that this would be pretty nifty. I also agree with many of the good points made above, that as nifty as that would be, it’s probably not feasible. Since Obsidian was brought up, and it’s one of the more well-known examples outside of programming circles (text editors for programmers have been doing this for many decades), I’ll use it as a frame of reference here and there:
In particular:
-
Retrospectively making a 15 year old code-base fully modular, to the level you are hinting at, and especially on a code-base this large, is likely never super possible. That’s the kind of thing you have to be thinking about before you write any code at all, and write every single thing you do with that in mind, perhaps to the point that even internal things that can’t be shut off, in theory could. It would be a very low level and exhaustive rewrite—and so I definitely agree it is the sort of things you’d really only think of doing in a total from-scratch rewrite. And that’s quite big decision to make for a program this massive. I would say you would need some extremely compelling reasons for doing that, beyond this one goal—like the programming language it is written in being deprecated.
Obsidian is an example of a program built from day zero to be modular. It has always had a “core plugins” section in its settings, and you’ve been able to turn off things so fundamental it would be removing the binder entirely from Scrivener—an act that would radically change how you use it.
-
The impetus for creating modular software rarely has to do with catering to a different group of users than what the software was originally designed to cater to. That is an immense amount of work for doing something you probably shouldn’t do anyway. It’s better to stick to your core and original design and be your best at that, no matter how many hoards of new users come along and say they don’t get what you’re doing. That’s fine, it’s made for those that get it, just like mind mapping programs are made for those that get that thinking model and not those confused by it. That is not a judgement, or measure of intellect, it’s simply a matter of compatibility.
Now, going to that incredible effort to make software the community can help develop and define? Absolutely, that’s why you put that work into it. But that adds another level of complexity to the problem, because now you are not just thinking about how to make it so turning off the Binder doesn’t break everything else, but also what happens when people start doing things you never imagined doing with your framework. Can a program that was never designed from that perspective become that, over a decade later? Again, it’s not likely feasible.
I also agree with the point made above, that modularity isn’t (generally speaking) a good answer for making software simpler (if such a thing is even acknowledged as a worthwhile goal in the first place, I don’t think it is). Modular software on the whole tends to be aimed at a more geeky and technical audience. There are exceptions, but few of them are simple, and most of those exceptions are additive rather than subtractive, like MS Word’s addons.
I would speculate that the entire notion of turning off pieces of your software is probably orthogonal to the way a lot of the Scrivener-is-Complicated crowd is thinking about software. I don’t mean that in an mean way, it’s just that this crowd doesn’t seem terribly familiar with how complicated software can get on the whole. Surely, if they were more familiar, they would see Scrivener is on the relatively simplistic end of the spectrum for a start, and in particular into the areas they tend to try and push it, such as effectively replacing InDesign.
-
There is a large degree of overlap between one of the things that makes Scrivener “so complicated”, and also not very suitable toward retrospective modularity (at even a conceptual rather than code practicality) level: it is a program designed with lots of little features that by themselves do a few things, but work together with other little features in a chain of dependency, that allows people to essentially create their own features with the software.
It is, in other words, a kind of design that attacks the same desires modularity does, but from a different angle. Instead of making interfaces for coders to add features for other users, the feature design is meant to allow users to assemble their own integrations of features to achieve more complex workflows. An idea like my ticket-based revision tracking system is assembled from several other smaller features all being coerced together into an efficient workflow.
So not only is Scrivener already coming at this problem from another angle, the way in which it does so does not play very nice with the notion of turning features off entirely! This probably extends deeper than you may even think—for example you suggested Collections be one of the things you could turn off. You probably didn’t consider that would also mean removing Project Search, which is a special interactive Collection.
If someone disables the Document Templates feature, do all of the “character sheet” examples in the project templates that feature them stop working?
If you turn off metadata, what does the Arrange by Label corkboard mode end up doing? What happens to the filter settings in the compiler?
In short, Scrivener’s design is such that removing even one or two features could very easily cause a ripple-effect outward that disables whole large chunks of what the software can do. That’s a bad place to be starting from, if you’re going to retrospectively be adding modules—and that’s from a design or conceptual standpoint, not a code complexity standpoint like the previous bullet point.
Look closely at Obsidian. It’s good at hiding it, but it can get away with being so modular because most of its features don’t interact with each other at all. It is banking on modules to expand how it works, not end users. I wouldn’t entirely agree that Obsidian is not complex, it has quite a lot going for it, and it is not what I would classify as a simple program. But its complexity was again very much built from code line zero to be modular, from the code design to the core UI design to the conceptual design.
I also think some of the things you bring up are things that can be achieved without modules. Better Markdown support wouldn’t necessarily require turning off rich text editing, for example, or toggling between the two. That you bring it up in opposition to styles brings up an interesting point: styles are another example of an interdependent feature designed to integrate with other features and produce more complex compound features—and here’s the mic drop, they were designed to be extremely useful to Markdown users. Having them be on your Markdown toggle would severely cripple one of the big factors that sets Scrivener apart from the sea of Markdown editors out there: its innate modular workflow that lets you effectively add features to your document that don’t exist yet.
In fact, I would go so far as to say that Scrivener’s style system is if anything far more powerful for plain-text users than rich text users. It is rather primitive for that purpose, such that often the best use of styles is to merely get the text marked that way, so other more complex software like Word or InDesign can take the text and implement the real design for it.
With plain-text though? Styles can even allow you to invent your own compile file types. The LaTeX project template in Non-Fiction, or this compile format that can create JSON output from any ordinary project, both demonstrate that.
I don’t meant to nitpick; I’m just picking out a few examples here of how this isn’t a straight-forward task of chopping up a program into smaller pieces, and to again illustrate how it is striving for expandability through its tool-chest feature design, rather than by keeping that part basic and encapsulated, and leaving third-party developers to handle the rest with their own encapsulated features.
Lastly, as to the perceived complexity of Scrivener: as I said above, along with a good dose of incompatibility (what you don’t grok seems complicated but is easy for others), I think most people saying that have no clue what complicated software really looks like—because I don’t understand how anyone can say that without their tongue in their cheek. I like to say, if you think Scrivener is complicated, then fine, go use Framemaker, LEO or Org-Mode. We’ll be waiting for you when you come back…
Again I don’t mean to come off as elitist, it takes all kinds and all that, but I think it overall it is safe to say that Scrivener got hugely popular in ways that exceeded its original design parameters. That’s cool and all, we’re so grateful to be that fortunate, but again is the right answer to that problem to gut the design or fundamentally change it? I don’t think so.
I think the best answer is to use that good fortune of popularity as a platform to come up with something else… which is what we’re doing. 
In a way, you could say this is our love letter to all those who find Scrivener too much, but want to like it anyway.
As I like to say: Adobe didn’t flatten Photoshop to the ground because millions of newly minted digital photographers found it too complicated and impossible to use without lots of books. They made Lightroom.
Wow, Amber. First of all, thank you very much for your comprehensive and really detailed answer, which makes perfect sense to me. Sometimes ideas come up that turn out to be impractical due to lack of deeper background knowledge, like my thoughts. I really appreciate you taking the time for the detailed reply and I now understand the implications better. I also think that programming something new is actually the better approach and in this context I am now looking forward even more to the new app that is due later this year. Thanks again and have a pleasant start to the new week.