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

[RonMakesSystems]

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

[njyo]

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.

[RonMakesSystems]

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:

@njyo

some refinements of the Whiteboard like auto-add entities by a query would be neat.

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

[Mircea_Braescu]

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.

[RonMakesSystems]

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.

@Mircea_Braescu

the whiteboard is for us the most used part of Fibery, and the core reason we choose this 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.

@Mircea_Braescu

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).

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:

[Mircea_Braescu]

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).

[RonMakesSystems]

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.

@Mircea_Braescu

1. that if that whiteboard belongs to Project A, all the entities added to it will be automatically linked to Project A.

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.

[Mircea_Braescu]

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).

[RonMakesSystems]

I just had a scenario I would have loved a canvas field: storyboarding and planning a video.

I have a “Videos” database and a “Shots” database.

If each video had a canvas field, I could use it as a kind of moodboard, and even convert sketches and ideas into “Shot” entities, where the content selected goes into the canvas field of the shot entity, and the entity is embedded in a way that shows an editable canvas of that entity.

Kind of like a whiteboard in a whiteboard.

Maybe one day!

[RonMakesSystems]

Using whiteboard a bit more recently and realised it would be quite nice to be able to move things around manually like you said here.

@njyo

updating my diagram manually

What if you could set the “Position” field in a “Network” view. Then you could have separate fields detailing position for different cases.

If the position field is not set, it is layd out automatically, but if the position field is set, when you move things around, you are properly changing that position field.

When you make a new “Network” work, it asks you for the position field, and you can either set an existing one, or create a new one.

The big thing this means is that the data of the position is not inside the view, but is part of the entity itself, as it should be.

It might be a bit weird to have 10 position fields if you want to lay out your network in 10 different ways, but I think it makes most sense!

[njyo]

I would expect that the position fields are hidden meta-data and connected to the entity and view. So they should not be visible fields.

But yes, that would be a way to do this.

[RonMakesSystems]

@njyo

would expect that the position fields are hidden meta-data and connected to the entity and view.

While I understand that as an immediate reaction, I feel like that is like asking a calendar view to be data that is stored per calendar view, and be hidden meta data just to show the right position in the view.

While a date is technically more understandable than an x and y axis, it’s still data which is used to position the entity inside the view. You are expected to select a date field per view. Why would a canvas/network view be different?

[njyo]

Yeah, I think there’s a number of angles to think through and it really depends on how one uses things…

• In a dependency map I would agree that such “coordinates” carry information
• If we’re looking at a “sprint kanban” type situation, a card could be in multiple places and then it gets noisy

Maybe there is a need to “select visibility”, maybe there are other elegant solutions. I don’t know, and it would require further design.

[RonMakesSystems]

@njyo

If we’re looking at a “sprint kanban” type situation, a card could be in multiple places and then it gets noisy

Yeah true!! Having the same entity show in multiple places is possible with hierarchies (table view, list view, etc). In a “Network View” I think maybe it would make more sense for it only show once, and show relations as links, instead of the same entity showing in multiple places

[mediamuse]

I very much agree with the impulse to raise this. While this to some degree highlights an intrinsic issue of all “schematizing” canvas apps, it also legitimately points to a need to think through the cognitive, systemic and “meta-functional” integration of the whiteboard within Fibery’s architectural logic.

I think many or perhaps all existing schematizing/mapping augmented canvases suffer from this ambivalence. Consider a venerable app like Tinderbox, which never really made it into the visual canvas metaphor space. Or look at Heptabase (not really schematizing, only partially illustrative), Scrintal (abandoned this path), Obsidian Canvas (perhaps best in class, still not a true mapping app). Often, apps in this space embrace this hybridity by allowing both maps and visual/card boards to exist alongside each other on one canvas (see advanced mapping apps like X-Mind, or how Obsidian Canvas, including the impressive Excalidraw plugin, handles things).

That said, it makes sense for a more advanced, best-in-class app to actively work with this duality/ambivalence/hybridity. There are ways to conceptually address this by enhancing the UI/UX accordingly and with conceptual awareness. Consider TheBrain and its multiple views (though it’s not really “board-like”), or look at Affine and other apps that conceptually build hybrid readings of the same structural information (document vs board) into one “viewport,” so to speak. An interesting attempt to find a ‘reading/visualizing device’ to read 2D (cards, boards, etc.) and structural information (graphs, maps, etc.) simultaneously was once discussed regarding the Atlassian “Dependency Map.”In a way, the whole “buzz” around “graphs” alongside “notes,” “documents,” and now “boards” is, I think, driven by the attempt/hope to address this intrinsic duality.

