Feedback on removing border for Rich Text in Entity View

This is not really a “bug” but may be an “issue” and I couldn’t really decide on a better place to put this.

It appears that Fibery team has decided to remove the border for the Rich Text Field in Entity Views. So far I do not like it. :smile: Not sure if I will maybe just get used to it, and maybe it is intended for eventually making Entities more Doc-like, which I can understand. But it just feels wrong to have a Field without Border. It’s also odd to me that this hasn’t been mentioned (as far as I have seen) in any change logs or announcements. It’s a “minor” but still notable change. Maybe I just missed it.

Before (left) vs. after (right):
Before (with border) After (without border)

Anyway, I’m curious what everyone else feels about this change (assuming you all see the same as I do, across multiple independent Workspaces and browsers).

3 Likes

I like it :slight_smile:

It’s something I thought of a while back and to me it looks cleaner.

2 Likes

Not sure yet… but it’s easy enough to add the border back (and/or a background color) with some Custom CSS (hint, hint to the Fibery team).
:


/* Add border/background to Rich Text fields */
.ObjectEditor .ProseMirror {
    border:  1px solid #ddd;
    background-color: #fafafa;
}

1 Like

Yes, good point Matt! This certainly crossed my mind. I really want official custom CSS support in Fibery though. This latest change makes it all the more obvious how important it may be. :smile: And I think it would be unique among PKM tools, at least as far as I’m aware! Maybe there’s really good reason for that :laughing: but as an Advanced option it seems reasonable

1 Like

Yes - please give us (Admin users at least) lots of CSS rope with which we can hang ourselves
and in return we promise never to bug Fibery customer service when we do :joy:

Seriously though, if I know enough to make custom CSS rules, I should know enough to debug CSS issues, and be able to tell if they are from my custom CSS.

2 Likes

This, precisely this! :point_up: OK, it’s time for:

1 Like

We removed borders for 2 reasons:

  1. Indeed we want to move to a more page-like feel for entities.
  2. Table of Content looked awful with borders.

Custom CSS is a relatively dangerous thing, but we will think about it

3 Likes

Yes, it was only when I went to make the screenshots that I noticed this interaction. I had certainly disliked ToC positioning before, but suggested it simply be outside (to the left) of the border rather than inside. I still think this would be a perfectly fine - perhaps even superior - solution. :wink: But I understand your reasoning.

So far I think mostly/only “advanced” Fibery users, i.e. admins, have responded (I guess that must be most/only who is in here in fact :smile:). I’m quite curious though to see whether general users have trouble finding/noticing Rich Text after this change. To my mind it is a step backwards in “obviousness” (discoverability) and potential usability for more basic, regular users. But that’s just my sense/hunch. Hopefully other admins will report in with their users’ experiences over time.

How dangerous and can you explain more about why?

It is very easy to break UI with custom CSS. When you are a solo user in PKM tool this is not a problem, but with team tool you can break it in unexpected places and users will go to support and we will have hard time figuring out what is going on.

2 Likes

Of course this is true, but… there are fairly easy (IMHO) ways to at least partly address this problem too. Including (but perhaps not limited to) ways of opening a user’s workspace in “safe mode” (in this context just means custom CSS disabled).

Easy solution to the support problem: regular (non-Admin) users do not have access to support. Intercom is disabled and instead links to an email to the admin’s address and/or a custom form if the admin chooses to set it up. OK, maybe this is not acceptable, but… I still like it. And not just for this problem, in fact I start to wonder if non-admins of Fibery workspaces should even have direct access to support! :thinking: (obviously they can always email you or go to the forums or Twitter, of course)

I find the without border a bit impractical.

Now I have to scan the page to see where I can input rich text.

I find the title of the rich field, and the default placeholder, to blend into each other.

To me, I rather have it ToC look slightly ugly.

Maybe the design here could be revisited?

image
image

1 Like

Please re-add this! Not seeing that you can type into a text field is insane. Multiple people in my team are annoyed about this… I had to add this again with Stylus but that’s obviously not a solution for everyone.

The CSS I’m using to fix this UX issue:

	div[data-state="open"].object_editor_collapsible_field_container .notranslate {
		border: 1px #383838 solid;	
    	border-radius: 6px;
	}
3 Likes

Some good points here:

  • I was surprised to see this too. Don’t recall any votes for it, and I feel like there is a myriad of more practical needs that would be relatively easy fixes that are not getting done.

  • I tend to lean towards liking the previous way with the box, but it’s not a big deal. So I mostly agree with you.

  • I’m probably getting off topic, but re: formatting in Rich Text fields, there is a lot to improve, mainly the “odd behaviors” that come up a lot here.

One thing that my team is forced to do all the time due to the lack of this feature:

…is make a screenshot of a comment in another entity, paste it, and then continue the comment. We also write with “soft returns,” meaning hit “shift” + “Return” when making a new paragraph, so we keep references from getting lost by doing a hard return. But when you insert the image I’m speaking of above, there is no way to keep the “soft return” aspect of it, even if you don’t hit “return” straight up without shift. This doesn’t really look better or worse without the box around Rich Text, but again I just think it would be good to solve this issue before undertaking a cosmetic fix like the box in rich text.

You guys at the Fibery team always ask for unfiltered commentary, so I hope you don’t come down on me for this!

1 Like

Here’s a really “special” and fun example of why this borderless approach is, well… bad UX (sorry guys, this one really mystifies me :smile:):

  • Go into full screen on a Rich Text Field with no contents
  • Try to find the show-on-hover “collapse/restore” button without a field border to guide you :sweat_smile:

No cheating as a designer because you know where you put it. Imagine a new user trying this feature for the first time. No fun.

5 Likes