I'm a software consultant with a focus on UX design. I also do web development and work on various software design and development related tasks. My education is in human-technology interaction. This project is an attempt to improve personal note taking activities and explore opportunities on fine-tuning the intricate process of capturing and managing my own notes and todos.
Different methods exists to organize thoughts, work notes, and tasks, both digital and analog. The system I in place is effective. Notes are saved on a synced cloud file system, named by date and time. The data consists of a mix of scanned paper notebooks, images, and markdown files. This setup provides flexibility and portability, without being tied to any specific service provider or data format. Any file format can be used and saved to the synced file system for easy access. The overall organization is well managed.
In both work and home life, there is a lot to remember and keep track of. Different conventions, platforms, and applications are dealt with daily. Organizing all this digital information is challenging, as it is scattered across various locations and formats.
Like most people, the goal is to work more efficiently and maximize the time spent on meaningful tasks, without unnecessary meta-work, stress, and the burden of maintenance.
Some of the problems with currently available solutions:
Taking notes and managing to-do lists should not feel like a chore. The mental effort required for prioritizing and organizing should happen with minimal overhead. Context switching adds to the fatigue. System should be defined so that it makes information easily accessible in order reduce cognitive load on lookups. Designing note-taking to be unobtrusive would allow more focus on tasks.
Tasks' exact order is often dynamic, and plans frequently change. Discarding outdated or irrelevant lists can improve the usefulness of kept notes. Reducing the tendency to hoard digital post-its is important. But at the same time, shaping the backlog of tasks or polishing archive of notes is not a guarantee to produce any additional value. The future need for given information is unknown.
The problem is about finding the right balance: enough maintenance to support efficient read and write operations and enough scaffolding and formatting to support consistent data format without unnecessary complexity.
Previous remarks can be morphed into value proposition: improving note-taking and task management could positively impact personal and professional life by reducing time spent on meta-work and increasing productivity.
The aim is to have a reliable tool for capturing daily notes at work and home. In addition, the goal is to make it easy to walk away from using the application if desired without losing the data.
Criteria:
Practical Approach:
A comprehensive approach, embracing the "walking skeleton" method, was advocated for this project. The priority was establishing a technical foundation to focus on content and design. As the solution was likely to be a local application, Tauri was initially chosen for experimentation due to its compatibility with web technologies and local file system access. This seemed beneficial for storing notes directly to the users machine.
However, as the project progressed, Tauri was replaced with a straightforward Vite development server running locally. This change was due to a subpar debugging experience with Safari and issues caused by the webview. Traditional web development setup proved to be more efficient for the needs of this project.
Experimenting with Tauri provided valuable insights into the technical aspects. A smooth build pipeline was established, particularly for reliable Mac builds, despite the complexities of different chipsets. Ultimately, the convenience of local file system access was deemed less critical, leading to a pivot away from the "native app" concept, saving further time and effort.
After shifting focus solely to the client-side, data storage without local file system access was required. Data was periodically saved to localStorage, with functionality added to save and load files directly for backup purposes. While this workflow was somewhat cumbersome, localStorage sufficed for most needs. This approach will be kept as an option for future prototypes, as it is easy to implement and simulates the experience of using a real app.
Object-oriented UX (OOUX) principles are appreciated, though not strictly followed in this project. In OOUX, design begins with object discovery. In this case the process was not as thorough, yet similar. After brainstorming note-taking activities, a rough understanding of the entities emerged:
Additional points:
Following this, a running prototype was set up, starting with the simplest, yet useful, idea.
I started playing around with an idea of "tapping", hence the first name: TapTapTap.
After some time I switched to the second idea: Bert. The idea came from Finnish sketch comedy show Kummeli (kiitos Pertti, thank you Bert). The application needed a mascot. At first I thought it must be an octopus that just "does many things at once".
The mascot later changed to a dog and the aesthetics went towards direction of monospace fonts and pixelated illustrations. In the picture below some of the logo ideas are shown.
Key criteria for the UI were established: it should be intuitive, visually pleasant, and provide clear signifiers for essential operations. The tag list was positioned on the left, similar to a typical file browser, with main items on the right to maximize space. Initially, adding a new entry was placed at the bottom, but testing revealed that placing new entries at the top was more effective.
Aesthetics, color schemes, and UI component details were not prioritized initially, as these elements were not crucial at this point in time and could be safely addressed later. However, it is important to remember that this is not always the case and situations vary. Working alone allowed for flexibility in design progression without needing immediate stakeholder buy-in. This approach optimized design work, focusing only on what was necessary at each stage. The important part was the understanding of decisions that were postponed. In a typical project context, frequent alignment with others would be preferable, though in this case, styling could be adjusted later without much additional effort.
While working on this project, eye strain was experienced, likely due to excessive screen time. Upon resuming work, dark mode was found to be easier on the eyes. Consequently, all apps, including this one, were switched to dark mode. Implementing dark mode support was relatively easy, thanks to the use of a custom CSS property setup called Cito. Switching the theme is done via dedicated controller.
It became evident that the system needed to balance being useful yet unobtrusive, which was a significant challenge.
Initial experiments included limiting visible notes, requiring task completion before revealing more, restricting modifications to existing notes, and considering application limitations as defining factors.
Some ideas, although initially appealing, proved impractical, confusing, or cumbersome in practice. Increased complexity in managing entries hindered the simplicity and unobtrusiveness of note-taking.
Simplifying each step and limiting options became essential. These restrictions, though often arbitrary, needed to be logical and consistent, like natural laws.
The app currently functions solely on the frontend. Redux (RTK) has proven effective for iterations, enabling easy movement of components within the tree. An open-source React Markdown editor was initially used for notes but was discarded due to slow performance with long texts, as it required useState for content. React with TypeScript has been excellent for prototyping. Plain CSS was chosen over Tailwind to keep dependencies low and to future-proof the project.
Given the trend in 2023-2024, integrating LLM into applications has become quite popular.
During the project, an idea of refining notes with ChatGPT directly from the app and adding image functionality was realized. However, localStorage had size limitations for storing images, and accessing the OpenAI API from the client was undesirable for potential public deployment. Thus, a separate backend was required. A simple NodeJS app with Express was set up to handle the connection to the OpenAI API by providing endpoints to the frontend. The backend also handled storing the images.
On the frontend, querying was enabled with prefixed prompts and note content as the prompt. Setting up the API was straightforward, though purchasing credits resulted in more than needed.
Six months ago, many opinions existed on what is important in note-taking. Interestingly, during the project, it was discovered that authoring solid memos has the most long-term impact. Good memos are intuitive, easy to follow, and tell the full story within the context of the memo. Previously, great value was placed on the function of collecting of anything with the belief that refining this process would create coherence in fragmented content. The greatest lesson from this project was a shift in perspective: the primary focus should be on the usefulness of the collected data. The right goal is to aim on having properly authored, purposeful, and accurate memos that are self-contained information packages. The way of such notes are collected with is the second order problem. Improving the ways to reach this end-result is crucial. Some level of periodic checks needs to be in placed in order to assess if the goal is reached. One easy way to test the outcome is to think whether or not reading the note makes any sense or if it brings any value in the future. Notes that does not meet this criteria should not probably exist.
textarea elements should be wrapped in web components rather than managed solely with React.This project provided valuable insights into organizing and managing daily tasks and memos. It demonstrated the feasibility of creating a useful application for personal and professional use within a relatively short time frame. However, Markdown files on native MacOS Dropbox-synced directory ultimately met the needs better. The function of note taking revolves around typing and text editing, which is highly nuanced operation from interaction point of view. This requires substantial amount of logic to be written for string manipulation. This work was not deemed reasonable to continue without clarifying the concept further, as having yet another text editor was not the primary goal. Bert can be happily archived as a successful proof of concept.