July 20, 2023 / Experimental 🥹 new Grid View and 🏛️ Columns Layout in Docs

Yes, we are :slight_smile: But we need to work on Views design embedded into docs, so far they don’t look good.


«Columns Layout in Documents and Rich Text Fields» — One of the most anticipated features. Thank you. :+1:
«New Grid View» — Also a very attractive feature. :fire:


AWESOME! These are indeed huge additions! Thanks a lot! Can’t wait for them to be non-experimental. :slightly_smiling_face:

1 Like

Really cool!! Excited to try it out :star_struck:


	- A groupable table view was pretty much one of our showstoppers with regards to switching over.

Bugs / UX issues:
	- [Bug] Clicking on the reorder indicator, and then on other reorder indicator keeps the first selected row selected - even though visually multiple rows are now selected. The multi task button also only shows one task as selected.

	- [UX] To my knowledge there is no simple way to expand/collapse all.

	- [Major gain, minor work?] Pressing "Tab" or "Shift-Tab" in a "Create entity" flow moves down or up a level w.r.t. the row above.
		One core workflow in other software for us is to quickly map out / write out tasks and their subtasks. In other software we can do that by creating a new task, then pressing Tab or Shift-Tab to move down or up a level of creation. If I press enter I go to a new row, but I remain in the context I was previously in.
			E.g.: Given a view on table "Task" with a recursive relation - I write out "3D Environment", press Enter, press Tab, and I can now write out a sub task under "3D Environment" called "Skybox".
	- It would be great to have the option to group, besides collapsible grouping introduced by the level flow. E.g: I want to be able to have recursive grouping on Tasks, and then group by Project. 
		Currently, I would show the Task table (recursive for collapsible sub tasks) with a Project column - however repeated values aren't hidden (grouping) on Project, so they visually clutter a lot and make it harder to spot the transition.  


So happy with this release. You guys are amazing.

Initial feedback:

  • Confusing Behavior:
    • Final states are not grayed out
    • I keep wanting to right click column headers to get column options
    • Field filtering with multiple databases is very confusing. Currently if you leave your selection in the filter drop down on a database, then the columns drop down only shows that databases fields. So you have to go back to filter and select all databases to see all fields under columns. This is not intuitive to me. Feels like this field DB filtering needs to be built into the column drop down itself rather than carrying over
    • Some of the grid views I’ve created won’t show buttons in the ‘+’ column drop down. Then when I add a button from the columns header button, it lists the button in the ‘+’ drop down as ‘Button was deleted or disabled’. But this isn’t consistant behavior on all my grid views, so I’m not sure.
    • ‘+ New Field or Relation’ button at the bottom of the ‘+’ column drop down doesn’t work
  • Strong Wants:
    • Not yet available in entity to-many views
    • Wish there was entire row color options similar to tables
    • Really want option to group by state/single-selects instead of just relations (similar to Monday/Clickup)
    • Would love a single column count field (single column for all DBs in the grid view) for how many entities are listed below
    • Workflow like @PsyRoelofs described. Shift-Enter to create new row below, tab to indent as inside, shift-tab to bring back to below.
    • Would love an option to make the top level more distinct. Bold / bigger / wider space, something to better visually distinguish
    • Grid view makes me want same DB relation levels from level 2+ and not just from level 1 even more
    • Please consider the grid view collapsible gantt sidebar idea. This would be game changing for us.

Again, awesome release!


I would love to see the entire Fibery UI more consistent in how “options” popups and controls are triggered and interacted with. Right now there are several types:

  1. “always visible” buttons – left-click to activate
  2. “hidden until hovered” – like #1, but normally hidden
  3. right-click to popup a UI menu

There is always a need for some type-1 elements, but my preference for everything else would be:

  • hidden until hovered
  • hovering changes highlighting to show clickability (or auto-opens a popup)
  • left-click is always for “select/activate/open”
  • right-click is always for opening an “options” popup

Also, Esc key use and keyboard focus handling are still very inconsistent

E.g., when a UI popup is active and has keyboard focus, sometimes Esc will close it, but other times Esc will close the current PANE or invoke global search.

Even after using Fibery for years, this still constantly surprises and irks me.


Thanks for the (constent) awsome work, quick feedback on the Grid view: do you think it may be possible to include a similar color feature as the Table view and color the whole applicable field based on color code rules (instead of list-like coloration which is limited to the beginning of the line - thus less visible)?


It is on its way :slight_smile:


Any chance we’ll add the ability to convert tables to grids automatically? :sweat_smile:

Oh, I hope one morning you will wake up and all your tables will be grids.


Not relevant to this topic, but Do we have plan for rebuild References, I’m still depend on those backlinks querry so much. I’m heavy using dataview (an Obsidian plugin) to query things. it’s really mess when i have a tons of backlinks without filtering it


Thank you for releasing this early view of the table/grid view. It looks very promising. Here are a few comments so far:

