Natively integrated custom CSS (and editor) for Fibery workspaces

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. :smile: 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.:

And of course:

Also some of this:

1 Like

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).

1 Like

Why do you want to hide the header? To reduce clutter? To limit access to users? Something else?

1 Like

@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.

2 Likes

What elements do you find not necessary? Are they elements that you consider not necessary for all users, or just some subset of 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:

  1. 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
  2. My biggest peeve is around spacing and sizing of elements. Therefore I’d want to be able to:
    1. Adjust the colour of heading to make the difference between h1 and h2 and h3 easier to see
    2. Improve the vertical margin between blocks on pages; for example after embeds, but also before headings
    3. 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.

Thanks!

2 Likes

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.

4 Likes

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.

2 Likes

True that!

Also an awesome feature for Fibery partners. To create a sort of whitelabel framework.

1 Like

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…

3 Likes

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).

1 Like

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…

Let’s make Fibery open source :rofl:

2 Likes

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. :smile:

1 Like

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.

7 Likes

That would be so cool. Any updates on this? :pray:

1 Like

No updates. Nothing is planned.

I somehow missed this topic when searching for existing suggestions to adress Fibery’s dampened color-function, due to (afaik) using css mix styled filters, as well as custom css requests.

Maybe some of these quick, edited, css-override visual examples show the potential of resolving that css implementation issue. generally I find fibery’s color function some of the most interesting things with great potential. but it requires solid, saturated background colors to avoid color shifts and resulting lack of color-separation problems.

  • maybe more granularity/iteration of the color function
  • potential leverage of “empowering” css class design
  • most of the current issues could surely be improved with entirely custom, built in css overrides

I’m retracting my vote in my own thread to support this existing and heavier request.
Guess I’ll just remove entirely and integrate it here to avoid spread votes and confusion.

1 Like

From my obselete/duplicate and related thread:
Replace CSS-Filter/Color-Mix(?) with solid background-colors for usability, UI/UX, eye-strain and clarity improvements. Add means for custom, Admin-defined CSS

I suspect css-filters/color-mix is being used to implement Fibery’s color functionality.

In general and historically, since bootstrap, and google, i.e. “material” design systems, to this very day classic implementation of typographic and visual rules are often lacking or entirely missing. This might be in part due to technical limitations. However HTML/CSS standards have evolved more than enough. So in most cases the main reason is probably that frameworks, tools are mainly elaborated by tech-focused people. Classic design, usability/readability, typography rules and theory seem to be forgotten, or simply considered way less.

Afaik one of the very few css-frameworks that actually empowers and considers basic, custom typographic requirements for letter-spacing, line-height etc. is actually tailwindCSS. Most even new frameworks do not consider those aspects or necessities at all.

Unfortunately this leads to generally suboptimal typography, readability, brightness/contrast and extreme eye-strain on a majority of modern websites, services and applications.

This is just my general perception and evaluation. Specifically in Fibery’s current implementation one of the biggest strengths, it’s dynamic, unique, intuitive and powerful coloring-functionality is rather dampened by use of (afaik) css/mix/filtering. Color saturation is strongly shifted/multiplied towards white or dark mode background color: In my perception it’s especially noticeable in dark mode due to accentuation of the issue by black backgrounds and shifts.

This becomes obvious when attempting to select different of default palette colors. As different hues lack saturation-difference to eachother. Also attempting resolution with custom manual colour will usually not help much. As the underlying problem is caused by css(?) filter/mix/multiplication.

Here some examples based on Dark-Reader’s dynamic recoloring, contrast adjustment with some swift Photoshop edits and examples. They are by no means representative, for simplicity sake. Obviously oversaturation, edit for demonstration will in turn not be balanced for certain icons or elements.

Also note heavier use of gray over black or full-white backgrounds with adapted bg/fg text-colors. High BG vs. Text colors contrast imho creates reduced clarity, visibility and on usually bright screens; A lot of avoidable and rather excessive eye-strain. That is not an exclusive fibery-“critique”, it’s basically become the general and modern “norm”. Unfortunately.

Colors have been exaggerated, resaturated to reintroduce and exemplify lack of color-saturation, clarity, increased eyestrain due to lack of “color-saturation-contrast”.

Before:

After or drafted, basic Potential:

Before:

Brief/Potential/Simulated After Edit:

  • Generally iteration on fibery’s dynamic color-influence would be great
  • Furthermore custom CSS capability, depending on underlying frameworks and css/class behaviour would maybe be a doable but powerful tool for admins and users

Some swift css-overrides based on dark-reader interesting css/class-override functionality
In: ► More ► Static (Mode) ► Edit-Pen

if anyone wants to play around with potential or more elaborate class-selectors and overrides to provide some more inspiration or examples.

*{

background-color : tomato !important;
color: #fff !important;
letter-spacing: 0.01em;
}

Swift Dark-Reader Dynamic+ Sepia Filter with Monospace and some non-optimal PS hueshift, resaturation:

1 Like

Not true. You can always allow customer to add custom css same way as browser extension. Simple toggle on and off so you can disable it when reaching for support. I think that implementing this should be quite easy.

2 Likes