April 4, 2024 / One-column Entity View layout, mirrored context Folders

[antoniokov]

One-column Entity View layout

Switch to a single-column layout to streamline Entity View:

• see all the Fields in both panels even on a narrow screen;
• get more horizontal space for rich text and relation Views;
• allow each user to collapse Fields if they know them by heart.

The two-column layout is here to stay so it’s up to you as a Creator to pick a layout for each Database.

Try the one-column layout if you have less than 10 Fields on the right, especially if most users browse Fibery from laptops, not 32" monitors. Or if your team comes from Notion.

Thanks to your feedback on the experimental features, we realised that compact Fields on top are convenient However, asking Creators to pin dozens of Fields and then instructing users to expand/collapse sections is not feasible. That’s how we arrived at the current solution with two layouts.

Resizable relation Views on Entity View

Widen the Relation View Fields and Embed Views in rich text to accommodate more content on the Entity View, whether in a one-column or two-column layout.

This enhancement allows for better utilization of screen space, enabling you to see more units, cards, or table columns within your Relation Views simultaneously.

Mirrored context Folders

🎓 Graduated from experimental

Mirror a Folder inside a Smart Folder to save yourself from manually maintaining an identical set of Views for all of your Products, Sprints, or Customers.

Fixed Bugs

• Threads work extremely slowly and even hang the browser tab
• Context filter stops applying on entity creation on List view

[aoe]

We have an issue with the smart folders

I understand it’s from the entity view and relations themselved but there’s no way (from what I can see to hide the views other than deleting them).

[interr0bangr]

@antoniokov

Resizable relation Views on Entity View

Huzzah! Thank you, this is huge for us!

[mdubakov]

We are hotfixing it now, hold on!

[YvetteLans]

Thanks for the release!

After a few quick tests we have the following feedback.

Resizable relation views on Entity View

• We have a lot of entities with relation views. In the current situation, I need to adjust each and every relation view to make it full width.
• When it’s full width on my laptop screen, it’s not full width on my team member’s screen. So it looks really odd.
• Also the title will not be left aligned when everything else is on full width. Which looks really uneasy.

(all shown data is dummy data )

I do think it can be a valuable feature to resize the relation view when you have a combination of rich text + relation views.

But when there are only relation views on the screen, it’s really counterintuitive.

Then it would be more user-friendly that a creator or user can choose for a ‘full width option’ (like Notion) or make that the default when there is a one column lay-out.

One column entity lay-out

• When we choose a 1 column lay-out, the many relations will not show. That’s a real bummer since things as ‘categories’ / ‘features’ etc. take so many unnecessary space.
• The help text is also not shown. So user can miss important information that’s in the description of the field.
• We have a lot of use cases where the most important information used to be pinned and all the other information in the right column. With this set-up you are forced to either put all information in the 1 column (without many relations ) or have the old look and feel when you want two columns + many relations, but then it looks really messy.

What would be a best-of-both-worlds solution

• Creator can choose for either 1 column or 2 columns, depending on what’s logic for the database.
• When there is 1 column, the user can collapse the column/‘pinned fields’ if they want (as it is since this release; that’s a nice feature). So that it looks like the picture below.
• When there are 2 columns, the creator decides what is the default view (collapsed or not collapsed) and if possible user can still collapse the ‘1 column’ if they want to (as it is since this release).
• So that you can decide what’s most suitable for an entity. Either in column:

• Or show all information on 1 line when that’s the most suitable.

@antoniokov

However, asking Creators to pin dozens of Fields and then instructing users to expand/collapse sections is not feasible. That’s how we arrived at the current solution with two layouts.

If we want to switch to one column view, we currently also need to do a lot of rework. Since only the information in the right column will be shown if you choose 1 column. All ‘pinned fields’ underneath the title are gone.

I agree that it’s not feasible to instruct the users to expand/collapse section. Would be great if a creator can decide the default.

[mdubakov]

@aoe

We have an issue with the smart folders

Should be fixed, please check.

[aoe]

Yes, it looks fine now! Thanks for the quick response!

[Robert_B]

I love that mirroring feature that’s great.

[antoniokov]

Thanks for the detailed feedback!

@YvetteLans

When we choose a 1 column lay-out, the many relations will not show. That’s a real bummer since things as ‘categories’ / ‘features’ etc. take so many unnecessary space.

We’ll allow displaying to-many relations in a compact manner later, probably in a few weeks. This should tidy things up for sure.

@YvetteLans

The help text is also not shown. So user can miss important information that’s in the description of the field.

Could you please elaborate on this one? The Field description is present, no matter the layout:

@YvetteLans

When there are 2 columns, the creator decides what is the default view (collapsed or not collapsed) and if possible user can still collapse the ‘1 column’ if they want to (as it is since this release).

Managing the default value is complex for (new) Creators, choosing where to look between two almost identical sections (to the right, to the top) is complex for casual users. Here we have consciously limited the flexibility and power in favor of a more “onboardable” experience.

@YvetteLans

If we want to switch to one column view, we currently also need to do a lot of rework. Since only the information in the right column will be shown if you choose 1 column. All ‘pinned fields’ underneath the title are gone.

We will keep a close look at this and, perhaps, include pinned Fields when switching between a from 2-col to a 1-col layout.

[ccollins]

@antoniokov

@YvetteLans

When we choose a 1 column lay-out, the many relations will not show. That’s a real bummer since things as ‘categories’ / ‘features’ etc. take so many unnecessary space.

We’ll allow displaying to-many relations in a compact manner later, probably in a few weeks. This should tidy things up for sure.

Being able to show to-many relations in a compact manner versus a view seems like a great opportunity to standardize the to-many views into becoming blank templates that aren’t tied to any specific relationship. Currently, only the to-many view name is permanently tied to that relation. But the view itself can be changed to reflect any database that has a direct or indirect to-many relation to the entity. So if you are going to allow to-many relations as condensed fields (which I would love), why not also allow adding a to-many view without tying the name to a relation?

• For example, I’d love to have a to-many view named “Hub” that has views for multiple database. But currently I’d have to rename a relationship to make that happen.
• I think standardizing the to-many fields into blank templates that are relation agnostic would also help new users more quickly understand the full power of Fibery.

---

I would also LOVE if single fields could be in multiple columns in the main column. This would mess up the new layout nomenclature, but I think the ‘side column’ should be referred to as a ‘side column’, which would allow you the option for multiple columns of single fields. See example below. I really want multiple buttons in a horizontal row.

| - - - - - to-many view - - - - - -|
| - button- | -button- | -button- |
| - - - - - to-many view - - - - - -|
| - single field - | - single field - |
| - - - - - to-many view - - - - - -|

[Yuri_BC]

@ccollins

single fields could be in multiple columns in the main column

| - - - - - to-many view - - - - - -|
| - button- | -button- | -button- |
| - - - - - to-many view - - - - - -|
| - single field - | - single field - |
| - - - - - to-many view - - - - - -|

This is the need Nr. 1 that I/we have indeed. The separation of single and collection fields has too many drawbacks, actually I don’t see any benefit it at all.

Basically, what is most useful is custom entity view layouts in which fields can be drag dropped in any location the use likes, regardless of the field type.

[Yuri_BC]

@YvetteLans

• When we choose a 1 column lay-out, the many relations will not show. That’s a real bummer since things as ‘categories’ / ‘features’ etc. take so many unnecessary space.

I indeed do not yet see the benefit of locking the page witdth/1 column layout with the pinned fields behavior. These are distinct and separate features of the entity display, and now the problem around pinned fields also includes the width behavior? This is increasing the problems around pinned fields purpose.

The issues that are not addressed:

Top navigation elements need separation from entity fields.

I refer here again to the same issue that in my opinion underlies the recurring problems around the pinned fields: the fibery team still tries to give pinned fields two different functions: to be accessible single entity fields and use them as primary (parent) navigation buttons. This needs to be rethought, because loss of context because of non-persisent and unseparated navigation elements at the top, and because single fields are not integrated well in the main panel. The issues will persist if these two features are not insisted on the pinned fields.

