Each time I’m trying to use the “table” feature which is in the Rich Text fields, to add pretty simple tables, I am either :
switching back to google sheet because the row management and the lack of formatting (among other things) make it really tedious and limitating to use. So I finish by simply put a link to the google sheet but this is scattering the information, whereas I would love to have all that in Fibery, and 95% of the time I don’t really need advanced “spreadsheet” features like formulas and having multiple tabs.
trying to limit myself with these features but waste really a lot of time
=> in both case, it is quite frustrating
It would be really great if there was a better way to add “non-structured” data in table format, either by :
enabling to embed Google Sheets directly into Fibery, like Confluence did, and make that searchable of course (which would be one of the main benefits)
improving a lot the current “table” feature, by adding the most essential “spreadsheet” features, and improving the row/column management (add/delete multiple etc.). I guess that would also mean to allow for larger tables with an horizontal scrolling.
With the unfair advantage in Fibery that this “table” object could also be referenced like any entity.
Maybe this could even be a new “view” type like whiteboards.
I’m not sure how others do this, but I feel like there is a missing piece here in Fibery,
I agree this is a need, and not just in Fibery, but Notion too, which I only mention because the lack of it in these two tools is interesting. So I’m anxious to see if there will be any movement to solve it. For Notion, their upcoming public API may allow for that kind of interaction with Google Sheets that would give you tight enough integration, including search of Sheets content from within Notion. They already have a good embedding system.
For Fibery, given that developing and maintaining spreadsheet-like functionality is probably a bit of a pain (and once they do, it’s another semi-major feature that people will want more features put into), I think I’d rather see them take their existing (and ever-improving) API/integration functionality, and connect to the whole G Suite of tools. This goes a little off-topic of your feature request for a moment, but I think integrating all of G Suite would be really excellent and help adoption and retention in a big way. You’d get:
Embed G Sheet in Fibery and manipulate directly; ideally the ability to interact with the data in e.g. formula fields, too
Create Fibery Entity from Gmail, open contents of source email from Fibery entity (e.g. for tasks)
Attach and view G Drive files in Entities
Much of this is already available in tools like ClickUp and it’s very useful indeed!
I agree this is a feature that we’re missing from Fibery right now.
We tried to onboard our marketing departement, and they have to keep switching between their simple “follow-up tables” in google sheet, and Fibery, and as a consequence the adoption is not great and the content is not up to date.
Some light improvements on the current “table” feature would really help us cover much more usecases of Fibery, where we still have to switch between tables and Fibery.
Must-haves would be for us :
very strong : ability to have a wider view of the table => if it has to be a whole view to obtain that, it’s not a problem
strong : abity to bulk add/delete cells & rows
medium : background color of cells
No need for formulas, sorting, filtering etc. But the above feature would already enable us to migrate much more content into Fibery, and smoothen the workflows.
Regarding GSheet (/Google integration), it is an interesting option indeed. However we would then miss the linking with other entities in Fibery, which makes it really less interesting for us.
Is it important for most people that the functionality is present in
or would a possible solution come from enhancements of the existing table view plus
Personally, I would love for the existing table view to have more ‘Excel-like’ functionality (editing/copy-pasting multiple cells, filtering/sorting using column headings, easier show/hide columns etc.)
I wanted to highlight a few related requests out there already:
which is approved, and
I’d really like to be able to see the contents of Rich Text Fields in Tables. This is a big benefit of Coda. You can’t do it in Notion, but Notion, unlike Fibery, has good Rich Text formatting in its “simple text” fields, which can be viewed and expanded in Table view. So if Fibery added some Rich Text capability in its “text” simple text fields, that would help a lot, too. What I mean is being able to write bullets, and ideally mention other entities. That request is here:
Basically, every entity view will be just a dashboard for all kind of information: textual, table, diagram, etc.
Another thing that we are going to add is ad-hoc types. You can think about them as freestyle tables and work pretty similar to excel, but under the hood, these are just usual types well hidden from the user (you will not see them in the schema). Thus you will be able to work with Tables freely. We also have to improve the current Table View to make it more functional.
So the solution to your problem in Fibery demands many things:
Change Entity View to allow insert Table View and other Views as well
Add a possibility to add Table View ad-hoc without any existing Type and create like hidden Type under the hood
Improve Table View functionality.
It’s a long path, so please don’t expect it will be done in the next 6 months. But it shows the direction we are willing to move to.
I expected that you would answer that, and honestly I find this “solution set” more powerfull too, so it’s great if you want to go that way.
However, your question raises the main challenge linked to that :
I think this “follow-up tables” has some structure and most likely they should be moved to some Type in Fibery. What exactly these tables contain?
=> Yes in principle, but the profile of user here is not one who want to get into the complexity of defining types etc. just to make a table, that they would like to insert in some context (ex: an existing entity).
So if you go the “hidden Type under the hood” way, this would have to be dead simple/intuitive to create & manage, if you don’t want to loose “basic” users along the way.