I remember it was recommended to use docs as dashboards, but what if the entity view was the dashboard?
At the end of the day, each project will need a dashboard to see open tasks, amount of time spent, etc. Each project is already an entity! Why not each entity is a dashboard? We can already add the data as fields (not all but most). This means also adding embedded views as relasion fields I think, as well as reports. It would be to be rethought a little bit, but I think it would be much more scaleable as a dashboard system than using docs (or rtf) as dashboards.
3 Likes
This would be my dream scenario.
1 Like
Imagine I add a rich text field to the Project db (called Dashboard) and therein I write stuff, create an embedded (relation) board view of tasks, add an embedded list of assignees, have a burndown report etc.
How does what you are asking for differ?
Perhaps you need to embed single field values?
Perhaps you expect the âdashboardâ content and layout to be replicated for all Projects?
1 Like
Do you mean in a RTF or as a multi relation in the entity?
Edit: as sorry I just reread. The difference is 1. yes, having it the same accross projects, and also the single field as well, all of the above really hahah. Adding a large lookup/formula in the center. Like a dashboard style. I can find some examples and edit this in an hour.
I see, makes sense. Yeah the problems with this are like you outlined:
- Each project will need to have a dashboard set up manually (or a duplicate template that wont be editable globally if I want to make changes after the fact)
- Cant put fields on the canvas. (there was feature requests for this to be added to RTF but I canât seem to find it right now)
- Much harder to make responsive on mobile, (i think)
- It looks really, really bad. Iâm sorry.
My suggestion is for an improved entity view, specifically with the mindset of it being a dashboard. 3 options for views: 1 col, 2 col, and freehand (or dashboard) style entity view. Where you can move views, lookups, linked reports (which isnât a thing yet i think), around on a grid. Then each person has their own personal dashboard in their own user entity. (Which would then be the home page)
Some examples of dashboards:
This is from Target Process.
From Directus, dashboard. (I highly suggest you guys play around a bit with directus)
Scoro Helpdesk
I mean just Google image search âDashboardâ and I think youâll see the differenceâŠ
I added this because even though there are other requests to add dashboards, I think embeding them as an entity view makes the most sense.
1 Like
Yep. I assumed this was core to the use case you have in mind.
Yep, me neither.
Part of a bigger problem I suppose 
No doubt that this is (theoretically) easier to fix than the other three 
1 Like
Funny I was just looking at whatâs going on with TargetProcess yesterday as some of those views were just fantastic, and obviously we have that pedigree here in Fibery! I hadnât looked that them in maybe a few years and there is still some stuff, like the more sophisticated Kansan boards, that we just donât have in Fibery. I quoted one of those here:
Suggestion for App Dashboard / Hierarchy View from left Menu
Good to see you also show how good these were, would love to see Fibery continue to develop towards achieving views that were as good as TP!
can I have some examples of an dasboard like this as an Project entity
I saw this coming up in the roadmap: Fibery
I fear itâs creating another artifact where thereâs no need for one.
What if instead of treating it as a new view, we can change the layout an entity view to a dashboard view. Then the layout of the entity is not the old entity view (applying to all entities in the DB) , but instead itâs the new dashboard view with those views inside taking context from the entity itself.
For higher level dashboards that arenât meant to have context, one could create a âDashboardsâ database, make the layout into dashboard layout, and set that each item can have a different layout (this would also be a new feature). Maybe even this database is set up by default for all workspaces.
The main reason for this suggestion is that it is again creating a new view for something that doesnât fall into the definition of a view. (Just like document or whiteboard). It is a collection of views. Similar to the current entity view with its multi-relation views. So it feels closer to that than a new view type. For me at least.
While it sounds nice, it has some conceptual problems.
- Dashboard View is well known primitive for any user. It demands a leap of deep Fibery understanding to understand how to create a Dashboard without this primitive.
- Entity View always has context. Indeed it is possible to create a separate database like you suggested, but it is even harder for a user to get to this idea
- Dashboard view UI is a grid where you can add, reorganize and resize widgets. It is questionable whether this concept will work good for entity view. It might, but it should support very good defaults with new fields and collections addition. It is relatively hard to make it good (but maybe possible)
1 Like
I see, and understand it makes things a bit more complex, but I donât completely agree.
Especially with the upcoming shift from Documents as views to a default documents database, you could make the same argument that documents are a primitive that people understand and should therefore be their own thing.
Regarding this, indeed if itâs a completely different mechanism I dont think it should replace the current entity view, but just be an extra option for power users. One column layout, two column layout, and dashboard layout. Default is one column, but if you want to custom build a dashboard as one of the entity views, you can.
One point worth noting is that entity view currently allow you to arrange (hide/show/reorder) fields, including relation fields. To-many relation fields can be displayed as various different views (list, board, table, etc.) but there is only one visible view per relation (you can have tabs, but only one is selected).
As far as I understand it, dashboard view will allow for any number of embedded views, each of which is context filtered to the specific entity.
This offers more freedom than entity view: I can have a kanban of Tasks for a given Project alongside a burn-down chart (report view) based on the Tasks linked to that Project.
But overall, I think there is an intersection of use cases for the dashboard concept, so I like the idea of
However, I wouldnât agree with this:
If a âdashboard layoutâ for entity view were possible, I would want it to be replicated for all entities of the same type.
If you do want a unique layout for a specific entity, this should be a âdashboard viewâ.
Exactly! Itâs related to this: Add a view of "Collection" entities within another entity that are not related, just for reference, and this: How we handle a view with too many related entities - #4 by Mircea_Braescu. We right now need to make âfakeâ relations just to have access to another view in the entity view.
I agree! I think in general this is the required use case, but the only places where you might want a different dashboard layout / views per entity is:
- The dashboard database. Or else every dashboard entity is the same and that defeats the pointâŠ
- Maybe the âUserâ entities. Then each user could set their own dashboard in their user entity.
- Maybe a joker dashboard view on an entity that is specific to that entity, if a project is larger and needs a different dashboard to other projects, etc.
Iâm proposing a toggle for âSame dashboard for all [database name]sâ or âUnique dashboard per [database name]â
Then you could have multiple entity views even, one thats the same across projects, and one thatâs project specific. Maybe!
One question is permissioning. I would argue that when a dashboard is different per entity, anyone with edit access to the entity can configure the dashboard, and when the dashboard is the same across entities, only creators can edit. Similar to the way a formula field works vs a text field. Formulas are the same across the db, so only creators can configure, text fields are per entity, so anyone with edit access can edit. Not 100% sure about this one though!
This is the same concept as context views in smart folders - they can be mirrored (same for all entities) or they can be unique. A âdashboard viewâ in a smart folder will do exactly what youâre describing, no?
Yes, thats true! Itâs very similar. But 1. Iâm not a big fan of the context views. If you get to the entity from another place, you donât have access to the context views of that entity (unless they are embedded), but 2. From the spec sheet on the roadmap Iâm seeing its not possible to embed dashboards in rich text. If I understood the way context views work, it relies on that, no?
In any case, I think reason nr 1 is enough to push towards a entity view layout as opposed to a view.
In the currently proposed implementation, would smart folder context view be the only way to bring context to a dashboard? Can you create a dashboard view as a to-many relation view in an entity?
I agree with this part. Also, I donât think this should be limited to dashboards. Tables in an entity or other views would be extremely helpful. I get that there are ways to do this with the To-Many fields, but the experience would be greatly improved if a tab of a multi view entity could be dedicated to a view.