I guess that's reasonably clear if you think about it logically. I think what throws me off is that pressing either the left or right side will toggle the editor, rather than only changing when you click the side which is not the current mode. It's also a bit misleading showing the non active option half transparent as if it were disabled, when actually it is clickable
Hi and nice to meet you. Thanks for your feedback.
Obsidian looks way cleaner visually, but suffers from the same logical hiccup. Book there feels like a bookmarking function. I just checked Apple's approach and see they approach this:
- In notes.app there is no edit toggle. The note is presented in view mode, tapping it brings up the keyboard and editing mode as well as a new yellow-colored check-mark to switch back to view mode.
- In contacts.app there is a single "Edit" button. When tapped, the contact becomes editable and the button changes to a blue check-mark.
This is just a little input, I don't have a solution at the moment, but happy to explore. I haven't tested the Android version, but in case of iOS we could follow Apple's logic to stay consistent with the host environment and do it like this:
- User gets the view mode by default.
- When tapped, the editing mode is activated and a blue check-mark is added on top.
I'm attaching a few screenshots for convenience.
That's not really feasible because Joplin uses markdown notes, and the edit mode does not 100% support all the markdown rendering which is in the view mode. So view and edit uses different underlying components.
One of the reasons why people wanted this feature is because you lose the scroll position when you switch between modes. This was addressed for the rich text editor, but not for the markdown editor, as it is tricky to align the scroll position with the viewer for that editor. So a double tap to edit function is not going to negate the need for a separate view mode due to this syncing issue and differences in rendering when you switch modes.
- In contacts.app there is a single "Edit" button. When tapped, the contact becomes editable and the button changes to a blue check-mark.
This is kind of like what we had before, and what is intentionally moved away from due to the above issue and some users finding it annoying to have to make an extra tap.
Other than the toggle button, one thing I'm not sure here is if we need an option to always open in edit mode, always open in view mode, or remember last state.
The current mode slightly changes how the app work and I can understand it's a bit annoying to get used to it. But I'm not sure if it's one of those thing we get used to it and forget it was ever a problem, or if it's an actual problem that should be addressed. Any input on this would be very much welcome.
If you see this as a problem, could you please describe your use case, in particular how the aboce option would help?
Not sure if this is in response to my PM or if you have not seen it yet, but copying my thoughts here for reference:
A lot of the reasoning for making the mobile app remember the editing mode is because we can now render most of markdown content in the editor. But what hasn't been considered is some people don't like the inline rendering and it is an optional feature. So actually if you're someone who has the feature turned off, it becomes very impractical as you have to constantly use the toggle button to see the rendering
In conclusion, I think we do need to have a config option for whether to remember the last state, as this is a worse user journey for the above use case, than what users who wanted this feature had before
Hi Laurent,
Nice to meet you, and huge thanks and respect for the incredible project you've built and continue to maintain.
Regarding your question about whether users would eventually get used to the new flow: as a tech nerd, I can get used to this and I can imagine some users may even find it more efficient over time.
As a usability person, though, I think the new design is a regression, especially on iOS, where users expect a view-first, edit-later interaction model.
From my initial analysis of the current flow in iOS 26 (address book, notes, mail app, messages, and many third party apps like proton mail, etc), I would expect information to first be presented, then become editable with a very clear state change, then saved. All within one coherent flow:
view mode → tap to edit → editing state → finish editing → swipe back to notes list
To me, the current interaction creates ambiguity. I gave this some thought yesterday and currently see a few possible directions:
- Revert to the previous design.
It was not Apple's HIG compliant, but it was internally coherent and did not try to imitate Apple's interaction model halfway. The persistent blue action button also established continuity.
- Fully embrace Apple's current design language.
Personally, Liquid Glass is not really my cup of tea, but Apple is sticking with it and has already solved many of these interaction patterns and users are used to them. Nothing really needs reinventing there. This would probably be my recommended long-term direction, even if it means taking more time to polish properly before release.
- Keep the new approach, but refine the visuals.
In that case I just fix spacing, rhythm, state clarity, more typography consistency, and reduce smaller distractions, e.g small arrow at the end of the note title area.
I hope this feedback is useful. If you'd ever like help with UX/UI thinking around this, I'd be happy to contribute occasionally, though realistically my availability is very limited.
I've created PR Mobile: Add setting to choose the default view / edit state by mrjo118 · Pull Request #15423 · laurent22/joplin · GitHub to address this
Thanks for the detailed analysis @meny, much appreciated. Let's do this then and add the option, perhaps defaulting to Viewer mode then.
And let's update the toggle button too and make it clearer but I'm still not entirely sure how it should look. I will try to do some mockups locally and try to find what seems right
meny's original point is that the icon in that position feels more like a state indicator than an action button. I don't think using outline icons really helps with that?
Yes I guess I landed on these outline icons mostly as a way to make the buttons a bit less dominant.
It's possible that a toggle button helps with the state indicator confusion, but it also has its drawbacks (size, and still not that clear what is what), that's why I'm thinking to go back to the current implementation but try to improve it.
I'm ok with the proposed outline icons. I'm just wondering whether you think they should be left as action buttons or if it would actually be better to make them state indicators - in which case we should reverse the roles of the buttons (and amend the screen reader announcements)
The second screenshot with the edit button looks really neat and clean. As you observed, the capsule switch is overpowering for the limited space there. I tried scaling the book icon down to ~85%, but still didn’t like it so maybe the eye icon might work better there. Its entire geometry is much simpler and more contained.
@meny FYI there is another button which conditionally shows which is an eye, so we should not use an eye icon for view mode.
Are you saying the outline icons make the buttons look more like action buttons rather than labels? I don't really understand the logic for why that might help other than looking nicer, but if you think changing to the outline style icons alone is sufficient, then that's fine by me.
Ah, I mostly meant it from a purely visual perspective. I actually liked Laurent’s second screenshot precisely because it felt much cleaner and simpler overall. To me the capsule switch adds too much visual weight for such a small area, and the extra ovals do too. Sorry if I wasn’t clear.
Hi, I have a different proposition: "drop 'read-only view mode' completely". Maybe we could discuss it?
What I mean by this:
- default to "Rich Editor View Mode" (renders note same as previous View Mode)
- clicking in note allows editing (e.g. brings up keyboard on Android, shows buttons related to editing)
- pressing back goes back to "Rich Editor View Mode" (hides keyboard and editing buttons)
- have separate button to switch between Rich and Markdown (always visible)
(The above does not specify if there should be options to control default mode or remember last state - to be discussed)
The rationale:
- The "Rich Editor" looks exactly the same (or almost exactly the same) as "View mode", I think. So is there a need for a separate View mode? We get the "View" feature (nicely rendered note) without the burden of having to switch to Edit.
- What would be the reason for having a special "read-only View" mode? If prevention of accidental modification is needed, then I think:
- I'm not sure if that's really needed - I don't remember if I ever done such accidental modification.
- There is Note History that can be used to recover in case of accidental modification.
- A "Note locking" mechanism could be introduced if a real safety mechanism is needed.
- This simplifies the UI/UX which is generally a good thing.
- This mimics behavior in many applications (e.g. OneNote, iOS, etc) - no special button to enter editing, just click on document - it seems to work fine in the other apps.
---
Also some additional feedback:
- I think you're making important decisions quite quickly. I think it'd be good to let this be discussed a bit further before making a decision.
- After a couple of days of using this new approach, I personally don't have any problems with this new way of working.