This post is aggregating a few points of feedback I recently posted into one coherent place. I just onboarded a company into their new workspace (from notion), and saw a consistent struggle to make views in the right way.
There are the following views:
Top level views Embeddable: In any entity/doc. Config: Creator/Admin Pros: The existence and location of the view is very clear. Con: No ability for context.
Mirrored context views in smart folders. Embeddable: Nowhere Config: Editors of the entity Pros: 1. Context. No need to make a new view per entity if they all need the same type of view. 2. Flexibility. Different Smart Folders can get different context views. In Entity Views, all entities get the same views. Cons: 1. The views created and mirrored are not embeddable, but that would just be a bandaid solution to be fair. The big con is that the whole smart folder isnât embeddable. The only way to get to these views is via the sidebar, and due to Fiberyâs context-empire, generally you get to things not just from the sidebar. 2. The location of these views are unclear. Removing them from smart folder does not delete them, they exist somewhere hidden as âExisting viewsâ but its confusing as to where that is.
Context views by creating an embedded view in an entity. (Same thing as creating a context view from smart folder and not mirroring it) Embeddable: Any entitiy/doc, BUT it does not grab the context from the newly embedded doc, even if its an entity of the same type. Config: Editors of the entity. Pros: Flexibility, can create it as needed. Cons: Lack of scaleability, canât be mirrored/embedded then into other entities with their respective context.
Multi-relation views Embeddable: Nowhere Config: Creator/Admin Pros: Scale. Robust, mirrors into all entities by default. Tabs work nicely. Cons: 1. Not flexible. All entities have the same views. Different entity views all have the same multi-relation views. 2. Must have a relation in order to create. This leads to needing to make fake relations in the data structure, just to have a space for the Multi-relation view.
Creating the same view for all clients, then seeing these views all below each other without needing to click into each client. Right now you must open each one by one, or make the top level view manually them embed into dashboard/document. Solution could be to allow views to have multiple views by context. Just like you can make multiple Pie Charts in the Reporting, allowing multiple views in one view based on context would be nice. Already kind of possible with grouping, but doesnât work for calendar view, or board view for example. (Plus grouping still looks and functions poorly).
Creating custom personal views dashboards. I got a comment yesterday that the âView already exists, its right there, why canât i just embed it on my pageâ referring to a multi-relation view, to be embedded in the entities rich text field. Multi-relation views are essentially context views, and context views are essentially multi-relation views, but right now it feels a bit messy, with different conditions for different things.
Not sure about exact solutions, there are many directions possible. Just wanted to shed some light on current limitations when it comes to views that I saw when introducing a new company into Fibery.
Smart folder context views are embeddable in docs/rich text, no?
What do you mean by
?
Do you mean a view embedded in an entityâs rich text field?
I note that the cons for #3 included that they canât be mirrored, but the cons for #4 includes that they are always mirrored. Doesnât that mean, at least for this problem (of mirroring) there is a solution with one or the other? - if you want a mirrored view, use a relation view; if you donât want a mirrored view, create a rich-text embedded view.
I agree that they also have other weaknesses (like relation views require a relation field, and rich-text embedded views require a rich text container, which might otherwise not be necessary).
It feels like the solution is what is discussed here, no?
Just tried, you can embed only if they are not mirrored across the smart folder.
I mean creating an embedded view inside the rich text of an entity. This makes into a context view with context filters. I think under the hood it is just the exact same as a non-mirrored context view.
Yes, but each comes with their cons as well. So an ideal would be consolidate it into something that has the pros from both. Maybe show the context views inside the entity, then a toggle to mirror into all entities or not.
Or allow each entity to have a different layout. Then technically its still there, but each entity is flexible to show or hide what it needs.
Yes, but only if it allows for ad hoc creation of views inside the entity (that looks and behaves like a relation view container). It needs to be really thought through.
This solves one aspect of views, the second one of having context built into views is another one. Similar to this: Convert pinned filters to tabs
Or if it made multiple of the same view with the context applied (like the way âMultiple Pie Chartsâ work in reporting.)
This way you can see the same view across the context you need. Sometimes you need Entity â Data
and sometimes you need
Data Per Entity.
Grouping helps with this, but doesnât work great for things calendar and general grouping at the moment isnât great.
I have no insight into what the PdMâs thoughts are on Danielâs proposal, but I imagine the idea is that users can create an entity view which is neither 1-column or 2-column layout, but is simply âview layoutâ.
This would be a full page view, allowing to choose any db, and by default would apply a context filter for the entities.
So with these dbs for example:
Project â Tasks
Meetings
A âview layoutâ for a Project entity could be a list/board/table/calendar of Tasks (with or without a context filter) or a list/board/table/calendar of Meetings (with no context filter, since Projects have no direct or indirect link to Meetings).
A user can pin the âview layoutâ alongside normal entity views (as in the image in Danielâs post).
I personally think that this solves a lot of use cases.
The issue of pinned filters as tabs (within any view) is tangential to this feature, and may or may not get addressed
But as an alternative, assuming that a âview layoutâ can be cloned, a user could easily just make multiple similar views, each with a specific filter applied, and then tab through them as necessary.
But this can already be done, just create a new entity view and toggle away all of the fields except for one. Would need the ability to remove the Name field as well and youâre done.
What I suggest is instead of a new Entity View type, it is another Field type. A way to put context views as âfieldsâ inside of the entity. (Not fields in terms of data, but feel like a Relation View).
More similar to this:
And regarding this:
Idk what we are doing differently: @Chr1sG
No. The point is, as you already mentioned, this requires you to choose an existing to-many relation (or create one). And the field name might be illogical.
I think weâre almost talking about the same thing: the ability to add a âvisualisationâ to an entity view (where the visualisation can display data from any db, and will be context-filtered by default where possible).
But I think it is not a field. A field is something which contains data which is pertinent (and specific) to the entity. Whereas a view is merely a query, and I think this is what is needed.
And who wants to add a field to every db where they need this visualisation functionality?
It makes more sense that the user is adding another visualisation option to entity view, not adding a new field.
While I agree with this on premise, but the current implimentation of Relation Views already lets you add content that is not part of the field itself. So it would consistent with current stuff.
Having it as a view INSIDE of the entity would be cool. Then it would also be visible as a a list of entities in table view or other. But this is also not needed as like you said, its not a field. Just like the Relation Views the un/filtered content is not shown in-line anywhere, it makes sense. It just shows the REAL relation in-line, and you can do whatever filters you want in the relation views.
Maybe it would be better to add a concept to entity views. Fields + Widgets. Where you can have fields of the data, and widgets (views) within an entity. (This is getting awefully close to âDashboard view as entity layoutâ thoughâŚ
Being pedantic, relation views can be configured to allow you to âvisualiseâ content that is not part of the field itself, but you are not adding any content to the entity itself.
Yep, exactly. Thatâs pretty much exactly what I meant.
There would be âdashboardâ and 'single viewâ (aka widget, or whatever) as entity view layout options, in addition to â1-columnâ and â2 columnâ.
The âsingle viewâ layout option is basically Danielâs request.
With those two possibilities, I think most use cases are well-covered.
But these are not âfieldsâ. If you were to query the schema, you would not be able to see these visualisations in the structure of your workspace.
And your dashboard/widget layout could potentially be configured to show entities in an unrelated db - there would be no connection (direct or indirect) from the entity to the items shown in the widget (i.e. no context filter possible).
Okay weâre on the same page. The only difference is that I donât see it as a âOne View per Entity Viewâ but as a âDashboard Viewâ where you can add as many views as youâd like. And also add in fields from the existing entity into the dashboard.
Could you maybe add screenshots to the examples? Iâd love to follow along but I donât know if there is globally accepted language for each of the four view types you mention and Iâm not sure which one is which.
Yes, these are possible solutions for the issue of allowing other views in entities.
The main issue with all of those still:
All entities of that database have the same layout and views. This lacks flexibility. Ideally the âDashboardâ layout has the ability to either be the same for all entities (Then only configurable by admin/creator), or allowed to be adjusted per entity (then editable by anyone with edit access, like a document).
But this still only solves one issue regarding views.
Iâll explain what I mean here:
Sometimes you need to see a view of the task calendar for a specific client. So you open up the client and see the calendar. Possible now, and would be even better with the solutions you outlined above.
Sometimes you want to see the task calendars per client. As in, you want to see the data PER client, and not within the client. Yes, this might just be an extra click, but it makes a difference when seeing an overview.
The workspace I onboarded made seprate top-level views per client (filtering manually) then embedded them into a document. And I tried telling them âTHIS ISNâT THE FIBERY WAY!â as they will need to reconfigure views for every new client which isnt ideal, but they were insistent on wanting the overview of calendars in one page, and that is indeed the only way to do it in Fibery right now.
If this actually works, it might be a solution for now. But see the video I put in where I tried and it doesnât work for me above.
When you say that you want to see a task calendar for each client, this can currently be done in a couple of ways:
You could click on each Client and look at the relation field for Tasks, where there is a calendar view configured
You could set up a smart folder of Clients in the sidebar and add a mirrored calendar view of Tasks
You could set up a sidebar calendar view, and use quick filters to see Tasks from specific Clients (1 only, 2 at once, all at once)
There may be some opportunities for UX/UI improvements in each of these, but I still donât get what the fundamental problem you are getting at when you say
The new Ghantt view allows to group and collapse the grouping. This is very good. But theres no option like this for calendar or timeline. âLanesâ are not collapsable in timeline.
If my role task is âReview Deadlinesâ, I want to be able to have a view I can go to in order to see all deadlines, per client. Not open each client and see the deadline. Its a subtle difference, but I think it makes a bit impact in terms understanding of what needs to be done.
(And quick filters are a really poor solution at the moment to this. Technically possible, but not ideal, mainly becuase it means to Hard code the filters again, which is what Iâm trying to avoid in the first place)
I agree that quick filters are not great, so we should look at improving them.
But to be honest, when I look at your example, I personally canât imagine wanting to see the same calendar view, repeated in a vertical series, each context filtered to a different client.
If I wanted to compare the information across different client calendars, I would have a single calendar view and then use colour coding per client.
If I wanted to view multiple client calendars one after each other, I would just use a mirrored calendar view in a smart folder.
Overall, I think there will always be personal preferences for layout and navigation (e.g. horizontal tabs, or multiple sidebar elements, toggles for enabling/disabling filters etc.) but itâs not possible to please everyone.
I would support a lobby to improve view filtering, but I donât think there is a gap in the foundations of what views are possible (beyond the entity view layout discussions we have already had).
Again, this would need to be reconfigured every time a new client is added or removed. Not ideal.
Then you need to click on each one by one, (expand each entity, then click the view⌠lots of clicks) itâs not an overview. More work, and also not embeddable anywhere. Not even possible to send someone a link to do it. You must tell them âFind the folder called x in the side bar, open it, open the toggle for each client, and in each one youâll see the calendar viewâ. Its not ideal.
I agree, of course. I just think there are some use cases that have not been thought of fully when it comes to the different types of views and how they work together.
Yes, an opportunity for UI improvement - colour coding using logic/formula (in the same way that reports do colour coding)
If that were implemented, whatâs wrong with this as an option?
There may be lots of use cases, but I still contend that adding more types of views is not the way to address them.
Perhaps we wonât agree here.
Potentially, but it might be a bit too overwhelming with stuff.
No no, i agree completely. I dont suggest adding new view types. I suggest bringing in Context Views / Context Filters INTO top level views.
Either as tabs or as views living under each other.
Something like this, where then each tab is a context view of that client. And the client list is also filterable to not show all, but only âActiveâ, for example.
Or instead of tabs, it repeats the view under each other. Grouping in table view, List view, and Gantt view do essensially that at the moment. So thats great. But thereâs room for it to be done in Board view, Calendar view, Timeline, Map and maybe even dashboard.
What i mean is that technically this is a table view of tasks, with a context split by Client.
Down side is that grouping doesnât allow for seeing the sums per group, and creating within a group very easily. But this is the concept that could be brought to the other views.
