Homepage    |    GitHub    |    API    |    FAQ

Sort Order Buttons and Per-Notebook Sort Order

There are many ways to use Joplin, and by using different notebooks, we can use them in different ways. Then, it is often the case that the appropriate sort order (e.g. title or updated time) differs from notebook to notebook.
However, in the current GUI of desktop app there is no way to switch the sort order except using a menu bar. It is inefficient and cumbersome from the viewpoint of UX.

So, there are two long-wanted features, "Sort Order Buttons" and "Per-Notebook Sort Order". Now, I'm developing them. First, look at the following animations, which are real examples.

  • Sort Order Buttons

joplin_so2

  • Per-Notebook Sort Order

joplin_so3

I've already finished the initial implementations and am enjoying them.

In this topic, I'll show the current feature details. Then, I want to polish the features and implementations by discussing with the community here. After the implementation becomes stable, I'll send a pull request to the Joplin repository.

Any comments and questions are welcome. Thank you.

Detailed Features

  1. Sort Order Buttons

    • Two buttons, "Switch sort order field" and "Reverse sort order", are added at the top of NoteListPanel.
      • The switch button cyclically switches the fields: Updated time → created time → title → cutome order → updated time ...
      • The icon images of the both button shows the current state of the sort order.
      • sort-buttons-labeled
    • Of course, any themes are applicable.
      • sort-buttons-theme
    • Besides, you can customize the icons using userchrome.css.
    • The two buttons are hidden when a global search is ongoing.
    • Shortcuts
      • Hitting one shortcut key enables you to quick get to your favorite sorting results.
        • Currently, what shortcut keys are used is not determined. I'd like to ask your opinions.
  2. Per-Field Reversal

    • Normal/Reverse order is kept for each sort order field (updated time, created time, title or cutome order).
      • In many cases, title tends to be normal-ordered and updated time tends to be reverse-ordered. By this feature, each field can have its own normal/reverse order preference.
      • That is, when you watch the note list in the alphabetical order, you can change the reverse order of the updated time by one clicking (without cliking the reverse button).
    • Its need is discussed here .
    • You can see a working example in the above first animation.
  3. Per-Notebook Sort Order

    • Some notebooks can have their own sort orders (field + reverse) for their notes inside.
      • For example, I usually use the alphabetical order for reading. But I want some notebooks for editing to be sorted in the reverse order of updated time. This feature enables that only selecting a notebook immediately let its notes be sorted by its favorite order.
    • Any number of notebooks can be specified to have their own sort orders via context menu.
    • Other (unspecified) notebooks are sorted in the shared sort order as before.
    • ”All notes" and tag results are also sorted in the shared sort order.
  4. Backward Compatibilities

    • The above features can be invisible/disabled from the option screen.

Current Status and Trial

The initial implementation is already finished and contains the full of the above features. You can immediately try them in the following forked Joplin (based on v.2.3.5).

In this topic, I want to discuss only about features. For the purpose to discuss the technical and implementation details, coding and bugs, I'll open issues at Joplin's github repo soon.

Related Posts

4 Likes

As you say I think this is a rather important feature that, if implemented successfully, will make quite a difference so I'm all for it. I particularly like the idea of having different sorting per notebook.

One small comment that you are obviously free to disagree with, relates to the following:

Rather than clicking the button to cycle modes it would be far more intuitive (to me) to offer a text menu with a mark indicating the currently selected sort method. I think this would also be somewhat superior in terms of accessibility to people using screen readers etc.(?).
Basically something like this horrible mashup of an image, you get the idea:
image

What I'm not so sure about is if selecting a different sort method should change the icon or if it should remain a static "sort" icon.

I think showing a list with the check mark for the selected order is good, but also that the icon should continue to change to indicate the active order—otherwise you have to click to determine which sort order is in effect

Rather than have 2 buttons, you can make things simpler by just doing what Evernote does: show arrows in the pop-down menu, and reverse direction when the current sort field is selected again.

2 Likes

I noticed by the recent change of the contribution policy of Joplin, I can only post a github's issue about bug reports or security matters there. Hmm, I have to seek some other places to discuss such technical matters before a pull request. Do you know any good place?

