It must be so simple I can’t see it, but how do I create additional views of a table that for example, only display certain columns?
If I got your question correctly, here is how you do it
1 Like
@Matt_Blais may be hoping, like me, that one day we can have Notion-like multiple “views” or “configurations” for a single Table instance…
I haven’t used Notion much, so can you explain how what they do differs from having multiple table views in Fibery? And of course, how it benefits you. I love learning from other peoples thinking patterns.
If I correctly understood @mdubakov’s answer above (please correct me if I’m wrong!), then what Fibery is calling “Tables” are really just Views; if you duplicate a “Table” (as shown in Michael’s video answer above) you are just creating another View on the underlying data.
Is this correct??
2 Likes
Yes, that is correct. A “table” in this context is a type of “View”, rather than in the traditional database management sense of “container for data”.
This is probably a larger topic than just this specific example since Notion, ClickUp, and probably others have some UI conventions that I find helpful for organizing increasingly large and complex spaces, data structures, visualizations, etc.
So in Notion a database can be created anywhere, and with any one of 6 types of Views: Table, Board, List, Gallery, Timeline, and Calendar. All of these are just views of a database. Only main difference from Fibery here is you create your DB anywhere you want and it lives in the hierarchy, but can be instantiated anywhere else, including embedding into any other page.
Now, you can do like in Fibery and just create a page anywhere in the hierarchy and make it into a given database view. But the nice thing in Notion that helps keep the main nav cleaner and makes it faster to do things is that you can create and select between any of the above 6 types of of views on a single DB “view”. And you can create as many of each type of view as you want and name them. Then simply select between them from a single, er, “view”, a single page in the hierarchy. A GIF probably illustrates this much better than trying to explain.
Abd Sort and Filter options can be customized per-view, so you get a different sort/filter along with your different view if you want. Thus you could have e.g. 2 List views but with different sort/filter and switch between them super fast. That example is the general kind of thing I find it really handy for vs. Fibery’s separate views approach where I have to create an entire new left-hand nav item just to e.g. switch quickly between two filter or sort setups.
In ClickUp you have something of the opposite problem. What can be represented in the left-hand hierarchical navigation is a bit limited, but there is a whole set of top tabbed navigation for lots of things, some of which I think is useful, some of which just becomes confusing IMO. But the flexibility is nice.
Bottom line is I really like the ability to combine left-hand nav and right-hand nav options to make each one simpler and more focused on its particular area of functionality. I think of left-hand nav as “gross” (or top-level) navigation while right-hand stuff is more specific to the currently open entity/doc/database/whatever.
2 Likes
I’m not sure I get what this really means. Isn’t this equivalent to saying for Fibery that a type (and it’s relations to other types) can be created anywhere (i.e. in any app)?
I do see that Fibery has a disadvantage that views cannot be ‘embedded’ in documents, for example.
(sidenote: I would love Michael and the team to implement embedded views, but I’m not sure whether the embedded views should actually exist outside the document, i.e. in the sidebar, so that a view in a document is merely a ‘pointer’…hmmm)
Is this different to Fibery? I mean, I don’t know what a Notion list is (similar to a table?) nor a gallery (maybe on the way?! Reddit - Dive into anything)
Does Notion automatically create one of each of these types of views when a ‘database’ is created (in the same way that Fibery creates a single table view every time a new type is defined)?
Again, I don’t get what this means. Is instantiating a database the same as creating a view of the data? Or is instantiating a database in Notion equivalent to defining a new type in Fibery (including creating a default table view)?
Sort and Filter options can be customized per-view, so you get a different sort/filter along with your different view if you want.
How are these different from Fibery ?
switch between them super fast.
I’m wondering if the core of the issue here is that to ‘switch between views’ in Fibery, you have to pick a new view from the left sidebar, but in Notion, you can switch between views using a dropdown menu above the current view?
I’m not trying to be obstinate/contrary 
I really want to understand your experience.
I totally agree that the switching between views is not as fast in Fibery as it can be in other products. I have most experience with Airtable, and there it is definitely quick to create views and switch between them, but my experience is that the flip side can be that users end up creating a new view every time they think there isn’t one to suit their needs and you end up drowning in views that are mostly useless for most users.
I can see why Fibery can create pain points in that regard. For example, the smartfolders can make it seem like the entities ‘live’ in the sidebar. But without them, the lack of a ‘homepage’ for each type, can make it feel like entities are ‘hiding’ somewhere until you create a view that exposes them.
When I discuss something with colleagues (that involves data found in Airtable or Fibery) I am reminded how the huge variety in users’ pre-existing mental models (about objects and relationships) and users’ historical experiences with GUIs (Excel, facebook, dropbox, etc.) plays a massive role in the effectiveness of the discussions, when in principle, the topic should be the content rather than the presentation of the data.
Sort of but not really. In both cases the database really “exists” in its own theoretical space and is merely “represented” in the available views/navigation in some way(s). But practically speaking the difference is in how you create databases and where DBs and their config options “live”. Fibery has a sort of hybrid approach where there is a true “back end” in which you can create new DBs, collections of DBs and Relations (apps), etc. but also edit some of that in the front-end (Entity fields and Relations). Probably as a result of this it has a distinction between creating/deleting a database (Type) and merely deleting a View of that database.
Notion has no “back end” concept whatsoever. Everything is done in the “front end”, and all these concepts are more intertwined. When you create a database it is created in a definite and specific “position” (even though that is just a representation, it’s the only way you can find/access it) and it is created as a “page” with a “view” by default, since that is the only way you can really “see” and interact with the DB (aside from creating a relation to it from another DB). If you then delete that “page”/view, the database goes with it. So it really does “exist” there as far as the way Notion has chosen to represent things.
I have strong opinions on this. 
Embedded views should absolutely not just be pointers and thus require an entry in the sidebar! Embedding views is a way to create flexible and varied representations of data. Requiring them to match 1:1 with sidebar navigable elements would be cumbersome and unnecessary. IMHO. 
The view options themselves aren’t different than Fibery really, but the fact that you can have multiple “views” on a single “view” or “page” is. And of course you can do this in more than 1 way, you can embed any number of DB views into a single “Page”, but I’m referring here specifically to being able to pick Views from a Dropdown for a single DB page/embed. Note however that the option to embed multiple page views (each with their own sub-list of views!) perhaps helps to elaborate on why this is cool. The list of views is attached to the “table”/DB view, which just further increases the flexibility when embeds are also available, and it does so in a very intuitive (IMO) way.
Yes, but it makes more sense that it does this because as noted above Notion’s DBs actually exist “in” the page/view they are created in/as, which is unlike Fibery. You can delete all Views of a DB in Fibery and the DB (Type) still exists. Not so in Notion AFAIK.
The first one, it’s just a view. But the DB is sort of “attached” to the original page/view it was created in/as/with.
Again the fundamental difference is you can switch between the Views in a single, er… “view”, or Page perhaps is a better term. I mean, Notion is free, you may just want to try it to see how this works, because you’ll quickly “get” it I think. It is not wholly a better system, to be sure, but this particular aspect is a notable improvement IMO.
Er, yes, exactly. It seems simple but it’s massively better IMO. Especially since you can mix any view “type” (gallery, kanban/card, table) within the same dropdown list. This allows you to name/categorize/navigate things much more smoothly. Rather than having e.g. a whole folder of “views of my tasks”, where I might have 5 or more different views of my tasks (Kanban by status, Table, Calendar, Timeline, etc.), instead I have one left-menu item “My Tasks” and I just “live” in this view most of my day, quickly switching between specific views as-needed using the dropdown. And if I find I want a view similar to one I already have but just with a different filter or sort, I can create it easily in the dropdown menu. In Fibery it just feels “heavier” to create it as yet another left-hand nav menu item.
I suspect this kind of thing might be part of what adds to the feeling that @B_Sp and some of his team report with left-hand nav getting overwhelming/impractical, too. If everything you access has to be there on the left, then as soon as you reach a certain (relatively low) level of complexity and/or number of collaborators, you start to see an overly long navigation structure. And of course I know each person can customize the view how they want, so they can collapse folders that aren’t relevant to them, but this ability to do some nav on the right side really is useful IMO. I feel similarly about tabs for Entities as a useful time/space saver…
Precisely!
Also this!
1 Like
That’s a good one guys @Chr1sG, too! Didn’t quite have the time to dig in as much as I’d like, but I wanted to add that I definitely would like to see more of the way Notion handles this than we currently have in Fibery. @Oshyan clearly you have a good grasp of Notion, and I believe I do as well, and there are some ways they deal with views that I’ve been surprised we don’t have yet in Fibery, as Fibery has solved more complex limitations of Notion, such as:
-
Making relations one-to-one or one-to-many. This has huge implications when it comes to grouping in views. Notion can’t even group by relation yet, huge limitation (so on a board you can’t see things like what Sprint a task is in, unless your “Sprint” is just a drop-down, not a relation)
-
Deep rollups/lookups (as Fibery calls them). You can’t do a rollup of a rollup in Notion
-
Some hierarchical concepts, for now with Smart Folders, but coming soon with Hierarchical views that @mdubakov showed in the last monthly blog. You can’t see anything like this in Notion
-
Even in Timeline Fibery is leveraging these relations as you can group by your lanes. Can’t do anything nearly as elegant in Notion.
I would hope that the issues you raise @Oshyan are going to be solved soon, as it would seem they are more on the level of displaying data, and not the underlying architecture of Fibery, which has certainly been conceived in a much more sophisticated manner than the other nocode stalwarts of Notion, AirTable, Coda, all of which can’t handle relations nearly this well.
Hope that’s useful to the conversation!
4 Likes
Yes, my feelings as well! 
Fibery seems more well thought-out and architected in general, but is missing some things to make it really nice to use and really take advantage of all its underlying power/flexibility.
2 Likes
Thanks for the detailed reply. I have used Notion a little, but never as a real work tool, so I guess I never bothered trying to think about how it does stuff, compared with the other tools.
When I have used it, I can remember feeling like it was a bit like trying to work at a desk covered with paperwork where it can be just luck whether you find what you’re looking for, whereas something like Airtable feels like having a filing cabinet of paperwork
Quick comment to this:
I actually think there are times when I really want to be able to include the same view in one or more documents, and I want the view to continue to exist even if the document(s) are deleted. Ah well!
If/when embedded views come, it’ll be interesting to see how Fibery does it.
Oh yes! I have a lot of types that have so many fields that the entity ‘card view’ is way too cluttered.
Thanks for a great discussion!
3 Likes
@Oshyan @Chr1sG Thanks for the deep discussion. We did think about all that a lot, as you can imagine, and we have a couple of ways to solve Views flexibility problem. There are actually two main things that we want to have in future:
- Typeless data. Sometimes you don’t want to add a full Type or you may be not sure what the Type is. What you want is just a bunch of data in a system. We want to make it easy to start with data and don’t think about Types at first. Eventually when you decide that this data should be solidified, you can add a Type from it.
- Embed Views into Entities (or into Rich Edit field, we are not sure yet). There are many useful cases here. For example, you have a Product entity and want to see its features on a Timeline View when you open this Product, or you want to see Features as a Table right here. Now all you have is a very basic list that is barely useful. Another case is to add a report/timeline/board into a document, like into Product Vision document, etc.
We have some concepts how it can be solved, but this requires a lot of work and I don’t expect we’ll implement it in the next couple of month, but option #2 is more important and I do hope we will have a solution for it this year.
We are working on Fibery 2.0 concept and hope to publish it in the next 2-3 months. I like it already, but don’t want to spoil the first impression you’ll have 
4 Likes
definitely (for me at least)
That all sounds very promising! Typeless data is an exciting concept, though I’d agree with @Chr1sG (and you) that option 2, view embedding of some kind, is the more important/immediate need.
Just want to follow up that there are at least two distinct versions of embedding that I can think of as being immediately useful for me.
One is just the ability to present linked collections in a more detailed/nuanced/interactive way. At the moment, you can turn fields on or off, but there could be more sophistication, such as allowing the linked collections to be shown in table view, with sorting/filtering etc. or even timeline view.
The other is where you want to include a view/entity which isn’t meant to be directly linked to the embedding item, e.g. allowing documents/rich text fields to refer to tables/timelines/entities in a more complex way than just mentioning the name of the view/entity. I guess this relates to the discussion of whether the embedded ‘thing’ is owned by the document/rich text field (such that it cannot live outside it) or has an existence/persistence outside the document/rich text (and can be embedded/replicated in multiple places). I know @Oshyan has an opinion on this, but I can think of use cases for both.
I am intrigued to see what we get given
1 Like
I agree, there are use-cases for both. Either would be beneficial, both together would be optimal.
can you give a hint how i can do this in a document?
Sorry if I misled you. I just meant that in the entity view, it’s possible to choose which fields to display in the linked collections.
I’m not aware that anything similar can be done in rich text/documents