Summary: I suggest a special Joplin Store format that embeds the Joplin MD notes into an existing folder structure of a user or group of users collaborating. The existing folder structure is shown instead or in addition to tagging. Creating new notes stays as simple as with other store formats, but optionally notes can be moved into folders. Reusing the folder structure enables user to reuse their existing grown personal information management practice in Joplin. By using existing folders from shared work contexts (i.e. family share, friends share, company share), Joplin notes can become accompanying notes for collaboration and can also be shared and collaboratively edited.
This requires Adding multiple sources / syncronisation directories as prerequisite.
- The store is configured by type (webdav, dropbox, etc) and root folder to use and credentials how to connect. In addition, subfolders can be excluded from the store by pattern (i.e. “.svn”, “photos”, “2010/backup”). There is a “default folder for new notes” which is configured, for example “root/notes”. Part of this configuration (for example the exclusion patterns and default folder for new notes) are valid for all users connecting to this store and may therefore be stored in a subfolder or file within the root folder with a sensible name, for example “.joplin-config”.
- Mobile and desktop clients connecting to remote stores may synchronize the folder structure of the remote store to the local device, but only including the folder names and the Joplin note files.
- Joplin MD Files must be stored directly in an existing folder structure beneath the root folder.
- File names must reflect the Joplin Note titles. Changing the title must change the file name.
- A sensible file name pattern must be found, such as “.joplin.md” or “<title …>.joplinmd”
- Links to other notes must be stored as relative hyperlinks pointing to the related file/note.
- Renaming a note or moving a note must trigger an automatic search for notes linking to this note and updating the link.
- When creating a new Note, the Note is placed into the “default folder for new notes”.
- Notes should be movable into other folders.
- The user should be able to create new folders.
- When creating new folders in offline-capable clients connecting to the remote store, the client may create the folder on the client copy of the folder structure. During sync, the newly created folder should be synced to the store.
- The user should be able to delete folders. If a folder contains other non-joplin files, the user must be warned about this fact, alternatively: deleting such folders must not be possible. Deletion of folders must be synced back to the store.
- The user must be able to delete notes. If a note is deleted in the local client, it is also deleted on the store.
- The folder selection should be visible to the left side of joplin. The gui may hide folders that do not contain joplin notes. The gui should offer a quick filter to find folders. When filtering, the gui should show parent folders of found folders, i.e. filter the hierarchy leaving all parents visible to contextualize a found folder.
- When editing notes, it should be possible to embed pictures. When a picture is embedded, it should be included in the sync, given there is enough space on the client device. Client may offer a threshold which notes to sync. Client may load pictures on demand, when note is rendered, retrieving them directly from store into a tmp folder, to render note including embedded pictures.
- When editing notes, it should be possible to link to other files in the same file root (non-joplin files, see next point).
- Joplin should crawl the names of all files (but not their contents) to an index file and sync this to mobile clients to support the previous two features (embedding pictures, linking to files).
- Notes can be used as additional information in existing data organization systems. Example: I have a project, I add a Joplin-Note as summary. See also: the README.MD we place in GitHub projects.
- Backup? not needed anymore, as users and organizations who value their file and folder structure already do back up
- Export? not needed anymore so often, as the MD files are “right there in my folders”
- Sharing? in combination with 3546, this feature would realize support for sharing notes.
- Reuse of existing thinking and enabling users to see Joplin as a life-long companion (see underlying facts below)
- Synchronization for this store needs a new approach. At least connecting to Webdav/onedrive/dropbox/ and selecting the root folder stays the same, so some code can be reused.
- The architecture for this approach must be simple, minimalistic, stable, to not harm any existing folder structure. It would be good to “get this right on the first try”
- Other apps can rename folders/notes. Joplin should detect such operations and have a means to re-index its fulltext search-index as necessary. Also Joplin should embed unique identifiers in notes (i.e. GUIDs) and may include these GUIDs also as additional data in outgoing links as a way to make implementation more stable against other apps moving/renaming/deleting files.
- Other apps copy-pasting notes can cause duplicates. Joplin should detect such copy-pasting and identify the copy (new file) as a new file, for example based on file date and index status, and change the internal GUId in the new file.
Underlying facts for this feature:
- Folders and files have been around since the beginning of modern computing and will also stay around for millenia to come. All major existing and future file-exchange platforms will provide interfaces to have “folders” and “files”, so this approach is guaranteed to be valid today and for the lifetime of all current users of Joplin on all operating systems and online file management platforms.
- The folder structure of a user or organization is a grown knowledge-management system and well understood by the user.
- Users are known to know their folders by heart, organize them intuitively in a way that supports quick retrieval. For example, users intuitively go for an average of 21 files per folder, which is shown to be roughly the number of files per folder that leads to multi-level folder levels that are both quick to retrieve with fewest clicks (averge 14.76 seconds) and can at the same time store thousands if not hundreds of thousands of files The Effect of Folder Structure on Personal File Navigation
- User’s prefer clicking through their folder structure compared to using fulltext search in “56–68% of ﬁle retrieval events but searched for only 4–15% of events” (http://doi.acm.org/10.1145/1402256.1402259)
- When tags came up in addition to folders, they never replaced folders. It was clear from the beginning, that both folder structures and tags are going to be used in parallel: Better to organize personal information by folders or by tags?: The devil is in the details
- “Placing information in folders may give users a sense of control that tagging does not” Providing for Paper, Place and People in Personal Projects
- Folders are a thing when it comes to sharing information in groups.
- In addition to these references to others, I also want to add firsthand personal observations: I built a personal information management system called “Semantic Desktop”, and I was also part of the team developing NEPOMUK-KDE, which became a core KDE project and was shipped to millions of KDE desktops. That allowed me to talk with a lot of other programmers working on PIM tools and interviewing a lot of users. From this personal experience, I know that users loved reusing their folder structures. Building on existing OS features makes software future-proof. Also I noticed in user experience tests that a “folder tree to the left that can be filtered with a search box above and still shows the parent folders when showing search result folders” in the context of a PIM tool like Joplin is something that users LOVED using. This was the single most loved feature of the PIM tool “gnowsis” I built. Even 15 years after the user interviews I did on that feature, I still remember it, so I believe it is something important I should share here.
I used the words MUST, CAN, SHOULD in the spirit of RFC 2119
Related ideas by other users:
- Local files without hidden storage is similar but I believe I have proposed a clearer architecture.
- Notes in tree structure is a user asking for a tree structure but nobody replied
- Embed remote images asks to embed remote images meaning “copy” - whereas this feature here asks to “link” to other images
I may note that I joined Joplin as patreon to one day be able to share my own experience of developing similar open source tools in the hope that now - in a decade where I am not in a position to actively contribute to open source projects - others may benefit from the lessons I learned (the hard way) and I benefit by having a better note-taking tool I can use for the rest of my life. Today is the day. I found some time to write up some key observations in this feature request. I believe the linked observations and facts stand for themselves and am looking forward to a constructive, evidence/fact-based discussion.
To put my money where my mouth is, I hereby promise to donate 100€ if this feature is implemented fulfilling the described specification or in an even better way.