Desktop UI review

Hello,

During my first steps with Joplin there are a some usability issues I stumbled upon. I figured I could contribute to the project by exposing the friction points, and then share ideas and sketches on how to make things smoother.

Left part of the screen

1st pane

Probably some style tweaks would fiix most of the issues there:

  • the + button is really bigger than any other icon in the UI, I wonder if it's intentional?
  • "Notebooks" and "Tags" look exactly the same, while one can be actionned to reveal things, and the other can not.
  • under "Notebooks", there is an "all the notes" button, with an icon and a grayed out style. This makes weird alignment and feel like the button is disabled (or is some kind of subheading)

Notes list sorting

The sorting process is unclear:

  • icons in the sorting button are not really evocative of their sorting methods (a calendar for a modification date, and a calendar with a plus for a creation date, an "A" for title...)
  • tooltip is odd, as it presents simultenously two sorting methods, I can't tell for sure which one matches the current icon
  • It's hard to tell how changing the sorting methods will affect the order of the notes, because the list show no other information than the note title.

Dealing with notes and tasks

When creating a file, there are two different buttons at the top, making people having to choose between "note" and "todo". The only differences I could notice between the two:

  • there is a checkbox before the file name
  • when the checkbox is (manually) ticked, the filename is striked through
  • the tasks files are pinned to the top of the notes panel
  • on the editor pane, the state of the alarm button differs (it is grayed out for notes)

Are there particular benefits in having that strong of a separation between notes and tasks?

Menu bar

The menu bar make the app look kind of oldish, and breaks the dark theme too. Would be nice to offer the possibility to hide/reveal it, like Firefox does with the Alt key.

Text editor

Various interaction issues

Left and right arrows :

  • one could think those buttons are used to shift the text, because they are placed within the editor control bar
  • they are to go backward or forward in the navigation history, but not sure how frequently used it can be?

The globe button is also hard to figure out what it is for and how it works:

  • a globe doesn't sound a good metaphor for a spellchecker, I first thought it had to do with online collaboration.
  • having "enable spellchecker" and "language" lines simultaneously checked shows both a globe and the language code
  • having only the language checked shows only the globe, but not the language code

On the right edge of the editor, interactive elements are hard to dinstinguish from non-interactive ones:

  • one could think the document date is an actionnable item, maybe grouped with the globe icon. It is in zone where all other elements (icons) are interactive
  • buttons styling allows to distinguish disabled buttons from their normal state, but in most cases it is hard to tell fwhether a buton is active or not.

switching between editor modes

