Replies: 5 comments 5 replies
-
|
I took a bit to think about the proposed ideas before replying, while I like the ideas, if the goal is to be user-friendly, I'm not sure that using custom HTML & CSS is the right way to do it (Although I'm all for having an optional section for it! It doesn't hurt to have options!) I'm all for something more simple to create and manage like using YAML or JSON as seen in @deseven's proposal (link) though since the majority of people who are using docker or are self-hosting are likely familiar with YAML I might be mis-understanding the proposed ideas though, I'm not the most familiar with web development yet 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for sharing your thought!
Don't worry! We are looking more for user than developer input here. |
Beta Was this translation helpful? Give feedback.
-
|
I like option However, since our preferences are already being kept in the sqlite database it might make sense to stay consistent and go the |
Beta Was this translation helpful? Give feedback.
-
|
My thoughts: For general site customization/styling, custom .css, .js, .html need to remain, in one place or another. This allows complete and flexible customization. I don't mind making those files editable inside the app, but a control in the app will always remain much more limited compared to an external editor so I wouldn't make this the required, only way to edit those files. I don't like the idea of storing this in the database. This would make it much more difficult to view and change the files. A big part of why I like Otterwiki is that it doesn't try to store everything in a database like other apps. Flat files on disk are easy to view, edit, compare and keep history. This is important for code files. I guess the files could be moved inside the repository in a .custom directory, but I'm not sure, because it would require a commit every time any single change is made to one of the files, otherwise the repo would be in "non committed" state. When trying things out with css and js, I wouldn't like having to create 40 commits until I'm done. Also that would require manual commits, assuming we allow editing the files directly. For the configuration of the custom menu, it feels less like a "code" customization to me and more like an app setting or "wiki content", so I wouldn't mind it being either in the database, in the repo or a config file. It is pretty much equivalent to changing a table-of-contents.md page that one would create in their wiki. Hope this helps :) |
Beta Was this translation helpful? Give feedback.
-
|
As the author of the proposed #298, I also quite like the (b) option. From the current comments here, it looks to me as if the ability to work with the repository is important. Having a dedicated folder with relevant files is definitely easier and somehow logical in my mind. One question comes to mind: how do I reset those files? Do we store somewhere a default file and replace the modified files with that default one? This is how it worked in my proposal. The default file came with relevant selectors for styling, with comments to help with onboarding. This default file could also just live in the OtterWiki repo, and people could come back here to get it. I have some reservations about YAML and JSON, but if it's crucial, I would definitely prefer YAML, as it is less verbose. |
Beta Was this translation helpful? Give feedback.
-
|
Btw, I would categorize the following types of customizations:
Some can be exposed as simple settings, others might needs more involved changes, such as a custom css file etc. EDIT: remove structure of site in favor of CSS modifications → not a new theme (CMS-like) but tweak the look and feel. |
Beta Was this translation helpful? Give feedback.
-
|
I'm also favoring (b) and I'd go with your idea of having a pre populated css available where users can start tweaking the theme. For the start I would provide an editable custom css. This gives one all the options and nowadays, with LLMs being capable of dealing with a copied blob and a prompt that asks for tweaks, this enables everyone to tweak their theme. Providing settings that configure the theme is more something i would expect from a full flavored CMS, and this is not what An Otter Wiki tries to be. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, what I initially wanted is to be able to tweak the CSS. I'm not interested in having access to actual page structure changes. I like the structure of An Otter Wiki. edited my comment above And having a css file means that editing via git is possible instead of via settings that would lack granularity of direct css. |
Beta Was this translation helpful? Give feedback.
-
|
@redimp I've taken another look at this and realized that while it would be nice to have additional css customization (and I'm all for it), I feel like some simple extra options for the current menu system could be added For the specific issue I had, it could be solved by just adding the ability to add a piece of text in the custom menus with markdown formatting and/or the ability to make this from the image below into a tree format 
like this: Unless I'm missing something, I don't think this would be too hard as you wouldn't need to deal with any conflicts between the custom menus and the normal ones anymore than you currently have to (although I could be wrong! Please correct me if so! :D). I of course don't know any of the codebase so this is probably more work than I'm making it sound though 🤣 I think this would go well with what @hollisticated-horse said with the categories Sorry if none of what I said makes sense, I'm having a hard time trying to word this correctly 😭 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing your thoughts and taking another look at this! I can definitely follow your reasoning: Having a tree-style menu structure and markdown support in custom menus would cover a lot of use cases without the complexity of full CSS customization. I'll keep this in mind when working on the sidebar/menu improvements. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've been thinking about how to make CSS, sidebar, HTML
<head>, and<body>customization more user-friendly. This idea was sparked by @deseven's proposal here, which introduced a customizable menu.In pull request #298, a page is used as an editable source for custom CSS. While I'm hesitant about the complexity of managing a dedicated page for this, the core idea is awesome.
Here are some proposed approaches:
custom.css,customHead.html,customBody.html, andmenu.yamldirectly within the repository, as attachments to "Home" .. in the folderHome/. This would enable editable attachments and unlock significant future features..customfolder in the repository containing the same files. Users could then edit these files through a new "Settings > Customize" section.custom.css,customHead.html,customBody.html, andmenu.yamlas blobs within the SQLite database, accessible via "Settings > Customize."All of these options would require enhancements to the editor functionality.
What are your thoughts on these approaches?
Beta Was this translation helpful? Give feedback.
All reactions