Unify and standardise the core UI

I feel like the core UI could be more unified across devices, and more in line with standard conventions. Ultimately, I really want to stay in the flow when using your app no matter which device I’m on. Here’s my suggestion:

  • Expand/collapse icon on the left in both desktop and mobile. Expand/collapse buttons are always on the left in other applications and operating systems. I find this pretty disorientating on the mobile app.
  • Zoom button in same place on desktop and mobile, preferably on the right to avoid misclicks.
  • Context menu on right click instead of its own button. Prevents misclicks and also gives quicker and easier access to the menu. Context menus have long been on right-click for good reason, it’s better to click on the context than it is to find a button near the context and then click on it. Google Drive does it this way. The browser’s default context menu can still be accessed with shift-rclick.

If you’re worried about changing things perhaps you could implement these as an option in the settings, or have an option to return to the legacy interface?

Thanks for reading.


I agree strongly with all of these. Especially, I want bullet = expand/collapse in mobile (and desktop, but that’s already a thing), and zoom on the right, because it’s a pain having zoom where you’re trying to set the cursor.

I like the context menu idea also, and wish it to work regardless of whether the cursor is active or not.

@Alan, glad to get some support for this, thanks. What do you mean when you say whether the cursor is active or not? Do you mean things like long press on Android?

No i mean in Windows. Context menu doesn’t exist in mobile, instead there’s a bar at the bottom.

Go to dynalist.io in android chrome, and in the corner select View in Desktop mode, and adjust the zoom out to make sure it switches to desktop UI. Try to do stuff and list the difficulties. Now go on a laptop and resize your browser tall and narrow until it switches to mobile UI and zoom in a bit. List the difficulties working like that. Constant mistakes and inefficieny.

The first prototype of dynalist was a unified UI, they put in work to split it for good reasons. I would recommend not doing editing work in any app on mobile. Mobile is good for jotting things down on the go when nothing better is there. That and drawing with a stylus. It will never be better than a laptop for edit work. This applies to all apps across the board.

It’s a balance, two sides of a scale, to optimize productivity, with the mental annoyance of 2 vs 1 paradigms to get used to, vs the constant mistakes and inefficieny caused by not differentiating to accommodate fat thumbs fumbling around vs a mouse editing on a 4K monitor. It’s pretty much an industry norm called “responsive web design” to not unify UIs between desktop and mobile, so you’re up against that industry wide trend, which doesn’t seem to be losing steam despite the fortune 500 research budgets.

So you’re asking for a lot of regression for reasons that arent good reasons imo (unifying and standardizing just for the sake of unifying and standardizing). Maybe go at it from a different perspective and make little suggestions that will improve the average users productivity if measured scientifically.

Yes there are reasons to have differences between mobile and desktop. Nobody is calling to get rid of those. But the three suggestions, all of them would be improved by the change proposed.

1 Like

@BigChungus I agree that it’s very sensible to avoid a goal of complete unification and I agree that responsive design is incredibly important, but I don’t think what I’m suggesting goes against the grain here. I have three distinct suggestions to bring the core Dynalist UI in line with UX conventions. I’d love to understand the specifics about the opinion you’re expressing in relation to my request:

  1. Is your opinion that it’s better to have expand/collapse on the right? If so, why?
  2. Do you see a problem with having the zoom button in the same place on all platforms? If so, what is it?
  3. Are you against having a standard right-click context menu on desktop instead of a button near the context? What’s your thinking?

@Alan Gotcha, I’m happy to edit the original post if it could be expanded upon, but I’m not sure I understand totally, I’d like to get a handle on what you mean by “whether the cursor is active or not”, can you explain? Or perhaps post a screenshot or GIF?

I simply mean, like is normal in all applications, if I click the right mouse button, the program looks at the mouse position and gives the proper context menu. This has nothing to do with whether or not a cursor is blinking nor where that cursor is. The context menu is for the mouse position if the mouse invoked it. If there is a selection active, typically it applies to that selection.

(This may vary if you press the keyboard context menu button.)

  1. & 2 seem to be the same question. It’s too hard for fat thumbs to hit zoom vs expand in desktop mode because they are right next to each other. I just assumed the obvious fix was to arbitrarily move one to the opposite side for mobile.

  2. I guess you could. But you’re disabling the browser’s context menu for what benefit? I don’t think there is a hotkey to do exactly what right click -> Inspect does in Chrome, which is vital for writing Custom CSS. Also, many Chrome extensions for manipulating hightlighted text dont have hotkeys and are accessed via the browser context menu (the extension adds options to it). Since I never use the Dynalist context menu (thanks to custom hotkeys), and frequently use the browser context menu, I don’t see a benefit. I may be bias since I used custom CSS to hide the context menu icon and all the other UI I don’t use tho.

F12 is your hotkey. Then click the inspect button.

Ah cool, it highlights it too, never noticed that button, thanks.

@Alan right, I understand, and strongly agree!


  1. Aha, I think this is just a matter of me making my suggestion clearer. I’m saying zoom could move to the right and expand/collapse take the conventional position of being on the left - and that this could be consistent on both desktop and mobile.

You can always access the browser context menu by shift+right click. Try it in Google Drive if you have it, or another site with custom context menus. There could even be a hint in the context menu to use shift-rclick if desired. The benefit as I see it would be:

a. Right click on the thing.


b. Remember to not right click on the thing like in other apps that require a context menu, instead remember there’s a hidden button and aim carefully (don’t click the zoom button by accident!!), then click to edit the nearby thing.

It might seem really minor, but when doing this 1000 times you really feel the difference. Since it takes you out of the flow instead of being “one with the interface”, it’s something I think can be improved upon.

Ahhhhh, it is becoming clearer

I support both those ideas

For those interested we can get the context menu to trigger on right click with this Tampermonkey script. Enjoy!

// ==UserScript==
// @name         Dynalist Context Menu on Right Click
// @namespace    http://tampermonkey.net/
// @version      0.1.1
// @description  Summon the context menu for a node simply by right clicking on it. You can suppress this behaviour by holding shift then right clicking. Thanks to Shida for making it work :)
// @author       Adrian
// @match        https://dynalist.io/*
// @icon         https://www.google.com/s2/favicons?domain=dynalist.io
// @grant        none
// ==/UserScript==

(function() {
    'use strict';
    $(document).on('contextmenu', '.Node-self', function(e) {
        if (e.originalEvent && !e.originalEvent.target.classList.contains('Node-bullet')) {
            // Open default browser menu instead if:
            // - shift is held down.
            // - right clicking on selected text.
            if (!e.shiftKey && window.getSelection().toString() === '') {

1 Like