Need for single (non-collection) fields in the main panel.

Users were happy that the pinned fields were vertically stacked because they were missing the single fields in the main panel. The cause for this happiness was that single fields were only accessible in the right sidebar. The real issue here is that users want single fieds as well as collection fields in the main panel, not only as pinned fields.

Need for custom entity view layouts

I see that me and users want to determine which fields show up where based on conditions, not solely based on the database configuration. Once this is implemented, a lot of tensions will be resolved.

[Oshyan]

Not yet weighing-in on the single column layout, instead… I don’t really feel like the changes to the main column width are helpful. And I’m on a 4k, 32" screen, which I thought would have been the target demographic! The old view was fine for me, and now there are problems for people with the narrower width so I’m a bit confused why the change was made. Did you get a lot of feedback that the text was too wide before?

[helloitse]

@antoniokov

The two-column layout is here to stay so it’s up to you as a Creator to pick a layout for each Database.

This will be fun to tinker with. Thank you for preserving the 2 column layout!

[Zauri]

@Yuri_BC

Users were happy that the pinned fields were vertically stacked because they were missing the single fields in the main panel. The cause for this happiness was that single fields were only accessible in the right sidebar. The real issue here is that users want single fieds as well as collection fields in the main panel, not only as pinned fields.

We are working on the ability to drag inputs, enums, buttons and other fields from Right Panel / Compact Panel to Main section as well. This concept is being tested internally now

[Zauri]

@Yuri_BC

Need for custom entity view layouts

I see that me and users want to determine which fields show up where based on conditions, not solely based on the database configuration. Once this is implemented, a lot of tensions will be resolved.

This is exactly what we are working towards! Every experiment currently conducted on Entity pages are preparational steps to introducing custom layouts

[Sylvain_Vuilliot]

We use Fibery as our main management app in our tiny company and love it more and more.
The recent improvements on the “collection views” (table, calendar, time line) and the ability to create multiple views of the relations on a entity where immensely appreciated. Thank you.

As we use the app all days, and are confortable with it, and so efficient with it, we want more
And the entity view seems to be the one with necessary improvements. You are working on it, experimenting : it’s not easy but I like you are taking the risk.

I understand there are 2 main kinds of usages of Fibery : the ones with lots of rich text, whiteboards and some “small” fields (à la notion) and the ones with more structured data, lots of relations and few rich texts fields often optional (like ous).

For our cases, the 2 columns layout with 2nd column automatically collapsed on narrow screen (or big screen but with multi panels opened) was not adapted because our main fields (dates, time consumed, state, budget, remaining address, …) where on the second column and the secondary fields (comments, attachments, notes) where on the main, always visible column. We would have be able to switch them !
So the pinned fields was a good move in the direction to put our main fields always in the place they deserve : in the first column at the top.

So my conclusion, or my contribution if it can help, is that we should be able to put the fields in the order we want regardless of their type (relations, comments, date, text, rich text, …)
I understand that some widgets are bigger than others currently, but this is certainly the thing to work on: have big, small and pinned widgets for all kinds of fields. You already worked on it for pin fields or in table views: a “to many” can be a big section or a small one, a date field could be a full calendar, …
Doing so we could arrange all kind of fields in a one-column entity view regardless of their type, in the order we want, instead of a segregation between “small” and “big” fields based on their widget size.
Perhaps, could we create multiple “small widgets sections” in the flow of the one-column layout to arrange small fields vertically and not all at the top as we are forced currently.

And a last idea: why not allow for multiple named layouts of one database ? the same way you allow for multiple views of “many relation” in one entity view. It was such a good idea !

Thank you a lot for pushing the limits and innovating like you do

[Zauri]

Thank you for the detailed feedback!
We are working on adding ability to move fields to/from every section regardless of field type. This will allow for a more tailored customization of Entity View depending on use case. Furthermore we will introduce multiple custom views for Entities, which will help in many cases as well.

[Sylvain_Vuilliot]

I’m confident that you will do a great job
…and sorry for my “not easy to read” explanation trying to articulate my ideas