There has been various discussion of this over the years, but I think it’s time to have a proper feature request for this: a built-in “native” custom CSS function and (basic) editor that can adjust the styling of many aspects of a Fibery workspace. An excellent example of this kind of thing is in Discourse (this forum) itself.
I can think of a number of optional features that would be great, like per-user or per Space CSS that admins could adjust, but that may be getting well into overkill territory. Just a Workspace-wide custom CSS would help a lot!
It would also address a number of other feature requests and discussions (and differing opinions on each!), at least until the more important ones can be implemented directly e.g.:
I agree, custom CSS could help admins make the UX more intuitive for users, for example
When embedding other entities using relationships, the header of the relationship view is always visible. Would be nice to hide that using CSS (or a setting).
@Chr1sG Yes to reduce the clutter. In general the user interface needs some UX polishing I think, and could be more configurable (indeed custom css editor could be a good start) to hide elements that are not directly necessary, to prevent the UX tension of visual overload.
I have created Drupal websites for 14 years, mostly to create collaboration platforms. Because the editorial experience of Drupal is still mediocre (ckeditor 5) in comparison to inline editing with tools like Notion and Fibery, I am testing out Fibery because its focus on components fields and relations is very similar, although much simpler, than Drupal. I think that Drupal missed the boat by keeping using php for its front end. Overall, Fibery I find promising while it needs some UX improvements for end users.
Hi,
I remember mentioning this to @Chr1sG some while ago as well. Just adding my vote and some of the simple use cases I can see for allowing admins to override some styles:
While I might not wanna do a full theming, I would love to add a little bit of brand colours to our Fibery to make it feel more ours
My biggest peeve is around spacing and sizing of elements. Therefore I’d want to be able to:
Adjust the colour of heading to make the difference between h1 and h2 and h3 easier to see
Improve the vertical margin between blocks on pages; for example after embeds, but also before headings
Add some breathing space above the different spaces on the left sidebar (like Slack or Notion) to make it easier to navigate
I would think (and hope) that this is actually a rather small UX improvement feature with a lot of upside. Even then allows us to contribute and suggest UI refinement fixes for the Fibery team to consider.
Obviously, custom css would allow sophisticated users to create a more personalized workspace, but probably the biggest drawback is that customer support can become more challenging.
As it is at the moment, the first part of solving a customer problem is to understand what they are experiencing, and typically then to reproduce it.
If every workspace could theoretically look/behave differently (with css implemented) then the job of customer support can quickly become a bit of a nightmare.
@Chr1sG, I understand your concern. But obviously I cannot ask for customer support for things I’ve messed up.
One simple way to solve that would be to have a toggle with said custom CSS theming allowing users to simply turn the whole thing off. In which case turning off custom CSS would be the first step in troubleshooting. If there’s no problem with Custom CSS turned off, then most likely* it’s an issue in the custom CSS and up to the admin to troubleshoot themselves.
*I say “most likely” because custom CSS could uncover some underlying issue on the platform, which should anyway be something you want to find out.
Overall, I only see significant upside with very little downside. At least not something that can be managed.
I agree. Having worked in technical customer service I understand the concern of an additional factor to deal with in troubleshooting. But a global CSS enable/disable toggle should handle that just fine. It could certainly result in having to make frequent first replies in customer support of “did you disable CSS and test this again?”, but that may be mitigated by an auto/intelligent response in Intercom, and a notice on the issue report function that custom CSS isn’t supported and must be disabled before making issue reports. So custom CSS as a feature does have the potential to cause some support issues, but I think they can be mitigated enough, and meanwhile the potential savings in dev and support time for minor aesthetic preference work would be minimized or removed entirely. On balance it still seems worth it to me.
And a (possibly not insignificant) bonus: Fibery would be the only major SaaS PM tool I know of that allows this! So it becomes a marketing feature as well.
To me there’s also the added bonus of allowing the community to share their CSS tricks. Right now there’s Show your Space, but looking at Obsidian and other open source tools, the ability to share enhancements is great and allows Fibery to harness our efforts…
Yeah, both great points @YvetteLans and @njyo , and both of those are things that could help Fibery develop a better “flywheel” for growth. Partners getting more incentive to create custom and whitelabeled solutions would be helpful (although obviously this is a very simplistic “whitelabel” approach), and being able to show cool-looking Fibery workspaces would add a Notion/Obsidian-like aesthetic aspect that a lot of people in the PKM space gravitate towards (for better and worse).
True, although there are more options for whitelabel AFAIK.
Only problem I see for my clients, is that we’re developing a flexible workspace within a fixed framework. If I make changes in CSS, then in theory I have to implement all those changes in each and every workspace of the client. Or I don’t implement it, but then the UI of client A differs from client B.
That’s not really handy since I also create docs/Wiki’s etc. about the workspaces…
Indeed, although I think this also connects with the larger problem of managing templates and versioning and updates, etc. which I would guess Fibery will never tackle, but in an ideal world would. To be more specific, what I mean is that let’s say I create a Template and share that and 5 people (clients or otherwise) start using it. If I then update that template in a way that is backward-compatible with the previous setup, but has major improvements, there is no way currently - as far as I know - to propagate those changes to the users of the template. It is admittedly a tricky problem to deal with, especially in a SaaS like this, but it does significantly limit the utility of Templates in whitelabel scenarios too, I think. I suppose what you perhaps can do is try to make changes in new Spaces and then just share only those new Spaces as a new Template to be added to the old one, perhaps. But it’s definitely cumbersome.
Anyway, a system that could manage versioning and merging for Templates/Spaces/Workspaces could obviously also handle the same for CSS.
I guess another approach to the CSS problem specifically would be the idea of “parent” workspaces and child workspaces, with all the children sharing certain aspects like CSS. I imagine this might be a good approach to simple whitelabeling. But that’s not really something I do, so you can surely speak more clearly to what you’d need, and it’s obviously a much broader feature request.
I’m now using Stylebot to correct the most pressing style issues in Fibery, but that is just a workaround because each user then needs to install Stylebot and share the same CSS files, which is not doable.
The reason why this topic may have priority, because it will allow:
Fibery developers to focus on what is on their high priority roadmap. Many of Fibery’s style issues have remained unaddressed for a while. With custom CSS, we could potentially assist by prototyping solutions, especially for style features.
Admin users to address UX style tensions, through the custom css file in the settings.
This of course would not rely on Fibery support, it is the admin’s own risk. Whenever Fibery Support is needed, we can create a custom CSS toggle button to troubleshoot the issues while ruling out the custom CSS as cause.
The CSS prototypes that have proven to be solid and useful, Fibery can choose to adopt it in their core system.
Implementing this feature will engage users more and attract a broader user base. It will provide Fibery with actionable feedback for improvement. There’s a noticeable shift in web development where users actively co-create with developers. This collaborative approach aligns well with Fibery’s vision and could enhance its adaptability.
Just a Workspace-wide custom CSS would help a lot!