The two-panes button and the md/pencil button both have quite an unexpected behavior (Personnally it took me a couple of minutes to figures out the thing yesterday, and retrying today I'm lost again).

  • the first button is made of a simple icon, and switches between 3 states: plain md edit, read-only rendering, and side-by-side.
  • the second is a group of buttons to toggle between plain md editor and rich text editor. As there are only two buttons in the group, it's hard to tell which one of them is selected
  • the two panes icon (the one of the first button) may let people expect a full-height sidebar to open
  • when actionning buttons on focusing on the editor view, there is too little differences to tell which mode the user is looking at

I see the reasons behind having both a readonly rendering and the rich text editor, while they look mostly the same. Still, giving clearer indication of the current state and switching possibilites would greatly reduce the cognitive load.

Also it might be suboptimal to have things in opposite directions:

  • switching between editor modes happens on the far right of the editor view, while the button to open the external editor is on the left.
  • when opening the rich text editor through the controls at the top, a warning is shown at the bottom of the screen. As such it can easily be missed.

Environment

Joplin version: Joplin 2.12.15 (prod, linux)
Platform: Linux
OS specifics: Fedora 38

16 Likes

Proposition

I've made a couple of mockups of the improvements I would see. Below is a summary.

Menu bar:

  • hide or reveal the bar using the Alt key

Text editor:

  • cohesive button placements
  • clearer button states
  • refined editor switcher
  • stronger visual differenciation between RTE and MD editor
  • refined spellchecker icons and behavior

Here is a glimpse:

To read more about it, you can open this Penpot link and a very rough prototype.

I'll edit this message in the future to cover additional changes.

10 Likes

I have other requests related to desktop UI design, allow me to post my thoughts again

  1. Joplin's document management list should be reinvented in the form of a document tree.
    Now many code editors and even Win11 file managers have been updated to this form.
    This will save Joplin the width of a panel and appear less crowded when the plug-in panel is open at the same time.
  2. The maximum width of the plug-in panel should be fixed, although it can be adjusted after opening the plug-in panel. I click on a plugin and it suddenly takes up a lot of space and I have to adjust it for ease of use.
    image
    image
4 Likes

Basically, I agree with the first post, except for one item:

"Notebooks" and "Tags" look exactly the same, while one can be actionned to reveal things, and the other can not.

Both work the same: click on it to collapse it, or to unfold it if collapsed.

About your proposal:

  • The check on the language should be more separated from the language abbreviation, it is a bit confusing.
  • We lose the display of date / time. Maybe it could be on this line, but a bit farther from the buttons? And with a better baseline alignment with the language list…
  • Don't forget there are users preferring the clear theme… :slightly_smiling_face:
  • Otherwise, it is nice and clean.

And yet nothing indicates those sections are collapsible. The impression those sections don't work the same is reinforced by the fact that when launching the app for the first time, there is some content in the notebook section, while the tag section is empty.

Answering your other points:

  • agreed
  • that's not totally lost, it moved to the brand new note list (which I added since your post)
  • far away from me the idea of forbidding themes : D

Thanks for your feedback!

1 Like

No doubt there are a number of good thoughts and remarks in the OP. I do however doubt that presenting them in a long text like this will help getting any of them addressed, resolved or adopted. The workload of the devs - assuming they agreed with your ideas - would be very high.
Instead chances are that breaking down this text into many palatable points, in diffrent threads or feature requests would help them being considered.
Just my 2cts.

3 Likes

Thanks for your comment. Please keep in mind I am not requesting anything here. I've been putting work to help improving with fixing long-standing usability issues, avoiding friction, and enhancing everdyday's user experience. Perhaps that could do something for people to stick with Joplin and even support the project.

The reason I shared ideas through such a long post is that before breaking solutions down into implementable parts, we need a big enough picture of what's happening wrong with the UI, and why.

1 Like

As it seems I can't edit the post anymore, I'll outline below the different changes I propose.

Proposition

Let's start with the most preiminent part of the window.

Text editor

That's arguably where people spend most of their time. We do not introduce nor remove anything in the feature scope. What we aim here is to deliver the existing features in a straightforward fashion, avoiding people's frustration and allowing them to reach their goals more easily.

Header bar:

  • navigation buttons moved out of the text editon controls, to the header bar
  • button states give clear indications of what features are currently active or available
  • enable reminder whether they have tasks lists or not (unsure if we actually want this)

Editor switcher:

  • refine control hierarchy and icons
  • stronger visual differenciation between RTE and MD editor

Spell checker:

  • refined icons and popover behavior

Notes list

The pane would come with much cleaner controls at the top:

  • single add note button
  • collapsible search bar
  • simple sort button with explicit label
  • new popover to set sorting methods and options

image

Changes applying to the notes list itself:

  • show notes metadata matching the current sorting method
  • use space to separate the notes from each other
  • auto detection of todos (no more conversion as everyting is a note)
  • add possibility to pin any kind of note
  • use a line to separate pinned notes from the others
  • while hovering a note, show a three-dots icon to reveal menu

image

Overview pane

Reorganize the sidebar a tiny bit

  • move "all notes" out of the notebook section (it's not a notebook!)
  • turn notebooks and tags into non-collapsible sections
  • add label to the new notebook button
  • fully left aligned sidebar
  • while hovering a notebook, show three-dots icon to reveal the menu

This is I think the only feature introduction of this proposal:

  • add handy filters for finding todos and unsorted notes

image

Unifiy notes and tasks lists feature sets

This change is an important part to settle the ground for some of the improvements detailed above.

Menu bar

For a better looking app:

  • hide or reveal the bar using the Alt key

Final words

If there are any comments I would be happy to discuss these proposals further.

Thanks for reading!

9 Likes

@mjourdan:
Nice suggestions.

@mjourdan
I like your suggested improvements as well. :+1:

1 Like

Would anyone be able to code this?

1 Like

Joplin really needs an UI refreshment. Even more on mobile. But I still love it!

5 Likes

I have other requests related to desktop UI design, allow me to post my thoughts again

This thread is about solving issues that affect most Joplin users and, in particular, newcomers. The radical changes you propose as well as the plugin panel are out of scope here. The following link looks like a more appropriate place to discuss your points.

1 Like

amazing :v:t3:

1 Like

Very nice! Thanks for your work!

I'd like to suggest adding an icon to show the sync status of the note, either "synced", "currently syncing" or "not yet synced". The idea is to inform the user if their work is correctly saved in the cloud.

This would be especially important on mobile, since the sync status isn't visible while editing a note (you have to press back 3-4 times to see it). And it's important for users to see the status of the sync, since phones usually won't sync if the user closes the app or puts the device to sleep, causing sync conflicts between devices.

You can see a crude mockup that I made some time ago: Mobile: Display sync status while in edit view

You can take inspiration from Google Docs and other similar apps, which display a cloud icon with a checkmark when the current document is properly saved in the cloud.

3 Likes

@mjourdan, very nice! I like it. As @personalizedrefriger pointed out, your proposal seems to align with my proposal for an improved editor (An Innovative Approach to Joplin's Viewers and Editors: Tailored for Every User). If nobody else plans to work on it, it appears that I may take it upon myself to work on it next year, starting around March.

4 Likes

This topic was automatically closed 360 days after the last reply. New replies are no longer allowed.