Homepage    |    GitHub    |    API    |    FAQ

Cleaner design of the sidebar?

Is there a userchrome.css for I?

If there is a vote, my vote goes for I.

I do like the idea of reducing complexity in the UI. For that reason I would prefer the design proposal C.

But before changing anything my two cents about what is the major goal:
For me there are two thinks I need help from the UI

  1. I want to be able to see in which folder I am operating
  2. I want help selecting the right folder

As in the mobile app 1 a slight color distinction could help. For 2 I thing if I do have un- button (or arrow) this helps me already, because I know where I want to go or? So the fokus should show me where I am and not in which layer I am moving because (in my setup) this is not important

@nr458h, hasn’t the first wish already been implemented long ago?


I don’t want to abolish the selection marker, and the striking blue color is perfect for me. The mobile interface is also okay in this respect (I can substantiate why light grey is a good choice in that design).

Some more graphical experiments

  • A is the current sidebar.
  • J is based on idea 5.
  • K = J with monochrome background.
  • L = K with more padding space at the left side.
  • M = D (based on idea 2) with monochrome background.

I hadn’t mentioned my own preferences yet. Time to do so. Idea 5 has won ⇒ J, K, L. These are the least crowded designs, and the controls simply don’t stand in the way of the visual clues about the tree structure. I’m not sure about the background coloring. I prefer monochrome now, but maybe this type of level emphasizing should be made optional. L pleases my eye most, but it widens the sidebar a few pixels more (or when keeping the width of K: shows one or two letters less at long titles).

Expand/collapse symbols

I also did a quick survey of the button symbols, to see if some common standard emerges:

  • The red symbols try to mimic the function of the button: “get more” vs “get less”, or “drop down” vs “haul in”.
  • The black symbols represent the current status by pointing in the direction where the details can be found.

Both systems are justifiable. Pity that there are two systems. The usual annoyance.


Option “M” is what looks most comfortable to me, as most of the software I use have tree structures like that. The slight color changes in “A” and “B” are a little distracting for me

I also like version M the most.

From a CSS standpoint, because of the way the backgrounds are applied (directly to the element vs using a class), I haven’t figured out a way to remove them without also removing the selected state, so for now I ended up implementing something that looks ~version E. This is added to userchrome.css:

.side-bar {
    background-color: #292A28 !important;

a.list-item {
    color: #A3A79F !important;

.fa {
    color: #575856 !important;

.folders i.fa.fa-minus-square, .folders i.fa.fa-plus-square {
    padding-right: 3px !important;

.folders .list-item-container {
    margin: 0 !important;

.folders a.list-item {
    border-left: 1px solid #575856 !important;
    padding-left: 9px;
    margin: 0 !important;


Another contender for List of CSS elements which should have a class

Yep, I added that on there under "Selected and Deselected Notebooks" :slight_smile: Would love to see those all added.

Thanks for looking into this issue @memophen. Perhaps we could have a non-binding vote to decide what to do about the sidebar design? One vote to decide “background colour vs no background colour”, and another vote to decide what expand/collapse symbol should be used.

Although for this maybe we could just pick from your survey of existing symbols (looks like arrow pointing right, and arrow pointing down should be the way to go).

I would like to suggest a third alternative: make backgroundcolor/nobackgroundcolor a user setting in the Options > Appearance page.

Plus: another other vote concerning the placement, left or right?


With background colour on the left

I would prefer not to add an option for this as it can already be customised by usercss if needed, but instead try to find what’s the best default.

Unfortunately the css modification for the notebook background has a drawback. If you change the background via css, the selected notebook does not have a blue background color, thus you don’t see in which notebook you are in. Otherwise I’d agree 100%.

When I look at other apps that have a hierarchy of folders (just checked Firefox, Chrome, Thunderbird and Sublime), I don’t see that any of them has the kind of colouring that we have. Personally I find it a bit distracting and I’m not convinced it helps navigating the tree of notebooks, so I’m in favour of removing this and go back to plain colours.

To improve the distinction between notebooks and sub-notebooks, I think we can increase the left margin increment (the app I’ve checked have more space, which makes it clearer), and use a right arrow/down arrow for collapsed/expanded state, which will be more discreet than the current +/- but still clear enough.


We could probably have a compromise, we could add css classes based on depth and one for the selected notebook. This gives even more power to the user CSS, the only drawback is that we would need some extra code.

1 Like

+1 for option M

1 Like

+1 for I option, as this option is more user friendly and user will not get confuse which notebook he is in
and I think it will much better if you make the lines more light

For people to recreate the existing look with userstyle.css we will need both a .selected class and a .notebook-level-[x] class added. Right now you cannot tell what level a notebook is with CSS only since it is only being applied visually with inline styles.

Regardless, I vote no background, except for a selected state, with > v symbols on the left. (aka option M + a selected state). With this option, I think it will also look better to move the symbols for “tags” and “notebooks” the left as well.

Here’s a quick mockup:

1 Like

I would prefer the icons of “Notebooks” and “Tags” in @uxamanda’s design to have the same brightness as the text (#5F5F5F), for two reasons:

  • To visually unindent them
  • These icons are not controls (in fact, the entire line is currently a control, but that could be changed)

And wouldn’t it be more logical to indent “All notes” including its icon and to make that icon brighter as well, so that it aligns “Notebooks” and “Tags” and their icons?

That all makes sense to me. Sadly I mocked it up by editing in the dev tools so it is hard to recreate and show with your fixes, but I agree with all of your edits.

Yes that would be a good compromise, and not too hard to implement.

1 Like