# On the Future of Zettlr

A few weeks ago, a debate broke out on the Zettlr Discord server on what Zettlr actually is, and what it isn't. This debate is certainly not new, but it has gained much more traction than earlier, which is due to the increasing popularity and maturity of Zettlr as an academic tool for writing and note-keeping.

For many years, I have refrained from deepening the discussion too much, but the problems in not having a clear mission statement are mounting so much that they start to become real blockers in any progress with regard to the feature set.

[Frank Carver has in this document](https://hackmd.io/@ZyBG2fDcQ5yi0ckzqNysdw/Sk38hr8e5) outlined in a very detailed, analytic, and sorted way, what he perceives Zettlr to be, and what not to be. He has created a basis for discussion which ultimately should lead towards a white paper to once-and-for-all stop the wild-growth that is Zettlr's feature set and instead streamline the efforts towards a sustainable app that can be developed further and can provide use-cases among the note-taking market, which is getting fuller by the minute.

This document is both a reply to Frank's thoughts and an attempt to further his ideas. I personally believe that he has written the most comprehensive analysis of the app thus far, and therefore this document should not be seen as a counter-statement, but rather as an extension that builds on this work.

## How it came to this

Let me start off with some background. This will serve two causes: First, it will make some of the mess more understandable because it will highlight my intentions behind what I did, and how I did it. And second, it will highlight the many non-strategic decisions I have made over the years, while the project gradually moved from a two-weeks semester break project to a full-fledged FOSS endeavour — without me knowing.

And I think that is one big part of the crux: That I did not see it coming where Zettlr went. I did not even drive by sight, I was navigating in thickest fog.

### The initial intentions with Zettlr

When I started working on Zettlr, my use-case was clear. Shortly before I started working on Zettlr in summer 2017, my main workhorse was Ulysses, a proprietary long-form writing app.

I started the search for a better alternative to writing everything in Word (rather: LibreOffice) just a few months earlier. A good friend (who also had the idea for Zettlr's logo!) started to search for better ways of writing and managing knowledge and kind of dragged me along.

Since I grew up with very traditional ways of working in academia, I immediately and unconsciously, began searching for a long-form writing app. I was never really into the whole Zettelkasten thing, because I felt it was too cumbersome for too little benefits, so I continued to do what I did before: Writing single long reading notes for everything I read, and then immediately transforming that into long-form term papers and research articles. However, gradually, writing in Markdown did change a few things.

With Markdown I still wrote one long document per reading note, but I began to automate extracting notes from PDF files (using Zotero) and then simply copy-pasting the extracted notes into a reading note file. I also started several attempts at my own Zettelkasten, all of which were ultimately futile.

So my writing changed, but little. I still had the approach to extract one long reading note from the articles I've read, then add my own thoughts to these, and finally writing a document by keeping all those readings notes open which I needed and switching between everything. In its foundations, this approach has never changed to this day.

### From Intentions to Development

However, Zettlr obviously did not support everything I needed from the very beginning. Initially, it was an extremely barebone app, lacking almost everything.

I had no experience with JavaScript, was bad at designing, and my state management was horrible. I can vividly remember how I shouted in joy once I saw my first file-tree successfully render in the sidebar, after trying to get the (back then complicated, now trivial) recursive function going for two days straight.

So after the initial version, the next two years saw me gradually implementing the features I needed. First, multiple workspaces, then a better global search, local file-search, regular expression search, the sidebar with the list of references (and more generally citation support), and so forth.

During that time, it became obvious that many of the initial design decisions were not clever in the long run. For example, the first versions of Zettlr only allowed to load in one single directory, and that was hard-coded into the app. The reason was that I was only using a single directory, and continued to do so. Then, after a few people mentioned loading in more directories might make sense, I suddenly started to utilize more than one directory myself. I didn't have the initiative to do so myself, I was dragged along by other users.

Implementing multiple directories was a pain. I had to refactor half of the code base for that. That was actually one of the first instances in which I began to suspect that this could break my back in the long run. And I wasn't wrong.

### From Development to Refactoring

The next years saw a gradual shift, with more and more people beginning to use Zettlr, raising demands towards its feature set, and the app beginning to see a wild-growth of features, sometimes helpful, sometimes not.

While initially I had a clear target group in mind — academics specifically in the humanities — and even closed issues if I felt they were not in line with that goal, gradually I gave way to more and more diverse workflows, leading to what Zettlr is today.

## Zettlr in 2022

To summarize, the development can be broadly divided into three phases. Initially, I just needed a barebone, minimalist editor which did what I needed, that is: Broad support for the academic tools and workflows that I needed, but nothing more. This phase seamlessly and gradually faded into a second phase.

This second phase was characterized by the development being rather driven by other people who opened issues than my own intuition. Many people highlighted shortcomings of the app which seemed absolutely logical to me, so I set out to implement these.

But rather than think about how these issues fit into a broader scope, I simply implemented one atomic issue after the other, frequently leading to dead ends in which I couldn't implement some feature before rewriting a part of the app. This then became more pronounced in a third phase which commenced last year.

2021 was mainly characterized by refactoring the complete codebase without implementing any new features. That this happened so late was due to two reasons: First, I never implemented anything with a strategic perspective in mind, and second, I never had the knowledge to transform the codebase into a scalable piece of software until after four years of constant development with JavaScript.

All of this now culminates in a fourth phase, at whose beginning we now stand. This fourth phase will be characterized by a more strategic approach to the app. The codebase is now largely in a scalable shape and will be able to accomodate even complex features without too much rewriting. Also, at this point all basic features of a writing app are now implemented and work stable.

What is now required is to streamline the feature set, throw out features that do not fit the mission of Zettlr, and add others that are still missing.

## A Mission Statement for Zettlr

What I missed to do throughout these last four years was to actually sit down and write a whitepaper for Zettlr, outline what it is, and what it is not, and then from this derive both a mission statement as well as a todo list for what has to be implemented to reach the state described by that white paper.

Debating the purpose of Zettlr is not new, however, as I mentioned in the beginning. And therefore it should not really surprise that there actually is already the skeleton of a whitepaper in existence. Two years ago, there was already a discussion about that, I think mainly driven by Lionel Ploum (if my memory doesn't fail me here). And that culminated in me writing a first sketch of such a white paper. However, that was quickly abandoned and never really put through.

Now, with the debate going on again, I think we should set out to finally pull that through. Let me spend the rest of this note on outlining the rudimentary, fundamental structure of this whitepaper-to-come.

### 1. Where is Zettlr now?

Let me start off with what Frank Carver has written, amend it with what I have written two years ago, and then try to further this in such a way that we can slowly start a whitepaper.

Frank Carver has mentioned, in short, the following aspects:

Zettlr is …

* … a Markdown editor
* … a Personal Knowledge Manager
* … a digital Zettelkasten
* … an academic writing tool

Zettlr is not …

* … a reference manager
* … a project management tool
* … a static website generator/ebook publishing tool

In order to put this list into perspective, it is necessary to talk about Zettlr's purpose, target audience, and then what I think Zettlr is and is not.

### 2. The Purpose of Zettlr

I think the purpose of Zettlr is very clear: It should facilitate everything regarding writing in a serious manner. If we have a look at other tools out there we can divide those into two groups and compare Zettlr in reference to these groups.

The first group simply includes everything that facilitates writing, including note taking tools such as Obsidian, logseq, notable, OneNote, and Evernote; but also general writing tools such as Scrivener or Ulysses.

The second group then would only include those tools that are being used by an academic audience, i.e. Microsoft Word, Notion, and Scrivener.

To the first group Zettlr compares in that it has only a miniscule set of functions in common with these. First, Zettlr is less suited for pure note taking, mainly because it acts on whole files rather than "blocks" and "pages", which is especially pronounced in Obsidian, Notion, and logseq. So if you are a person that likes to write atomic notes and interlink quite a lot, Zettlr is probably not suited for you. Then, on the other hand, the more serious writing tools like Scrivener and Ulysses have other things in common with Zettlr. They both also focus more on files, but one thing that sets Zettlr apart from both (and which has been my goal since the very beginning) is interoperability. Getting text out of Scrivener or Ulysses can be a pain, especially since Ulysses, for example, uses a non-standard dialect of Markdown, which essentially locks you into using their software. If you ever grow unsatisfied with Ulysses's exporter, you are at a loss. With Zettlr, all your files should almost without any changes work with other engines, apps, or websites, and if one ever encounters a situation in which this is not the case, it is the duty of Zettlr to fix that, not yours.

The benefits of Zettlr with regard to the second group are more pronounced, because Zettlr is aimed at an academic audience, so here we are talking less about the feature set and more about the workflows it enables. Since Zettlr aims to integrate all of the different features that are offered by these other apps into one single app, we can clearly state that here the purpose of Zettlr is to reduce friction for academics. We can see, it is much easier to compare Zettlr with academic writing tools, rather than with general-purpose tools, which is telling.

> The purpose of Zettlr is to facilitate a one-stop solution for every need an academic could possibly have with regard to their text-work. Since every academic needs to produce text, Zettlr should make that process as easy as it can possibly get. However, Zettlr needs to set boundaries and not implement *anything* that has to do with text. For example, Zettlr should never aim to replace a tool that already enjoys wide-ranging support, like a reference manager. On the other hand, Zettlr should also incorporate features that have nothing to do with text, iff (note the double-f) it facilitates an easier process of writing.

### 3. The Target Audience for Zettlr

This leads me to the second point, the target audience of Zettlr. It is fairly accepted knowledge that no single application is able to target every person on this planet. Even Facebook is now hitting a brick wall, and people are migrating to more specialized platforms. That being said, the easiest way of hedging the scope of the app is to clearly define a target audience. If other audiences can benefit from the app, that is wonderful, but it should not be a priority.

That being said, here I can simply copy and paste the draft over from the old whitepaper:

Target Group:

- Undergraduate, Graduate, and Postgraduate students
- Faculty (post-docs/profs)
- Researchers in industry labs

Not a target group:

- People who do not need to write a lot/retain many texts
- Tech-savvy people such as programmers or advanced STEM researchers who already use highly specialized software either way (i.e. those people who use Overleaf not just because other people recommended it, but because they write 100% in LaTeX)
- People who want a quick'n'dirty program where they can just drop some lines of text in and then forget about that again; Zettlr is an app you should start with your computer in the morning and then keep it running until you leave the office

Note that all of those people who fall into "Not a target group" are not excluded from using Zettlr. Rather it is that we focus on implementing things especially for academics. But many of the workflows academics need will also naturally be useful for many other people who are not academics.

This is by the way something important we should reflect in the communication. This list of "Not a target group" looks and sounds very excluding, which I do not want to communicate to the outside.

### 4. What is Zettlr, and what is it not?

Next: What is Zettlr, and what is it not? This is already hedged quite a lot by the above discussion of the target group. Here I have repeated the list of what Zettlr is and is not based on Frank's work, but amended with what I personally think Zettlr is and is not (or, rather: ought and ought not to be).

Zettlr is …

* … a text editor
* … a Personal Knowledge Manager/digital Zettelkasten
* … an academic writing and publishing tool
* … a central hub for academic work in general
* … interoperable with whatever other tools you need
* … focused on files as the main atomic unit
* … supporting a traditional, known way of working (metaphors that people have become used to such as files and folders)

Zettlr is not …

* … a reference manager
* … a generalized project management tool
* … a minimal, lean app
* … a data science tool
* … focused on "blocks" or "pages" as its atomic unit
* … creating *new* metaphors of working (such as "blocks" or "pages")

### 5. The Scope of Zettlr

This brings me to a last section. I have already mentioned that Zettlr in general focuses on text and leaves out non-text work, but also that Zettlr should not implement everything text-related, and also implement some things which are not text-related. So here are some features I personally think should be incorporated into Zettlr, even though they are not necessarily text-centric, as well as some text-centered features that Zettlr should not incorporate.

Examples of text-centric features Zettlr should **not** incorporate:

* Treating text as a database rather than files on some hard drive
* Reference management
* A "Daily Journal" (which, e.g., logseq supports) and similar concepts
* A Microsoft Word compatibility layer (in the sense that you can edit Word files, or preview them, etc.)

Examples of non-text centric features Zettlr **should** incorporate:

* Basic project management; not a full-blown Kanban with team support, but rather a personal way to manage tasks, suited for an academic style
* Collaboration on projects and single files
* A web-based interface that allows to make your work portable (+ facilitate said collaboration)
* Integration with much more services as we currently do, for example "exporting" markdown files not to a file, but rather onto, e.g., a blog (and, perspectively, publishing pipelines as those currently under development in many places of the world)
* Better integration with other apps that are not necessarily working with text, as long as they serve academic writing (i.e. calendars to support writing towards a deadline/conference, etc.)

## Quo Vadis?

Frank has set out four potential ways forward for Zettlr.

1. “Double Down” on one aspect and way of working
2. Provide more visibility of the different aspects
3. Split the application into separate tools
4. Split the application into “core” and “extension” components

I think that all these four potential ways forward should be part of Zettlr's journey, but none of them exclusively.

### Don't Double down: Be opiniated

Doubling down on one aspect and way of working is the only way Zettlr is going to survive, but I think there is a spectrum of how much we should go into that way. Focusing more on specific ways of working will enable the implmentation of more complex features, since every specialization we introduce will create more assumptions we can work with, and every assumption the app can make about, e.g., the structure of some files, will make the resulting code simpler, faster, and more feasible.

But if we double down too much on a single aspect, this will suddenly see many Zettlr users having to look out for multiple tools that facilitate what Zettlr used to do. It is a game of weighing, but I believe that if we reduce Zettlr's feature set too much, we will end up having to keep twenty tools installed. One hill I will die on is that Zettlr should incorporate the features of several app into a single interface; and not go the Linux way of "one tool, one function".

> Zettlr should definitely become more opiniated towards certain styles of working, but without abandoning the "blank canvas for your workflow" attitude that has made it successful

### Increase the Visibility of Features with a Strategic Vision

The next point touches the fact that the app has now become so convoluted that it is sometimes hard to find features. I think we should definitely "clean up" the app so that most features will be easy to find. However, that is an illness many FOSS apps suffer, because there are only few UX people involved.

I think this is very important, but also a group-project. This is a way forward we have to go as well, but it does not so much touch the app itself, as its infrastructure. This is something that will evolve as Zettlr starts to follow more regular tracks, and a strategic vision. Once the app has been opinionated a little bit towards certain ways of working, many of the improvements we can implement to make features more visible will automatically fall into place. Others will be noticed by us during the way, and once we have identified those aspects, we can plan how to mitigate these problems.

### Increase Interoperability Instead of Splitting the App

The third and fourth point Frank has mentioned is that it might make sense to split the app up into several components. He has rightfully mentioned that this could end up costing us a lot of time and efforts to facilitate, and might in the long run prove utterly unsustainable. I believe it is like that.

So I would strongly advise against blindly splitting up the app. A strategic approach, however, would be to increase interoperability. For example there have been calls to implement "rendering plugins" so that people could, for example, not just look at pre-rendered Mermaid code, but also PlantUML codeblocks. Also, markdown linters and other interfaces that could enhance the display of Zettlr are something that would fall under this category.

I believe that increasing the interoperability to other tools is crucial here. We can then remove some of the aspects of Zettlr while at the same time providing interoperability to these. We could, for example, add interoperability with Grammarly and the Operating System's spell checker, and at the same time remove the pre-bundled dictionaries (which would decrease the application's size by about 100MB). This way we could carefully remove some features from the app without actually removing the features. This goes some way towards splitting the app, so we'd have to make sure we only "externalize" those features where the threshold for users to switch to external tools is very low.

In short, what we could do is twofold: Some features that Zettlr already has could be externalized to easy-to-use tools so that users will not lose access to them while at the same time simplifying the app. This is, to a certain degree the splitting into "core" and "extensions", without really going all the way through. The second aspect to this then is to simply increase interoperability to facilitate more tools being able to hook into Zettlr, which would prevent a splitting of the app into different tools, but rather enhance the usefulness of both Zettlr as well as those external tools. Grammarly for example is being used by many, but it would mean people have to copy text back and forth. By integrating its API, those who would like to use it could do so without us having to implement that.

## Conclusion

I hope that these two notes will in a next step lead to a first draft of a whitepaper for the future of Zettlr. Let me finish this note off with another quote from the original white paper draft from two years ago, because I feel that this is still true for at least my personal vision of what Zettlr is, and is not:

> The mission of Zettlr is
>
> - … to be an easy to use app for people who don’t code and don’t want to dissect their operating system just to get basic things working
> - … to include state-of-the-art methodology, hence it will never be “finished” as continuously new technology should be included as it gets popular
> - … be a “blank space” that does not force you too much into a certain workflow