Split whiteboard view to a "Canvas" field, and a "Network" view

Realising I never added an official request for this. And I feel like it’s not being heard or not understood. I’m onboarding an organisation into their Fibery Space, and am finding myself telling them not to use Docs or Whiteboards. This is unfortunate because it has a lot of potential to be something really outstanding.

I feel that you guys tried to mix two things into one solution (network view + drawing canvas), making it bad at both. Let me explain:

View (Network):

A view shows existing data in certain ways. It does not have any data itself. Just the description and icon. Yes, you can multi-insert cards into a whiteboard in order to for it so act like a view, but you can also reference multiple entities in a rich text field for it to act like a list. It doesn’t make it a proper list view!

When you add new items to the database, they don’t automatically show in the whiteboard view (as they would in other views). You can’t filter or color code (as you would in other views). And deleting from a whiteboard doesn’t actually delete the entity, just deletes the reference (unlike other views). Whiteboard acts badly as a view.

Canvas (Containing knowledge / Data)

A whiteboard can contain images, text, etc inside of it. You can write business plans in a whiteboard, take meeting notes. But right now doing that is a really bad idea! Why? The data in a whiteboard is black box, you can’t search for it when search across the workspace, and so I also guess it isn’t indexed by AI (not sure if this is right though).
And the location of this data is also unclear. The whiteboard can be connected to an entity by adding a whiteboard field to a database, but its quite clunky and can easily be accidentally moved to another entity or unlinked if not careful.
And it doesn’t have any change-log history. Can’t see who added what. Like you would with a rich text field…

So it does this also badly!

You guys said you appreciate honest feedback, so to put it bluntly, it feels to me like whiteboard is a bit of a gimmick in Fibery right now. A check box to say you have it.

What to do?

Split into 2 things. Canvas field and Network view. Changes that will preserve data that exists already:

  1. Add a canvas field. This will look like an embedded whiteboard but will be in all entities in the database. Think of this like a rich text field.
    Needed features for this to work and bring canvas to the level of a rich text field: Include whiteboard content in global search and references - #2 by Mircea_Braescu, Entities in whiteboard don't appear in reference, add sections / text / shapes using automations, see edit history of whiteboard, rich text fields inside of the whiteboard where you can mention entities as you type (maybe even replace all text elements to be this?),
  2. Do the same thing you have planned for the Docs → Database migration. Not sure what you have planned, but with the canvas field I think it can work the same way.
  3. (Optional) introduce network view. No comments on the canvas, no following cursor (unless this is also bring to other views). Follows behaviour of other views, but instead of being nested heirarchy, it is in 2d space. Not sure if dragging the nodes around should be allowed, or if it should be stuck to a set of predetermined layouts. I think it should be stuck to layouts personally, seeing as moving the nodes closer or further apart could indicate “knowledge”. Its doing clustering on a view instead of data. When/if relationship properties arrive, maybe you could set a number for how close the relation is, and this would indicate how close it should be in the network. Then the data is actually in the database as opposed to it being in the view only. Not sure about this one though.

Closing thoughts

I really think Fibery has so much potential. It’s already one of the strongest pieces of software in this field. I think this is one conceptual challenges that wasn’t on this year’s list and needs to be solved for Fibery to be a complete solution.

If this isn’t clear, or you disagree, I’d love to hear it. But I felt the need to share it once more, and more comprehensively as I haven’t heard anything last time and I feel bad telling clients “Don’t use this feature as isn’t quite integrated nicely yet”.

Keep going,
Ron

1 Like

Hi @RonMakesSystems, thanks for sharing your perspective!

As somebody who’s a big fan and user of the Whiteboard for process maps, and entity diagrams I have to say that I while I see and agree with the challenges you raise, I think not using the whiteboard and documents at this point feels like cutting the nose to spite the face. Maybe you’re clients needs are different and they need the content to be searchable… but I am happy with Whiteboards and Documents to be something that can be embedded or attached.

The network view could be interesting and I could use it for some entity diagrams, but I actually prefer updating my diagram manually. There is a Workspace network view already and if the same would be reused to create a Network view I cannot imagine where I would use it.

But yes, some refinements of the Whiteboard like auto-add entities by a query would be neat. :slightly_smiling_face:

Hey! Thanks for your thoughtful response! I have 1 question and 1 comment for clarification.

Q: How do you use whiteboards mostly? Is it a folder in the Navigation or as the whiteboard field? When do you use which and why? It is just for relationship mapping? Or also adding content/knowledge?

C: There’s one thing you said that makes me feel there’s misunderstanding:

I personally think this would be a mistake, as it’s pushing whiteboard further into something it is not. It would be like adding an “Auto reference new entities” in a rich text field. Again, trying to act more like a view even though it’s not a view. I’m curious if you would you perfer this over a split of network view (working similar to current whiteboard relation mapping) and canvas view? (with the ability to embed a network view into a whiteboard as well). If so I’m curious to hear why!

