-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
App navigation is confusing #364
Comments
Ok, so you cannot from the app. And like said in 2: Now, let's find solutions. So you have:
But to be fair it looks good on Mail but mail rarely have more than 2 depth nested folders. You on the other hand, allows unlimited ones. So I would say the whole ui is not clear. You're stating that folders are "categories", but it means you're only allowing one category? Are the parent folders supposed to be categories as well? How do you see your categories being different from tags for example? I would like to understand how you see this? What is your vision :) |
To be honest, I always preferred it to be a simple note list sorted by most recently edited and nothing more. ;) But I have to say it’s not as confusing as you say:
|
I'd suggest we adopt a similar layout to contacts and mail to solve this. Apple notes uses it and It's one of the best notes app I've ever used. Plus we already have the UI :) |
I think the two-tier structure is a good idea! An issue is see with this, though, is nesting folders/categories in the sidebar. I went with a similar approach in the bookmarks app last year and it turned out to be a bad idea. (@skjnldsv already knew it back then; I've since seen the error of my ways 😄) |
For the appnavigation nesting, we could also try to improve there for the vue components and start increasing the width of it (allowing for more than one nested level) |
For me personally, it would be enough. but the UI is based on the files folder structure, so we'd need to think about what happens when the file system folders are nested more deeply. |
So this 3-column view of course would work, but to be honest the initial intention of Notes was to be able to focus on Notes, and suddenly then it’s mostly organization. That said, I mostly use the Android app these days and don’t use categorization anyway, so I’m fine with someone else taking over the design – like you @ma12-co :) As long as you use something like Apple Notes as design benchmark it should be good. 👍 |
I also think that a three column based layout is a heavy overkill. the design gial of this app was always to be simple. For more organizational stuff a solution like nextnotes, onlyoffice or some other suite in combination with the normal files app might fit better. just my 2 ct |
I understand the concerns, however I'd like to stress that the layout would default as 2 column, one with just notes (no categories) and another with the note editor. The categories and settings column would be for more advanced users only and accessing it would require expanding the sidebar. |
I am aware that the android app is already doing this. There is a flow from master to detail because there is only one screen displayed at a time. this is done to show as less information as possible at a time to give a user a quick overview. on the desktop the scenario is different: if we use 3 columns here, very much information is displayed at the same time - all this has to be scanned by the user before he can start to actual edit. |
Then we have to think about how it is cross-application though, and about the default. Because people rarely change the default, and if the navigation is shown then it is very complex in this case. But not showing it for other apps like Files or Calendar would not be good since it displays essential data. So basically, I think displaying non-essential (or secondary) data in an element that so far has always displayed essential data would lead to confusion and/or us messing with the design in a way that we can not really estimate the impact of. With Nextcloud we aim to be really really simple and easy to use, and that’s why lots of people prefer using it. Compare e.g. to Simplenote which is a great example of simple but powerful note taking. The 3-column layout is already a bit of an issue with Contacts and Mail, as it leaves little space for the content if you don’t have a huge screen (which many people don’t), and the reason is mostly that historically Mail apps have been this way, and because the sections in Mail are more important and distinct than just categories. For Contacts and Notes e.g. what we could instead think about is putting the list of Notes / Contacts in the app-navigation, and then having an extra dropdown-like element on the top of the app-navigation which by default says "All groups" / "All categories" and you can filter or create groups/categories there. And this would not add a whole nother column for a rather rarely used component, and would keep the core experience simple. |
Thank you all for sharing your thoughts and for a critical review on the notes app. I think this is a very good process in order to improve the usability of the app. First of all I want to answer some questions:
You have to open the sidebar by clicking the three-dot menu in the upper-right corner and chose "Details". There, you can change the category and use
Indeed, this should be improved.
One goal of the app was to have all relevant data in the file system, so you can import/export all data in an easy way and even sync your notes with a system where you edit them with a generic text editor. Due to this, we've chosen a folder-based category system. This means:
It's there to differ between category selector (above) and notes list (below). But we can remove it or visualize using other styles. @ma12-co
We can't prevent users from creating deep-level categories, so we need to handle such notes. But there is no need for a full hierarchical navigation through all levels. I think navigating through the first (or first two) level is sufficient. Deeper levels should be composited like it's already done:
IdeasThree-column view@ma12-co proposes to separate notes and categories, which means that there will be three columns: categories list, notes list, note editor. I like this approach for it's clearness, but we didn't chose it because it's against the vision to focus on notes. Drop-down in app-navigation@jancborchardt proposes to introduce an extra dropdown-like element on the top of the app-navigation. I like this very much, since it respects the app's vision in a good way. |
Thanks for taking the time to help us understand! 🤗 So what do we decide?
|
Why not? I think that we can and should determine how much nesting we want allow here. The concept itself of category nesting is confusing and certainly doesn't help if the goal is to make this app simple and straightforward. Most 'simple' note apps don't have subcategories.
I just don't get why we should feel the responsibility to display in the notes app a text file that is very deeply nested in the filesystem.
I get this, and I think it's very nice to have it. But in my opinion we should introduce some rules about what you can do in files if you want things to be displayed in notes. In this sense there are already some boundaries in place in the current app, for example you cannot place a We could go a bit beyond that and say something like: if you want your folder names to be displayed as category names, you have to create these folder at root level in the notes folder Hope I made my point clear :) |
Because it's using the folder where the user put the notes, we can't forbid the user to create subfolders :) |
We can't forbid it but we sure can ignore them in the notes app! Maybe I didn't do the best editing on my previous post. The reasoning behind what I'm saying is towards the end of it. Only advanced users will modify the folder structure and edit these files with something other than the web and mobile notes apps. So since they're advanced we can ask them to comply with a couple of simple rules if they want their changes to be displayed in the notes app. |
Yes, let's do it. This is better! 👍
I'm not sure if I understand this correctly, but we are already merging levels greater than 2 (see screenshots:
Because we are nice guys 😄 Here is an update of the situation with some more realistic notes: |
It is a mystery to me why it should be completely sufficient to make the app really navigable in the UI with only 2 nested folders. For me, the app is unfortunately not really usable. I have to switch to Joplin, which offers the perfect UI several levels deep. That is a pity. For shopping list, todos, etc. completely sufficient, I agree with you. But I use md-files as a kind of wiki and knowledge base for my business. And there are many different categories that can not be limited to 2 levels, otherwise it is too confusing. Other wiki solutions are too bulky, Nextcloud Notes would be sufficient, only the display from the 2nd level is too confusing for me with my large number of folders and subfolders. That's just my opinion on the subject. Nevertheless, thank you for your work. I know it's not easy to do justice to everyone, it's even impossible. |
@handkerchief333 if the indentation is really the only issue, then we could also indent it for deeper levels. A lot of things changed since the issue was opened, the nav width is adjustable etc. How many levels do you use? And @korelstar what do you think? |
@jancborchardt Thank you very much for your message. Yes, it's indeed the only issue. I have checked it, I use maximum 4 levels. But depending on the need, it could probably be 5, but no more than that. That would be really great, then I could do without joplin and use nextcloud notes directly instead of doing the same thing in a roundabout way. |
@jancborchardt Are there any news? It would be a pity that nothing works now because someone has not answered for a long time, possibly months. If I can be of any help, please let me know. And thanks again for your fast and optimistic answer. |
Some issues:
../
means, app navigation should not evolve regarding on what you click. This is not supposed to be a hierarchy browsing area.@korelstar @jancborchardt
The text was updated successfully, but these errors were encountered: