Dear Thortspace … What are the advantages/disadvantages of embedded versus linked spheres?
Well in version 1 of Thortspace:
First of all some background:
(1) Links between spheres when you make them in the App are 2-way links. You have to have edit permission on both of the spheres being linked to make a link between the spheres. And the link will show up as a link to the other sphere on both sides of the link. Whereas embedded spheres are one-way links — essentially an embedded sphere link is conceptually like a web-link… It goes from a page (ie. sphere) to another page (ie. sphere). Although the target page could also have a link back to the page you came from (and of course usually there is a back button) there isn’t necessarily a link in both directions. Visually, however, when you visit an embedded sphere, it grows from its location on its parent. And when you zoom out enough you return automatically to the parent. Which enables a kind of infinite-zoom in and out. Transitions to linked spheres, whereas, display more like they are siblings than children. But I think in practice either could be used for sibling-type relationships and either could be used for parent-child type relationships.
(2) When you make a link between spheres, if that linked spheres has links to other spheres, those links and those other spheres will also display in the app (as long as you have viewing permission on them). (Not yet in the browser version.) … And this process is iterative to the 4th level as you zoom out. (Which we call “Neighbourhood view”.
(3) In the browser version we have already started to move across to enabling multiple alternative networks of spheres. We see this as being advantageous because it means you can bring together spheres as chunks of thinking in alternative different structures and combinations. We are heading towards having an equivalence between paths between embedded spheres and 2-way links. Not quite there in the App, yet, but to try this out for yourself in respect of the Web version, create a sphere with 2 embedded spheres in it and connect them with a path in the App. Make sure all the spheres are public and then go to the sphere with the two embedded spheres in the Web version. You’ll see when you visit either one of the embedded spheres that they are linked together, even if no explicit link has been made between them other than the path on the parent sphere.
Now to come back to the question:
(1) Embedded spheres are good for grouping spheres… you can create groups of embedded spheres that have some association with each other. You can also use paths, as described above.
(2) Linked spheres are good for keep related chunks of thinking together in a more apparent way. Linked spheres show you a partial view of their content, even when they are not the current central sphere. And they show you relationships, as I say up to the 4th level. You build up sphere networks overtime, the one link at a time. But then when you come back to working on spheres you worked on previously, your bit at a time building starts to tell you things and provide insights that you didn’t explicitly know.
(This is, in general, the point of Thortspace as I see it; it allows you to work bit at a time, and then reflects back to you a visualisation of an entire structure of thinking that you have — or your team has — built up over time: across multiple perspectives, from multiple points of view and different contexts and from the view point of different focuses. Which is why, in my imagination at least, I think of it as “everything from the perspective of everything else”.)
There is an article on how to use embedded and linked spheres from a practical point of view here:
Notes:
There are two significant conceptual differences between linked spheres and embedded spheres:
(1) Embedded spheres are mostly one-way links … if sphere B is embedded in sphere A, then A has a link to B, but B does not have a link to A. I say “mostly” because when you’re in Present mode, thortspace keeps track of the spheres you visited in the order you visited them and you can go back through them (like the back button in a browser). Also if you navigate to an embedded sphere you can zoom out to go back to its parent. However those “linking-backs” are not permanently stored anywhere, so that is the sense in which the link is mostly only one way.
Whereas Linked spheres are two-way links. When I link sphere B to link A, I simultaneously create a link on sphere B, that links it back to sphere A. And when I navigate I can follow those linking paths in either direction.
In version 2, and already in the Web version, we plan to have “Paths” and “Links” between spheres be equivalent in respect of embedded spheres. Consequently you can link two embedded spheres on a sphere with a path step, and when you navigate to either of them, you will see the other embedded sphere now appearing as a linked sphere.
(2) Graphically how they appear. Embedded spheres appear embedded in thorts on a “Parent” sphere. Whereas linked spheres appear connected by linking tubes.
