I see, why this change was done, however I don't really like the implementation. I always liked a relatively narrow note list, but with this change it doesn't look very good then. Why not do it a little bit more responsive:
if the width of the note list is >235 px: display the buttons as they are right now
192 px < width < 235 px: remove the "New" in each button and change the buttons min-width to 71px. The plus implies the "New" in my opinion.
if its even narrower, maybe remove the text completely, switch to the old icons and thus make the buttons even smaller
I just don't like it, when UI elements overflow when you shrink an element down. In my opinion either it should act accordingly and scale down the element somehow, or it should not be possible to shrink the note list further.
The search bar also scales accordingly, which makes the buttons appear a little bit "dumb"...
Any thoughts on this?
Another small thing: If the sort order button is disabled, the padding of the two rows doesn't match on the right side (I didn't want to file an issue instantly, as the points above need to be discussed in my opinion).
There is also another case where the note list gets very wide. I think it would be nice if the buttons had some kind of maximum width set and then once there is enough space, all four elements re-arranged themselves into a single line. Otherwise, the buttons now only get super-wide, which doesn't really help with anything, while also taking precious vertical space.
This is how the situation looks currently. The first problem happens once the note list width becomes narrower than 240 (as defined in settings.json).
On the other hand, below are the super-wide buttons. There is more than enough space to put everything in the same line.
Yeah, as I said, I see why the change was made, it also does look good in my opinion, but only while the note list is wide enough.
No, 40 px is maybe the width of one button then. Both would probably add up to about 90 px.
90 px is very small indeed, but I think the question should rather be if one needs the list smaller than 192 px. And to that question I would give my absolute yes, this can definitely happen sometimes.
My last checkpoint was only a thought, as I don't know, how to shrink the button size even further without going back to the old icons. I think this would be a way to address the problem. I would then set the width of those two buttons to the minimum possible, thus restricting further shrinking.
Even though I personally don't need it, I really like this idea. It would be like in Firefox with the search bar consuming most of the width. For the people that set the note list to the top of the application (over the editor) this would mean space saving, as there isn't that much of it.
As long as there is a classname so that we can use css to change those buttons, all is good.
Personally I do not understand how someone could not know how to create a new note/todo:
it was explained in the documentation afaik
there are menu items called New note and New to-do with keyboard shortcuts
the buttons, which are at the top of the list of notes/todos - duh, also have tooltips
Sorry to be blunt, but how the heck is it possible not to figure out how to create a new note? Maybe someone who couldn't figure it out can explain their thought process to me. Maybe I can understand it then.
I am sorry, my dad is over 70 and he is not a computer expert. Yet he knows that there are menus and that icons are often related to the elements in their vicinity or to the pictographs these icons show.
A problem that really bothers me:
When you click the search box, it will jump from the current position to the position of the previous line.
The problem is that when you double-click the search box to select all the contents, there are often errors due to the change of the location of the search box I hope you can restore the old style.
I can confirm the search bar issue. When the buttons and the bar were located in the same row, it made sense for the buttons to temporarily disappear when being focused on the bar in order to provide more space for search strings. However, with the two elements located in different rows now, there doesn't seem to be any reason to hide the buttons anymore…
I am sorry to bring this up again, but I find it unfair that the mojority of users have to suffer because of a few people who can't seem to figure out how to create a new note.
Let's add another FAQ entry or make the docs better. The new UI flow is worse than before and now as a long time user I only have the choice to get rid of the buttons completely, which also mean I can't use these buttons anymore.
I also liked the UI design where the search field expanded to the full width. It looked very professional. Now I feel like in kindergarden where kids run around with plastic phones that have huge buttons.
Doesn't this somewhat prove the original argument though? If there are people who need instructions on how to create notes in a note taking application, then clearly something is wrong... If this was some kind of advanced functionality, sure, but we're literally talking about the main function of the program here .
Nope, I don't think this is the case. I have no idea how many people are using Joplin, but how many tickets/issues/topics where created in that regard? Even if there were like 100 reports who couldn't figure it out, what percentage is that? 0.01% or 0.1%.
Either way, that percentage does not warrant that all other users have to live with this degraded UI experience. And it currently certainly is a degraded experience.
Well, it's really all in the eye of the beholder at this point. I can say that the new buttons are a clear improvement and a much better experience for one my family members (who had major problems remembering and navigating the old ones).
In that case we should create a separate UI (via an option or a theme-plugin) for people who can't remember 2 buttons. I am sorry, as I mentioned before, I don't think this is fair to the rest (which is the majority) of the users.
For those 0.1% the UI might be better, but for 99.9% of the users it is worse. You still want 99.9% of the users to live with this?