mobile UI improvements / mobile version

[meichthys]

zadam/trilium#856
zadam/trilium#2953
zadam/trilium#4424
zadam/trilium#3641
zadam/trilium#692
zadam/trilium#1170
zadam/trilium#1186
zadam/trilium#3194
zadam/trilium#4335
zadam/trilium#4741
#462

[Byteingpython]

Imo the bad mobile UI is the worst thing about Trilium

[meichthys]

It indeed needs a lot of work. There are plans to improve this relatively soon.

[meichthys]

As mentioned in #462, Note attributes are not currently visible in the mobile view.

[HyperCriSiS]

Maybe someone can help this guy, he made a very well start for an Android Trilium app:

https://github.com/FliegendeWurst/TriliumDroid

[meichthys]

Wow, it looks like a lot of progress had been made there!
I'm not sure how I hadn't seen this before. Thanks for sharing.
It looks like development stopped on this around the same time when zadam/trilium was slowing down. Perhaps if the dev knew about TriliumNext, there would be renewed interest in maintaining/improving it.

[eliandoran]

Wow, it looks like a lot of progress had been made there! I'm not sure how I hadn't seen this before. Thanks for sharing. It looks like development stopped on this around the same time when zadam/trilium was slowing down. Perhaps if the dev knew about TriliumNext, there would be renewed interest in maintaining/improving it.

@meichthys , @FliegendeWurst is a buddy of mine on the NixOS side, where he is the maintainer of Trilium Notes and also recently helped me with the packaging of TriliumNext (NixOS/nixpkgs#356930) so they are aware of it. @FliegendeWurst, maybe you haven't had the time or have lost interest?

[FliegendeWurst]

The app got to the proof of concept stage before I hit some trouble.

1. Difficult to keep up with the sync protocol and database schema changes
2. Scripting API very difficult to implement
3. No good ideas for UI around labels/relations
4. Performance wasn't perfect either (maybe 1s to switch notes)

I think it could become a real thing if we find at least 1-2 more Android devs.

For point 1, it would be really nice to have the sync protocol documented somewhere. The database is usually easy enough to figure out.

[FliegendeWurst]

I have updated my app to support TriliumNext's sync protocol, though I didn't actually have to do any code changes...
Meaning you can now download the app (https://github.com/FliegendeWurst/TriliumDroid/releases/latest) and try it out.

[meichthys]

Wow. This is like an early Christmas present! Just being able to quickly pull up a note is a big deal for me.

[jacksgt]

This is super exciting! Maybe a link to the TriliumDroid repo can be added to the main README to give it a bit more exposure and attract some other Android devs?

https://github.com/TriliumNext/Notes/blob/develop/README.md#mobile

[skellyatsnhu]

The experience on iOS and iPadOS is especially rocky right now.

A few random thoughts:

-Sidebar is only consistently visible in landscape mode
-No access to context/formatting menus (no right click equivalent / no UI button equivalents in mobile mode)
-No tabs in portrait mode
-Cursor often outruns the screen
-Keyboard may come up (or not come up) at the wrong times
-Can't do a lot of management of notes due missing menus/sidebar being inconsistent

I really hope this improves someday. Trilium is pretty powerful and incredible on the desktop, but it's absolutely suffering on mobile.

[meichthys]

@skellyatsnhu Can you confirm what version you are running? There have been some significant improvements in the most recent beta versions. So, feel free to check those out if you haven't already.

[skellyatsnhu]

@skellyatsnhu Can you confirm what version you are running? There have been some significant improvements in the most recent beta versions. So, feel free to check those out if you haven't already.

Docker tag triliumnext/notes:latest that is updated daily with watchtower. Version 0.90.12 Build date: 2024-09-07T18:36:34Z.

What improvements were made here? I'm still not seeing a great mobile experience at all, it's the same issues it's always had.

[meichthys]

latest doesn't include beta versions.

Enabling the fixed format bar in the options IMO improves the mobile version significantly since the formatting bar has a horizontal scroll to easily access all formatting options.

Here's the new look:


[skellyatsnhu]

Gotcha. So just highlighting it's still reasonable to state that the main version does not have this.

Generally I don't use betas, especially Trilium betas, due to prior issues where new versions frequently broke everything.

Looking forward to when this reaches prod.

[meichthys]

Yes, correct. only beta versions have these changes so far. the next stable shouldn't be too far out.

Also, if you only need read-only access on android, you could try the TriliumDroid apk.

[herrkami]

First, thanks for all the great work! Trilium is improving well and fast these days thanks to all your efforts. :)

I'd like to report some issues that I encountered with the most recent mobile UI changes in 0.91.5. Some of them may be a matter of personal taste perhaps, others are probably actual issues. Please regard them as suggestions, not as critique.

1. The Launcher Pane is missing. (I need it :) )
2. The tab bar is there but I cannot change tabs. Closing and long pressing x-menu works but clicking a non-focused tab does nothing.
3. The Insert Child/Delete Note menu cannot be closed without inserting a note or reloading the page. (Very annoying if you misclick.)
4. The text editing menu is sometimes placed incorrectly somewhere in the middle of the view. Scrolling and moving the cursor helps sometimes. (But perhaps that's just me?)

Moreover, here are some thoughts/suggestions about the previous and current UX in general. Perhaps, you find them inspiring for future changes.

1. The menu to open the Note Tree needs to be accessed quite frequently and, hence, should be easy to reach. Yet, it is currently located at the top left of the screen, which is pretty much the furthest spot to reach, especially for the right-handed.
2. The main menu is located at the bottom right, i.e., the easiest spot to reach for most people. However, I rarely access this menu. It would be nice to have this swapped with the main menu, location-wise, imo.
3. The note navigation menu (previous, next, new) takes up a lot of vertical space at the bottom of the page. Personally, I don't need those buttons at all because I navigate backward/forward with the browser and the +-button is redundant to the +-button in the tab bar just a few pixels above.
4. The Insert Child/Delete Note menu has always appeared weird to me in many ways: It only contains two items, and could, hence, be replaced by two little buttons, wasting negligible additional space there. Alternatively, it should be a proper menu, containing more than two items. E.g. an option to set the note type, edit attributes, etc.
5. This brings me to my greatest personal pain point with the mobile UI. Afaik, the only way to specify the type of a new note is to create it via long press from the Note Tree menu. Moreover, it is impossible to change the type of an existing note without switching to desktop view. Same for note attributes. Therefore, I'd love to have the regular note options (Properties, Attributes, etc.) available either within the Insert Child/Delete Note menu or in a ribbon, similar to the desktop view. This ribbon could, e.g, appear where the note navigation bar currently is.

[eliandoran]

@herrkami ,

The Launcher Pane is missing. (I need it :) )