This is the correct place to discuss such matters. The GitHub is only supposed to be used for bugs and approved feature requests. Some people insist on using it for technical discussions, but are often ignored accidentally because there are so few people checking the GitHub for technical discussions.

Thanks @CalebJohn for your advice. I see.

I want to confirm that do you (and other core developers) intend technical discussions are accumulated as a knowledge base in the stocked pull requests? The intent of the question is I wonder which is the appropriate place for exploring technical matters between old issues and old pull requests. Before, I investigated only the old issues.

Currently, I provide the following commands:

  • Cyclically switch the field of sort order for notes
  • Toggle normal/reverse sort order for notes
  • Toggle whether a notebook has its own sort order or not

They can be assigned to shortcut keys, and plugins can invoke them.

Ideally all discussion would take place on this forum and issues/pull requests would simply link here. In reality it often happens that technical advice is provided in issues and pull requests.

So if you have a question, or want to start a technical discussion, please post here. But if you want to search for all available information you'll need to check here and the GitHub issues/PRs.

Thank you for discussing UIs.

My rationale of designing UI here is the following.

  • Minimum space, maximum worth of information
    • Display space is always limited and expensive.
  • Understandability for beginner users
    • Self-explaining UIs are required. A menu bar is one of handy ways.
  • Rapidity for expert users
    • At-a-glance information, fewer key-strokes and clicks, no-dragging are better.

As @Daeraxa and @huy said, UI like such the below Evernote is one of good-designed UIs.

image

Since Evernote shows only one UI for sorting, it has to meet both beginners' and experts' requirements by the UI. In such a situation, its UI design is reasonable.

However, since Joplin already has a menu bar UI which meets beginners' requirements, Joplin has a chance to provide more specialized UIs for experts. As @johano said, I also want to know the current mode of sort order at-a-glance. To provide quick information and quick operations for experienced users, I think that an icon indicates the current sort order is necessary and that clicking and shortcuts are preferred to dragging (pull-down menu).

It's only my opinion.

1 Like

You make good points, and maybe if the icons show the state, then perhaps the menu does make things busier than they need to be.

I don't understand the significance of the H icon for sort by title, maybe something with A to Z might be clearer?

alphabetical_classification_4279 or order_alphabetical_ascending_icon_135339

?

I know that Joplin (unlike Evernote) doesn't support due dates for 'normal' notes (not classified as to-do), but sorting tasks by due date would be a great feature in this context, too.

@johano, you just hit my point! I don't satisfy H icon for alphabetical order, and your suggestion a-z is exactly what I want.

Unfortunately, Font Awesome has no a-z icon without an arrow. I examined them, and H is the result of compromise. Any better icons are welcome!

By the way, I wondered which is better between the current two icon buttons and one icon with arrow/triangle button such as a-z down. Since if one buttons were adopted, its cycling length is 4x2=8 and is too long. So, I chose two buttons.

I don't have an issue with the "at a glance" type feature - I just think it would find it slightly unusual to have an icon that isn't static other than a shading/shadow toggle but I can understand its use case. I'd be interested for any UI/UX professionals to weigh in here - normally I would expect the 'static' UI to always be familiar with very little in the way of variation - or at least an icon that has a very similar appearance in all its potential states - like the Evernote Note list icon where the variations show what they do and what mode the list is currently in but its clear that they are all very much related.
image

Personally I would say that a cycling button with 4 states just isn't intuitive, I just know that I wouldn't use the feature enough to remember the order of the states and I'll end up missing the order and having to go through the cycle again - something that isn't a problem with a dropdown.
Having the dropdown also means that one doesn't have to remember the possible sorting states - I would often think that I would want a list sorted then would click to see the available options in text form to make a decision as to what fits best.

Also you mention that the menu bar UI satisfies beginner's requirements and that experts would want the UI, I'm not convinced that is the case - I would say the majority of beginner or non-technical/export users looking for that feature would look at the UI in the immediate vicinity, not up in the menus - particularly if they find the sort functionality as a UI button before they find it in the menu.
For the most part the opposite is true - the more technical and specialised functions are up in the menu bar whilst the simple accessible functions have UI icons.

