Better customization of existing features

[rodrigoalexandrecosta]

There are a lot of things that we got used to do through css and scripts to create custom stuff on top of existing features. Some of these customization are individual and adapted to our individual and specific use case, which means that they could not be immediately useful for others.

On the other hand, there are some customization that definitely could be useful and create better experience for users in general. Some of then even were delivered as plugins, while they could easily be implemented in the application to work right out of the box. Some good examples are the Breadcrumbs plugin, the Left Panel Auto Zoom plugin, the Strikethrough Checked Checkboxes snippet, and even the Collection Views plugin to some extent, not to mention the several css snippets to customize the UI.

I'm not only talking about existing plugins, but also existing features on the application that could be more open to customization. And by that, I don't mean to create more snippets and plugins, but actually include these customization organically in the app through the Options menu, giving users the ability to change functionality on their own. The examples that I'll give are based on existing plugins/scripts/snippets, but perhaps we could think of other things as well:

• remove children's attributes from parent note listing
• show backlinks with note links only (without content)
• show vertical lines following indentation in the note tree
• show edited notes as list in today's note
• show existing day notes in the calendar
• strikethrough checked checkboxes
• insert emojis in the note's title and note's content
• hide/show nested lists in general
• be able to select specific width for individual notes
• create backlinks to notes that doesn't exist yet
• have access to more dynamic data to use in templates, note titles and note contents

I understand that some of these things were deliberately avoided by @zadam in order to keep changes to CKEditor to a minimum. I completely understand that reason and I'm also sympathetic with the idea of not customizing dependencies too much in order to reduce time spent dealing with maintainability hell. But at the same time, this could limit the overall “customizability” of the provided features. Some ideas here could be:

• firstly, understand if we're going on with CKEditor at all or other text editor solution;
• propose and implement changes directly in/with CKEditor's team (if possible) in order to reduce direct changes from our side;
• understand if the CKEditor's rolling plugin system could be used from the app, giving the users the possibility to install plugins directly into the editor;
  • if that's the case, perhaps we could create our own plugins;
• offer more CKEditor features through the app, for instance letting the user chose which kind of editor bar to use (balloon, fixed, etc.).

These points also could be extended to the Fancy Tree dependency as well. My point overall is that we could offer more options out of the box instead of depending on external solutions, specially when we don't have decided on a plugin system yet.

What you guys think?

[zerebos]

I can't say much about your specific examples, but I do agree trilium-next can and should allow for better and more user friendly customization. I think Trilium unfortunately had an over-reliance on things like attributes when some things would have worked better as a UI with more options.

[root-hal9000]

Yeah, Trilium has an interesting balance with making it so open for customization while trying to deliver some of those options out of the box via the example project. But I do lean towards closely integrating some things that seem just universally useful as features. But again, as @rodrigoalexandrecosta said, it's a matter of whether we are sticking with the editor. Thanks for listing those - i was not aware of all of them