Project Background
Introduction
Markdown is a lightweight markup language characterized by its straightforward plain-text-formatting syntax. Its simplicity has led to its widespread adoption in the realm of notetaking. There exists a plethora of Markdown-centric note-taking applications, including, but not limited to, Notion, Obsidian, and ZK. These platforms seamlessly integrate Markdown’s intuitive nature with advanced features such as inter-note linking, tagging, and beyond. However, a significant drawback to these tools is the tight integration between the frontend text editor and the backend note management system, which inevitably results in functional limitations.
Problem Statement
Current note systems predominantly intertwine the frontend text editor with the backend note management mechanisms. Such an architectural choice restricts user flexibility. For instance, a user inclined towards leveraging Obsidian’s mind-map capabilities is compelled to contend with its cumbersome Electron-based text editor. Furthermore, users find themselves adhering to Obsidian’s predefined key bindings, rather than comfortably resorting to familiar shortcuts from their preferred text editors. Additionally, expanding the capabilities of these note-taking systems isn’t as straightforward as simply adding a plugin, especially when compared to highly extensible text editors like Vim or Emacs.
Comparative Analysis of Existing Solutions.
A myriad of exemplary note-taking systems currently dominate the market, yet none singularly embody the trifecta of power, portability, and extensibility. This section delves into and scrutinizes some of the market front-runners.
Obsidian
Obsidian stands out as a sophisticated note-taking platform. Equipped with a diverse array of tools, it supports activities ranging frompersonal note-taking and journaling to establishing knowledge bases and overseeing projects. [1] A notable feature of Obsidian is its embrace of a plugin-centric ecosystem, boasting thousands of plugins. [2] However, its dependence on the Electron framework can sometimes lead to performance concerns, particularly when handling extensive notes or numerous plugins. Additionally, learning the API that the platform provides for plugin creation may steepen the learning curve for developers.
Notion
Notion serves as a multifaceted workspace, seamlessly blending note-taking, project management, documentation, and other tasks within a unified platform. [3] However, its enclosed ecosystem poses challenges for integration with external applications. Being an Electron-based application, [4] Notion is not immune to performance-related concerns. Additionally, its ambition to consolidate numerous tasks into a singular app renders it somewhat bloated and tightly coupled. It’s noteworthy that both Obsidian and Notion adopt a closed-source stance, and unlocking their full prowess comes at a premium, potentially alienating users.
ZK
ZK is an open-source command-line tool developed to facilitate the management of a plain-text Zettelkasten or a standalone wiki. [5] While ZK closely aligns with our criteria, it falls short in several areas. It lacks features such as a mind map drawer, version control, and cross-platform synchronization. Although it can be integrated with text editors like Visual Studio Code and Neovim, [5] ZK doesn’t come with a universally compatible graphic user interface (GUI).
Project Objectives
This section describes the detailed objectives of the project.
Functionality Objectives
The primary objective of this project is to design a versatile, cross-platform, decoupled, and feature-rich open-source note-taking system. This system aims to:
Compete and Excel: Emulate the functionalities offered by existing competitors and surpass them by fostering a free and open ecosystem.
Universal Compatibility: Leveraging platform-native development tools, the system is architected to operate seamlessly across diverse platforms.
Versatility with Ease: The system is designed not only to cater to an array of user needs but also to streamline development efforts. With the capability to function as a command-line interface, it can be smoothly integrated with text editors, such as Visual Studio Code, ensuring users remain in a familiar environment.
Community Collaboration: By adopting an open-source approach, the intention is to harness the collective expertise and enthusiasm of the developer community. This collaborative spirit not only sustains the project’s vitality but also ensures that any antiquated components can be rejuvenated or replaced by community contributions.
Expected Outcomes
To achieve these objectives, the project will incorporate the following software components:
Command-line Interface Program
This encompasses a standalone background CLI tool that is compatible across all platforms. It includes functionalities like a markdown parser, a template generator, a fuzzy finder, and a language server, all curated to work in unison.
Text Editor Plugins
This involves integrating our backend program with various text editors, covering plugins for renowned editors such as Visual Studio Code, Vim, and Emacs.
Standalone Text Editor
If time permits, we project the launch of native text editors tailored for individual platforms. Alternatively, the development of a cross-platform text editor using the Electron framework might be pursued.
Project Methodology
This section outlines the systematic approach adopted for our development endeavors.
Design Philosophy
We have adopted the Unix Philosophy for our design approach. This philosophy emphasizes that each program should excel in performing a singular function. Rather than overburdening existing programs with new features for distinct tasks, it advocates for creating new programs. Moreover, it anticipates the output of any given program to potentially serve as the input for another, possibly unforeseen, program. [6] In alignment with this philosophy, our project is bifurcated into backend and frontend applications. The backend, further, is segmented into specialized modules, each expertly handling a distinct function such as text parsing or fuzzy finding.
Development Approach
We have selected the Agile methodology for our project because of its inherent benefits in software development. Agile facilitates regular software updates, promptly integrates feedback, and fosters consistent communication within the team.
Development Environment
For our backend program development, we have chosen Haskell. Haskell inherently supports multi-platforms, [7] enabling effortless adaptation across diverse platforms. Being a functional language with static and strong typing, [8] Haskell simplifies the creation of parsers and unit tests and enhances maintainability in extensive projects.
To manage our project, we will utilize Stack. Stack prioritizes reproducible build plans, supports multi-package projects, and offers a uniform, intuitive set of commands, simplifying the development process. [9]
Testing
We are committed to adhering to the Test-Driven Development (TDD) approach, ensuring unit tests are formulated prior to implementing any functionality. This will be facilitated through the automated testing tool, Hepec. Leveraging Haskell’s pure functional capabilities simplifies both unit and integration testing for us. System tests will be conducted at every development phase. Additionally, our development process integrates with the GitHub workflow, utilizing GitHub issues for efficient bug tracking.
Project Schedule
Project Initiation & Setup
In September 2023, we kick off with the project initiation, marked by our kickoff meeting where we’ll set our project’s expectations and outline its scope. This month will also see the beginning of brainstorming for the development of the Command Line Interface (CLI). Week 3-4 of this month will focus on establishing our development environment, ensuring all necessary tools and software are ready for smooth progress. Alongside, the initial design and layout work for the roject’s web page will be initiated. As the week progresses, we’ll also continue with the CLI’s development.
CLI Development
From October through December 2023, our primary emphasis will be on crafting the CLI tools. We’ll kick-start the process by simultaneously building a markdown parser and a fuzzy finder engine. Following this, our attention will shift towards the creation of a template generator and a notebook manager, both of which we aim to finalize by November’s end. As December rolls in, our efforts will pivot towards bug resolution, performance enhancement, and the development of the language server.
Frontend Development
Starting in the upcoming year, our attention will shift to crafting frontend applications. We will initiate this phase by constructing a plugin for Visual Studio Code, using Typescript by the end of February. Armed with insights gained from this initial development, we will then proceed to create plugins for Vim and Emacs by the end of April. Should time allow, we aspire to venture into the creation of native applications tailored for specific platforms or, alternatively, an Electron application with cross-platform compatibility. Parallel to the frontend advancements, we will continue refining and optimizing our backend CLI program.
Future Work
Upon completion of the development phase, our code remains proprietary. However, following the final exhibition, we intend to transition our project to an open-source project. This decision is driven by our commitment to benefiting users and inviting collaboration from developers. Additionally, we aim to expand our project’s reach by making it available on mobile devices, ensuring seamless synchronization. Furthermore, we are dedicated to continual maintenance, ensuring that our project stays updated and compatible with evolving technological environments.
Conclusion
In conclusion, the pursuit of creating a versatile, cross-platform, and feature-rich open-source note-taking system stems from identifying existing gaps in current market offerings. With many leading solutions tightly coupling frontend and backend functionalities, the need for a decoupled, efficient, and extensible system is palpable. By embracing principles like the Unix Philosophy and leveraging powerful tools like Haskell, our project seeks to offer users the freedom to choose their frontend while maintaining a robust backend system. Through diligent planning, meticulous testing, and iterative development, our team aspires to deliver a product that not only matches but surpasses the capabilities of current market leaders. Ultimately, the vision to transition to an open-source model post-project completion underlines our commitment to community collaboration, continual improvement, and wide-ranging compatibility. The journey ahead, though challenging, promises transformative outcomes in the realm of note-taking solutions.
Reference
[1] | D. Eastman. “Obsidian and the Case for Using More Markdown.” the new stack. https://thenewstack.io/obsidian-and-the-case-for-using-more-markdown/. (accessed Sept 30, 2023). |
---|---|
[2] | J. Pot. “Obsidian Review.” Pcmag. https://www.pcmag.com/reviews/obsidian. (accessed Sept 30, 2023). |
[3] | I. Torres,.”Notion goes where Evernote dares not what you need to know.” android community. https://androidcommunity.com/notion-goes-where-evernote-dares-not-what-you-need-to-know-20180608/. (accessed Sept 30, 2023). |
[4] | OpenJS Foundation and Electron contributors. “Showcase.” electron. https://www.electronjs.org/apps. (accessed Sept 30, 2023). |
[5] | M, Menu. “ZK: A plain text note-taking assistant.” github. https://github.com/mickael-menu/zk. (accessed Sept 30, 2023). |
[6] | E. S. Raymond, “Basics of the Unix Philosophy.” catb. http://www.catb.org/~esr/writings/taoup/html/ch01s06.html. (accessed Sept 30, 2023). |
[7] | B. Gamari. “The Glasgow Haskell Compiler.” haskell https://www.haskell.org/ghc/. (accessed Sept 30, 2023). |
[8] | “Haskell.” haskell. https://www.haskell.org. (accessed Sept 30, 2023). |
[9] | “The Haskell Tool Stack.” haskellstack. https://docs.haskellstack.org/en/stable/. (accessed Sept 30, 2023). |
Leave a Reply