I know this is now getting into the non-desirable world of trying to please everybody and massively overcomplicating what should be a simple feature but what about different actions on left and right click? Right to cycle, left to context or vice versa? I can see how that would not be slightly intuitive though unless you had read up about it first.

I can't think of an example with the current data available but in the future what if a new sorting criteria are added, this cycle would either have to get lengthy or divorced from the menu bar settings.

I'm being nitpicky, this isn't exactly end of the world stuff I know and this isn't supposed to be a criticism of your ideas, I've recently got somewhat into this kind of topic; considering areas of usability and UI design that I wouldn't have given a second thought about before.

@Daeraxa, thanks for fruitful discussions. Since there are several important points, I'll divide my response.

The first is about the need of "at a glance" feature. I recognize some people does not feel it is necessary. I'd rather think of some people who utilize their notebooks in various ways described in the first post. In such situations, there are often case that they want to confirm where they are. Especially, the Per-Notebook Sort Order feature is designed to support various notebook usages. Sort order buttons indicating the state of the current sort are strongly coupled with the feature.

The second point:

normally I would expect the 'static' UI to always be familiar with very little in the way of variation - or at least an icon that has a very similar appearance in all its potential states

I agree your statement. Providing consistent UIs to users and prevent them from being confused are very important matters in UI designs. Actually, I designed the following sort order buttons UI in order to keep consistency for the purpose to sort some items. Are they look bad?

sort buttons UI

They look good, @ken1kob. I looked here at font awesome and think the icons in the first row might be of interest instead of the H icon, but I'm guessing they are not available to you in the version of the font you need to use. Perhaps T might be an alternative to H, if the word Title appeared in the tool-tip hint on mouse over?

Looking forward to seeing this in Joplin, especially the per Notebook sort order capability, I think it's a very a strong and useful feature.

Appreciate your work

Cont'd. The third point:

Also you mention that the menu bar UI satisfies beginner's requirements and that experts would want the UI, I'm not convinced that is the case

A menu bar is the minimum to meet beginner's requirements. One of large issues of biginners is they often lost in the large ocean of UIs and cannot recognize what they can do and what they should. A menu bar is a base-line safety rope. Of course, for beginners as for experts, appropriate and effective UIs should be placed in premium class locations (as you said, "the UI in the immediate vicinity").

The fourth point:

Needless to say, the premium location in this topic is the top of note lists. To discuss what UIs is better there is very essential.