Thanks!
Ron

I agree with a lot of your feedback but I strongly disagree with this part

to put it bluntly, it feels to me like whiteboard is a bit of a gimmick in Fibery right now

The reason for it is simple: despite all the flaws that you mentioned, and a lot of other ones I reported to the Fibery team, the whiteboard is for us the most used part of Fibery, and the core reason we choose this platform.

We use Fibery extensively for data modelling and unlike other tools like Miro, here we can use brain out processes with post it notes, scribbles and lines, and then convert those into different data objects which can tie with the rest of our workflows. Fibery enables a discovery to delivery pipeline that was incredibly cumbersome for us before.

That being said I fully agree with the rest of the criticism. One of the things I miss from normal views is being able to color entities. Imagine we define a flow. We’d like to visually mark the cards that were developed vs ones that are not, right now it’s not possible.

Another limitation that grinds my gears is that there is no way to see which entities belong to a whiteboard. Product discovery and modelling can be messy which creates a lot of junk. We want to be able to separate entities, and keep those that are in certain boards and delete those which are orphans (don’t belong to a board). We can’t do that, not even via API.

Regarding the network view, I think I provided this feedback to the Fibery team before, but one of the coolest features that Atlassian Compass had, was this sort of graph explorer, where you could go from entity to entity.

All in all, I don’t feel like whiteboards are a gimmick. It feels like a thing that evolved naturally and ran into some limitations / tech debt issues as it was being defined along the way. Even so, to me it feels like whiteboards are a second class citizen in Fibery despite being the biggest differentiator from other similar tools.

3 Likes

Thank you for sharing where you disagree! Yeah maybe I was too harsh. Maybe a better way to say it is that it’s not as well integrated and consistent with the rest of the platform.

Very interesting to hear this! And this actually makes a lot of sense for the use case. Then the content that you convert to entities are searchable across the platform. Hm… this is where splitting it might cause issues.

I’m wondering if you make a whiteboard per project / idea. Where then you’d be able to make a “projects” database and add a canvas field, and then you can brainstorm and make entities that are autolinked to that project when created in the whiteboard too. See the video I made below showing it.

This is quite tricky conceptually if you compare it to other ways Fibery works. While seeing referenced items from whiteboard is important to being it to the level of RTF, it still doesn’t “belong to” that whiteboard. Just like when you reference in the RTF it doesn’t belong there. There’s only real belonging if you add relationships. Hence, see what I proposed below with adding a canvas to a project. You would be able to filter by number of references, and that might be enough for your use case, not sure!

I’m not about your exact use case, so feel free to correct me if I got it wrong.

I made an explanation of potential:

If I’m understanding you correctly you would have an entity such as Project A, which could have one (or more?) whiteboards, which would be a sort of visualization of the entities related to Project A.

Then there would be 2 types of views:

  1. Network / graph - which is a sort of non-editable canvas that shows all the entities related to Project A
  2. Canvas - the whiteboard similar to how it is today, with the difference that if that whiteboard belongs to Project A, all the entities added to it will be automatically linked to Project A.

If that’s the case, I could see it being hugely helpful.

Right now we use whiteboards in 2 main ways:

  1. System modelling, where all the elements are children of the Project
  2. User flows, where all the elements are children of a Flow (which belongs to a Project).

Kind of, almost!

It’s not that the whiteboard will have two visualisations (if thats what you meant).

It would have one or more canvas fields. Imagine these fields as Rich Text Fields, but in 2d space, meaning that like a rich text field, if you create a referenced entitiy in them, they will get automatically linked, IF theres a one to many relationship in that entitiy (see video above).

Then there will also be a relation view, just like list or table called Network / Graph, where its exactly like you said.

It belong to the entity the same way a rich text field belongs. Its not a related thing, its part of the entity itself.

Then in your use case you could have 2 canvas fields, one for user flow, and one for system. Then add one-to-many relationships to the project for the items you’ll be creating in the whiteboard and then when you create them they will be auto-linked (as a real relation) to that project. Exactly!

Important to note that because its a reference and not the actual relationship itself in the canvas, if you delete it there it won’t be unlinked or deleted from the relation. Just like a Rich Text Field. But if you do it in in the Network view, thats a different story, that would behave like any other view, unlink or delete.

Quick mockup: Each entity will have a blank canvas at the same location, just like a rich text field

Let me know if it makes sense now! I’m finding it a bit hard to explain properly.

Yeah, it makes sense and I want such a way of doing things.
However to me it would feel like like a huge overhaul which I wouldn’t expect any time soon. For now I would settle for incremental updates to the whiteboard such as being able to color cards (just like in views).

1 Like