An Innovative Approach to Joplin's Interface: Tailored for Every User
This new interface for joplin, Inspired by Obsidian (apparently, these were mostly my ideas and I havent used obsidian ever but it seems many of the features are already implemented there), introduces a revamped user interface to cater to diverse preferences, ranging from text-centric users to those seeking a rich visual experience. This new design philosophy revolves around two primary modes: Viewer and Editor, with the traditional split mode being phased out.
Modes Overview
Viewer Mode: Focused on aesthetics, this mode renders content beautifully for an enhanced viewing experience. It supports minimal interaction, like editing images created with jsdraw. The editor remains largely unchanged, maintaining its high quality in Joplin.
Editor Source Mode: This advanced mode allows users to work directly with the markdown source, providing a clear and straightforward editing experience.
Editor Non-Source Mode: Similar to the current layout, this mode offers basic rendering like bold, italics, headings, simple code blocks, and blue links. Images are not rendered to maintain a cleaner look.
Checkbox Toggling: Checkboxes can be toggled directly in the markdown source using Ctrl/Opt + Click.
Link Navigation: Links are accessible through Ctrl/Opt + Click or via the context menu.
Highlighting: I dont know about that. That is for you source mode folks to decide. Is it too much? I am talking here about: ==mark==, nsert syntax (++insert++), sub (sub), and sup (^sup^) syntaxes.
We also shouldnt forget about the wyswig compatibility because that seems to be very important to the project.
Editor Non-Source Mode: A Game-Changer
Direct Integration: Eliminates the need for external plugins like rich markdown and enhancement.
Interactive Rendering: Clicking on rendered elements like images, videos, and tables converts them back to markdown for editing. (For video: does not happen when you click on play, pause...)
Math Rendering: Supports inline/block math rendering, already available through the enhancement plugin for example. Plus additionaly there should be a preview when editing (see second image)
Mermaid Diagrams: Rendered for viewing, but editable on click.
Task Management: Tasks are rendered.
Headlines: Rendered for clarity, with source code viewable on click (which means the hastags)
Links and Links to Notes: Rendered. When clicked on jumping to the links or linked note. When putting directly to the right it shows the source code.
Audio : is just rendered?
UI Considerations
Rich Editor Positioning: While beneficial, the rich editor should be an optional feature, not the default. The main problem is that it breaks many markdown things.
Toggle for Editor Modes: Simplified UI with toggles to switch between editor and viewer modes.
Source Mode Indicator: A distinctive icon to indicate when the source mode is active for example to the left of the toggle, which you can click on and activate source mode or deactivate it.
This innovative approach aims to harmonize the diverse needs of Joplin's user base, offering a flexible and user-friendly interface that adapts to individual preferences.
I am specifically interested what @laurent@personalizedrefriger@tessus and the other contributors think. Please everyone chime into the discussion to finally get a milestone for this so that the goal is clear and everything can be implemented.
For example, Logseq displays the markdown source code for the paragraph you're currently editing. The moment you get to another paragraph, all others are just rendered.
It uses /slash commands to allow users interact quickly with markdown.
Another modern approach are gitlab comments. Here, the viewer is a blend between WYSIWYG and Markdown. You can write markdown as you would normally, or you can write as you would in a WYSIWYG editor. Both will get the same result. The editing experience is smooth both for humans and devs:
I think that both of these approaches are so fluent that they don't really need a split between edit/view/wysiwyg mode.
Personally, I use more the WYSIWYG Joplin editor because it makes no sense to write markdown when there's a tool that does that for me. However, sometimes it's not easy to remember the keyboard shortcuts and I end up having to use the mouse to click the buttons, which I don't like at all. I like most gitlab's approach. It feels natural both if you come from VSCode or from MS Word, and the code mode is always a click away.
A great editing experience is indeed a standout feature for notetaking apps (e.g. Typora, Notion). I agree with the statement above, Joplin's editing (and viewing) modes are inferior to other apps, and should be upgraded. At the moment, I rely on @CalebJohn 's Rich Markdown plugin.
+1
I see this all the time with Evernote users who try Joplin - they like so much about Joplin, but the editor/viewer split concept is very foreign to them. Obviously many, including myself, make the transition, but many others do not.
I also use Rich Markdown plugin, though I keep viewer up b/c I use another of @CalebJohn's plugins - Inline Todos.
@Yajo , your insights are quite valuable in understanding the diverse preferences of users regarding markdown editors. There indeed seems to be a division: some users, including myself, prefer the raw markdown code, while others opt for a more visually refined interface.
In light of this, my concept aims to provide a balanced solution. For those who favor the classic markdown experience, the "Editor Source Mode" in my proposal is designed to meet their expectations. This mode offers the traditional, straightforward markdown environment they are familiar with.
On the other hand, the "Editor Non-Source Mode" caters to users who desire a more modern, user-friendly interface. This mode resonates with the first app example you mentioned, offering a sleek, uncomplicated experience, bypassing the intricacies of raw markdown.
Your second app example reflects what I envision for the "Source Mode". This mode is for those moments when users need more control over their markdown code.
Furthermore, in response to the other contributors' points, my concept significantly reduces the reliance on external plugins like 'rich markdown'. The enhancements I propose are integrated within the editor itself, aiming for a more seamless and integrated user experience.
To sum up, my concept is about providing choices and versatility. Whether a user is inclined towards the traditional markdown approach or prefers a visually appealing, modern interface, my proposed redesign for Joplin is intended to accommodate both preferences without compromising functionality or overall user experience.
I hope this provides a clear picture of the direction I'm advocating for.
@laurent , I am truly passionate about this and would like to begin working on it next year. I hope @personalizedrefriger can assist me with the codebase. ;). I think that would be the breakthrough joplin needs.