Several possibilities are already suggested. I summarize here.

  • (A) Two sort button pairs indicating sort state (my original post)

  • (B) Static icon + drop down menu (like Evernote)

  • (C) One icon indicating sort state + drop down menu

    • It's an improvement of (B). An example is here.

      • sort-buttons-menu2
    • One problem is that in the default icon font set (Font Awesome 5) has very limited sort icons (alphabet, numbers, and quantity) and does not have time and date.

  • (D) Two sort button pairs (left click) + context menu (right click)

    • Daeraxa's (modest) hybrid idea:

      I know this is now getting into the non-desirable world of trying to please everybody and massively overcomplicating what should be a simple feature but what about different actions on left and right click? Right to cycle, left to context or vice versa? I can see how that would not be slightly intuitive though unless you had read up about it first.

    • First, I have maybe the same opinion with Daeraxa. It's too complicated.

    • Then, I implemented it quickly and examined it. The below is a real example.

      • joplin_so_menu_D
    • After I examined the UX of the implementation of (D), there are some findings:

      • Evernote-style drop down menu is not bad. I feel it's in the range of acceptance for this topic's features.
      • However, the action of toggling reverse state is not intuitive for newcomers. Evernote's fancy coloring and icon designs mitigate the problem. But, such way of mitigation is difficult for OSS developers.
      • After several minutes operations, I feel cumbersomeness on the context menu. Since left clicking and right clicking have the same functionalities, buttons are always quick and comfortable after being accustomed. (Sorry, the number of examinees is only one (me!), and it's not a controlled experiment.)
    • As the result, two UIs embedded on the left and right clicks are redundant. Either of them are acceptable. (But, my preference is buttons. :slight_smile: )

1 Like

You can also use the icomoon set, although Laurent created a simple set.
2 options:

  • ask Laurent to create a new set that includes the new icons you would like to see
  • load your own little icomoon font set

I think this is the main area in which the two requirements differ. The 'button' system
(type A) I think is the superior one for people who would be frequently changing the sort order - for example those who have relatively few notebooks but a large number of notes within a notebook.

Types B or C seem like they would be better for those who would tend to pick a sort order and leave it in that state - I for example tend to have a larger number of notebook depths with fewer notes within - each one tends to lend itself to a specific, static, sort.

No I don't think they look bad - in terms of the information they display within the context of sorting they seem sensible (including the custom one - I assume you are going for the idea that to custom sort you have to use the mouse).
However, if you just take that icon by itself, none of them actually seem to imply (to me) that they are for sorting unless you intuitively understand the reasoning of the arrow next to it but even then I'm not convinced that a user seeing the hand + an arrow would intuitively assume it is a sorting button whereas some form of A-Z, sorted blocks, double arrows etc. is ingrained into most people at this point.

To compare of examples of sorting from other similar applications with similar functionality (ignoring any that only have it via menu bar or settings):

  • Evernote - Static icon with dropdown entries (reverse included)
  • Obsidian - Static icon (up/down arrow) with dropdown entries (reverse versions separate)
  • Noteable - Text button with dropdown entries + separate arrow for reverse
  • Standard Notes - Combined display + sorting text button with dropdown entries + separate reverse option

So basically the norm is a dropdown menu rather than a cycling button but it isn't like it would be setting a precedent within Joplin - the toggle editor layout does exactly that. The difference in that the icon doesn't need to change because the effect of pressing it is immediately obvious in the layout.

Totally agree - although very interesting to see it in action, thank you! I suppose there is always the option of:

  • (E) Long click for dropdown but that hardly solves the problem although I feel it is a slightly more standard approach or
  • (F) Both - have it selectable between cycle + dropdown as an option but this still runs into another issue of settings clutter that somebody is going to set once then never look at again (or forget how and where they changed it if they install a new client), there are always going to be dissenters no matter what gets chosen

Ultimately whilst I have a small preference for the dropdown style (B or C), this is hardly a hill I'm willing to die on, I'm just offering an alternative and would be interested to see what the community/userbase think about it.


One section not really touched on much so far is fitting this in with the existing UI layout - there have been quite a few discussions about needing a design system to follow as well as more flexible theming or layout options and a more unified design as a whole. Whilst I don't find the default UI particularly distasteful or problematic, the notes list panel already sticks out to me compared to the theming of the rest of the application and I don't think the addition of a new button in this space helps (don't get me wrong, I still think the functionality trumps this issue but I think it is worth discussing).

The new button (particularly in its expanded form with the arrow button) will take up more of the already limited real estate, particularly if you have a narrow aspect monitor or run Joplin on one side of the screen, one side effect is that the persistent data from the search box might lose quite a bit of its effectiveness (particularly as supported queries can run quite long with various arguments e.g. (created:20200118 -created:20201215) and one might wish to glance back at the present "filter" as shown in that box to compare to the results.

For example if I were to shorten by usual note list panel width by approx one extra box - this is what ends up being shown for a single 'created:' query:

image

Obviously this isn't a problem if you click back on the box to expand again but that sightly defeats the point in having that aspect of the UI at all. This is within the constraints of the current theme and layout, if this was to change with a theme or layout alteration then this would likely not be a problem as it would be taken into account ahead of time.

Do I have a solution to this? Not that I can think of, at least not one that fits within the current theme and layout. Just something else worth noting.

1 Like

@former_evernotist, I agree. Sometimes I have a need to sort by "due date". But I'm not sure that it can be a member of the highest priority group in the limited premier UI location.

Technically, adding fields of sort order is not easy and has a large impact on the implementations of other functionalities. So, I won't include adding field at this time. But it is worth discussing for future enhancements.