Grouping by other fields

I couldn’t agree more. I think being able to group rows using other field types is really important. Current structure which requires relations, limit usability. It is missing in other areas of fibery as well (e.g. smart folders and lists). Board view and timelines support additional grouping options for the bins/lanes. I hope the same could be extended to grid/table view. I am hoping that in the future it would be even possible to define custom groupings per view based on things like numerical values or dates.

Collapse/expand button

Currently, the collapse/expand buttons are combined with the database icon which appears next to the name field. However, if you don’t display the name field, you no long are able to control expanding/collapsing of the list. I think that expansion/collapse should be independent of the name field and appear as needed in a reserved space to the left. This also addresses use case where the name field may not be the first field (as per @PsyRoelofs above):

I think this is also may resolve the related request to make database icons optional.

Aggregate functions

I assume aggregate functions for columns are coming in future iterations of grids/tables but I wanted to mention it again. I also hope that aggregate functions would be possible on grouped items (e.g. subtotals) as well as the entire table.

Column header controls

I know fibery has adopted a particular style for creating view settings (like sorting, filtering, formatting, …). However, I think that it would be a massive improvement if these settings were either moved to column headings or were at least available there (per this request). This is a very common pattern with most applications that deal with tabular data and I think more intuitive for average users. It also allows field/column type specific settings (e.g. specific sorting & filtering for dates vs. numeric fields …) to be available. I know in the current version there are some options available on left-clicking. I am just mentioning this to see what is the ultimate plan.

It would also be great if users had a bit more control on how columns are formatted, like changing the horizontal alignment (left, centre, right) or even option to change font weight, all controlled from the header.

Table quick search/filter

As has been discussed extensively here, having the ability to quickly search/filter a view (similar to the manner excel tables allow) would be a huge improvement to tables and something I hope is going to be integrated.

Combined gantt timeline

+1 for this. It would be quite helpful to see this. However, it might be more optimal to allow addition of more columns to the timeline view.


Delivered today


About the New Grid View: It would be useful to be able to combine databases in one column.
In some uses cases that can save space, and also is desireable, for example:
I some of my entities have a many to one relation (parent relation) to project
Other entities have a many to many relation to a project. To currently require these colums to be separate is a tension that similar apps don’t have.

Do you mean combine fields/columns from related DBs in one Table? Like a join?

I guess @Yuri_BC means that it is possible that some columns (=fields) in grid view may only exist/have content for one type of entity, so some cells in that column are just unused space.
If more than one such column exists, they could be combined, if the gaps in one column match the occupied cells in the other, and vice versa.

1 Like

This indeed is not about database joins (editable lookup fields in views table) what @Matt_Blais refers to, although that is an interesting feature also.

What I referred to is indeed more a display format feature of the table, in which fields can be combined to show in the same column. I came across this when I saw this in a view with multiple first level entity types, in which the related ‘hub’ entities in a many to one task relation are shown in a different column than the many to many project relations:

Apart from this particular example, there are several use cases where displaying multiple values of different entity types in one cell can be beneficial. Here are a few examples:

  1. Contact Information: In a customer database, you might want to display a customer’s contact information (phone number, email address) in a single cell. This can save space and make it easier to copy all contact information at once.
  2. Address Information: Similarly, for an address, you might want to display the street, city, state, and zip code in one cell. This can make the table more compact and easier to read.
  3. Product Details: In a product inventory, you might want to display the product name, SKU, and price in one cell. This can make it easier to get a quick overview of the product without having to look at multiple columns.
  4. Event Details: In an event calendar, you might want to display the event name, date, and location in one cell. This can make it easier to see all relevant information about an event at a glance.
  5. Employee Information: In an employee database, you might want to display an employee’s name, position, and department in one cell. This can make it easier to get a quick overview of the employee’s role in the organization.
  6. Financial Data: In a financial report, you might want to display the quarter, revenue, and profit in one cell. This can make it easier to compare financial performance across different quarters.

I can see that this example (where one type has a to-one relation to another db and another type in the same grid view has a to-many relation to the same db) makes a lot of sense to combine them.
Although I could imagine some users might be confused why they can add multiple values in some cells but not in others.

For the other examples you gave, they seem to only save space if you have a lot of entities (of the same type) that have empty values for different fields, e.g. in example 1. some contacts have an email and not a phone number and others vice versa.
However, for example 3 I don’t see the benefit -surely all products will have name, SKU and price, so there’s no space to be saved is there?

Out of interest, where you have databases where the data might be ‘sparse’ (each entity having a few empty fields, but not the same empty fields in each case) is the list view perhaps a better option that grid view?

At this point, the list view I like a lot for easy navigation, but when it includes many fields, I find confusing because they can appear irreguarly horizontally listed.

For the use cases mentioned I’m more thinking in the direction of a proposed new Gallery View. I won’t go in detail here, but I used Gallery views a lot in other applications. See New view type: Gallery View