I personally believe that alongside some conscious approach to this duality and inherent “split,” and representing that in UI/UX, there also needs to be unification. Currently, I think the whiteboard is nice in itself, but in many respects a “one-way road” or “dead end” in the system. That is, it’s only partially integrated into Fibery’s overall logic. For example, it can’t be searched globally, and it’s one “view” that isn’t a “view” and doesn’t automatically register in the entities which are part of a whiteboard.

I think this matters, as another way to solve the structural challenge is not to further complicate the whiteboard space itself (in terms of splitting views, alternate or hybrid views, etc.), but to actually embed it more organically in the overall system, and treat all the other views already there as “alternate angles” on the same information. But this only works if there really is a fluid two-way exchange of the maximum amount of structural information between the whiteboard and the rest of the Fibery architecture.

[RonMakesSystems]

@mdubakov Wondering if this idea is unclear, rejected, still needs thoughts, or planned for the future. Pinging as I saw you commented on another related post about references from entity mentions in whiteboard, saying it probably won’t come, but bulk editing might. (the former is more like a rich text field, “Canvas”, the latter like a data view “Network”… Where currently a whiteboard is closer to a canvas than a network)

I’d be happy to clarify anything that’s unclear. I really think whiteboard in fibery has huge potential, but is still not usable in a complex system in its current form, and I’m worried further work on it as a single view and not split would make it harder to split in the future, and pushes it away from how things are done in Fibery. As @mediamuse said above, if I understood correctly.

[mdubakov]

Overall, now we have a single person working on Whiteboards, so for this year we are going to complete

• Insert views into the Whiteboard
• Whiteboard: Support all relations
• Add more shapes for some specific processes
• Whiteboard: Templates (maybe)

So for this year nothing more will be done, then we will see all feedback and decide what to work on next

[mediamuse]

Yes, @RonMakesSystems – I think you read me right. As I was hopefully reading you right, resp. latch on to what you were laying out and pointing to, principally.

The answer here by @mdubakov (and team elsewhere) would signal to me that a deeper ‘logical’ integration than we currently see is not in the conceptual horizon of Fibery – for the time being .
One thing is of course resources. The other thing is seeing whether the ideas/lines of thought generally register, or resonate.

So, for me this unfortunately rules out ‘investing’ in Fibery, as to me whiteboards (canvases as well as ‘maps’) are central places where knowledge is manifested and insight is generated.
So I need this to ‘register’ in the overall system to be useful, or link up to the rest in the best or most encompassing ways possible. As this kind of integrated information system really is the crux for me, in terms of sparking my interest in Fibery, and considering it. And whiteboards being a kind of ‘sideroom’ or ‘black box’ to the system would, for me, not generate any surplus vis-a-vis a situation, where I use separate and specifically aligned tools.
Then, this likewise applies to UI + UX logics and the integration with different functional architectures subtending them, resp. the knowledge-ergonomical process supported and scaffolded by them – which is the concern I read out of your initial remarks about the need to deal with the ‘epistemic’ split and hybridity of the (digital) ‘whiteboard’, nowadays.

So, thanks for clarifications here.

(Just for the records. You write

@RonMakesSystems

I saw you commented on another related post about references from entity mentions in whiteboard, saying it probably won’t come

– can you link up those threaded discussions, resp. put a pointer to this up here? TIA! )

[RonMakesSystems]

@mediamuse

The answer here by @mdubakov (and team elsewhere) would signal to me that a deeper ‘logical’ integration than we currently see is not in the conceptual horizon of Fibery – for the time being .

My understanding too. Unfortunately.

This is the thread I was referring to: Find out which entities are visible in a whiteboard - #6 by mdubakov

[mediamuse]

Thanks!

Uhm. I see.
Too bad. Especially as I have seen the topics dispersed appearance in different threads, which were never really interrelated. (But it´s hard to keep topical focus in these forum environments, as we all know…). So, I will lay my once expressed case to rest.
– Thanks for filling in here (and in other threads)!