The launcher pane is not actually missing, it's at the bottom. The only problem is that it's currently a bit underdeveloped. I made the decision to split the launcher panes of the mobile from the desktop since it doesn't make sense to keep dozens of icons on a small screen. This would also allow a user to select different icons based on their needs.

As stated in the release note:

The mobile view now has its own launch bar configuration with its own launch bar buttons. For now only a few have been enabled. Feel free to request any button from the desktop should you require it.

What do you need from the launcher pane, more specifically? Bookmarks, calendar, new note, etc.

---

The tab bar is there but I cannot change tabs. Closing and long pressing x-menu works but clicking a non-focused tab does nothing.

I've noticed something similar too, I'll have a look some time in the future

Do note that the tab might be focused already but the state of the tab bar is not yet synced due to some weird issue. I've noted this in 0.91.3-beta but forgot to add it to the stable as well:

On mobile, opening in a new tab activates the new tab but does not refresh the tab bar.

---

The Insert Child/Delete Note menu cannot be closed without inserting a note or reloading the page. (Very annoying if you misclick.)

Feel free to open an issue for it.

---

The text editing menu is sometimes placed incorrectly somewhere in the middle of the view. Scrolling and moving the cursor helps sometimes. (But perhaps that's just me?)

The formatting bar is really annoying to position, I suppose it depends on which browser you are using. On iOS as a PWA I think it works best, on Android the browsers are sometimes annoying.

The menu to open the Note Tree needs to be accessed quite frequently and, hence, should be easy to reach. > Yet, it is currently located at the top left of the screen, which is pretty much the furthest spot to reach, especially for the right-handed.

If you use a PWA, the tree can also be swiped upon. Unfortunately due to browser differences sometimes this turns into a back gesture that I cannot seem to bypass for now.

As per the release note:

The sidebar can also be triggered by swiping to the right on the left side of the screen. Still some quirks to address on both iOS and Android due to their weird back button gesture.

---

The main menu is located at the bottom right, i.e., the easiest spot to reach for most people. However, I rarely access this menu. It would be nice to have this swapped with the main menu, location-wise, imo.

You probably meant it to swap it with either the tree menu (top-left) or context menu (top-right). For the top-left side it would be weird. From a UX perspective, it would not really make sense to have the global menu at the top, to be honest.

---

The note navigation menu (previous, next, new) takes up a lot of vertical space at the bottom of the page. > Personally, I don't need those buttons at all because I navigate backward/forward with the browser and the +-button is redundant to the +-button in the tab bar just a few pixels above.

The note navigation menu is actually the launch bar you mentioned at the beginning. It used to be on the left side of the screen, taking valuable width, so it made sense to move it at the bottom (quite similar to Obsidian).

All the buttons here are removable, since the mobile launch bar is configurable, but you'd just end up with empty space unless we add more features. The "Jump to note" feature is slightly different from adding a new tab since it operates on the current note (e.g. Ctrl+J on the desktop instead of Ctrl+T). Do note that the tabs in this form will not exist forever and it will be redesigned into a mobile-like tab experience (dedicated button to show the tabs and perhaps a swipe gesture), so the new tab button will no longer exist in time.

---

The Insert Child/Delete Note menu has always appeared weird to me in many ways: It only contains two items, and could, hence, be replaced by two little buttons, wasting negligible additional space there. Alternatively, it should be a proper menu, containing more than two items. E.g. an option to set the note type, edit attributes, etc.

Yeah, it's weird. We shouldn't replace it with more buttons as we don't want to clutter the UI, instead populating it with more options is a good idea. Ideas are welcome.

---

This brings me to my greatest personal pain point with the mobile UI. Afaik, the only way to specify the type of a new note is to create it via long press from the Note Tree menu. Moreover, it is impossible to change the type of an existing note without switching to desktop view. Same for note attributes. Therefore, I'd love to have the regular note options (Properties, Attributes, etc.) available either within the Insert Child/Delete Note menu or in a ribbon, similar to the desktop view. This ribbon could, e.g, appear where the note navigation bar currently is.

Feel free to open an issue. Mocks or ideas on mobile design are welcome.

[herrkami]

Hey @eliandoran,

Thanks for your comprehensive replies. Of course, I missed that in the release note, my apologies. Most is resolved then.

Concerning the Launcher Pane, there existed a neat solution in the Lightpad theme. The pane was horizontal with scroll overflow. For me that worked flawlessly. With the separate configuration for mobile, it would now even be possible to have different orders and selection of items which sounds amazing.

What do you need from the launcher pane, more specifically? Bookmarks, calendar, new note, etc.

Everything that the desktop launcher pane offers. E. g., I have three custom Trilium apps that I access via Bookmarks from the launcher pane, plus some notes, schedules, etc. that I access frequently. I also have a script that acts as a bright/dark theme switch. I need all of those in the mobile launcher as well and I wouldn't like to create/configure all of them twice for the desktop and mobile version each time tbh.

You probably meant it to swap it with either the tree menu (top-left) or context menu (top-right). For the top-left side it would be weird. From a UX perspective, it would not really make sense to have the global menu at the top, to be honest.

This is certainly a matter of taste. But let me point out that most of my apps have it on the top actually. Among them all Google apps, Spotify, PayPal, banking apps... To me it makes total sense to have the buttons sorted from bottom to top ranked by the respective access frequency. I don't have hard feeling about the main menu button but the tree button really needs to come down to the bottom (right) imo, especially if the swipe gesture does not work on many devices.

Do note that the tabs in this form will not exist forever and it will be redesigned into a mobile-like tab experience (dedicated button to show the tabs and perhaps a swipe gesture), so the new tab button will no longer exist in time.

That sounds awesome. :) However, I'd like to share my concerns on swipe gestures. As far as I know, those are notoriously hard to get right and to maintain over various platforms, browsers and devices. I know there are libraries out there but even with those you can create conflicts with existing system or browser gestures etc. if you're not simultaneously aware of all platforms. I would strongly advise to keep them out of or at least entirely optional in a project like this because it would require the respective developers to have access to all of the desired devices to get it right and not accidentally ruin the experience for a significant share of the user community. If it's still your decision, then please also provide an option to turn them off or deliver them as a Frontend code note or so. (I defined some swipe gestures to indent/undent and move up/down list items in text notes. Works great.)

I will think a little more about the Child/Delete Note menu and open an issue. Thank you!!

[eclairevoyant]

The text editing menu is sometimes placed incorrectly somewhere in the middle of the view. Scrolling and moving the cursor helps sometimes. (But perhaps that's just me?)

The formatting bar is really annoying to position, I suppose it depends on which browser you are using. On iOS as a PWA I think it works best, on Android the browsers are sometimes annoying.

On Chrome (android), I observed the following:

In floating mode, the formatting bar does float, but it doesn't follow the cursor if I move to another line. And it also covers up existing lines, so the two lines below it aren't accessible at all.
In fixed mode, the formatting bar gets cut off by the on-screen keyboard.

Besides, wouldn't fixing the formatting bar to the top of the screen make more sense than fixing to the bottom?

(EDIT: on that note, viewing the browser in desktop mode via "Switch to desktop mode" seems to be far more usable- in landscape mode only, though. Formatting bar in fixed mode is pinned to the top as hoped, and the entire note is accessible. In portrait mode, though, the 3-column layout is too cramped.)