Skip to main content

Refactoring graphmind: a plan to mindmap life, the universe, and everything

CEO, Co-Founder
Feb 16, 2010

The following is an outline of the new concepts and the architectural changes we want to introduce in the next version of Graphmind. If you are interested in the project please give us your feedback in the comments!

Concepts

Multi-user modes:

  • Transactional updates: all updates are packaged in an object that gets communicated through a P2P connection with the other Grapmind clients that are viewing the same session. We've got a demo of an initial proof of concept on Peter's post.
  • Master-slave model: a user can join a mindmapping session of another user, and see the changes that the first user is making. It is possible to request control of the session.
  • Aggegration model: even though recommendations for possible children are made, every user makes their own mindmap. A master mindmap aggregates the results from all the users (this could work with an RDF triple store, using for example the storage model of MindRaider).

Editing modes:

  • Mindmap mode: the root of the mindmap object is fixed, additional generations (levels of children) can be added.
  • Dynamic graph mode: when focussing on a node, this becomes the new root of the mindmap. Focussing happens after any interaction with a node (e.g. click)
  • Semi-Dynamic graph mode: when focussing on a node, this becomes the new root of the mindmap. Focussing happens after 1 specific event (e.g. double click on a node, context menu item)

Pheromone recruitment model:

In semi/dynamic mode, instead of fixing your thoughts into a single mindmap, we'll tune the UI so that it acts as a pheromone recruitment model (as seen from ants - thanks Mixel) to lay out the strongest graph trails (this could be done both on a site wide and an individual user level). A trail that is often followed gains in strength, effects of old trails fade using a radioactive decay function.

graphmind 2.0 consists of 5 pluggable components:

  1. GUI layer

    This is what users interact with to:

    • browse mindmaps
    • CRUD the objects represented by the mindmap nodes
  2. Data-object manipulation layer

    At the heart of the dataobject layer sits a .mm format XML object that is manipulated by this layer to reflect the user interaction in the GUI. This .mm file is only a means to an end: it is not necessarily the primary goal of graphmind to be a mindmap builder (in mindmap mode it could be however). Instead this object is used as a sort of cache, a temporary "in memory" data object that stores the current state of the system. An object update request can be triggered by the GUI or the communication layer. When triggered a hook is called that makes it possible for plugins in both GUI and communication layer to manipulate the transaction (e.g. update the corresponding node in Drupal, change the node that will be inserted, etc.). It is possible to make a copy of the .mm object and save it as a node so that it can later be used to return to the previous state of the graph.

  3. Communication layer

    This layer communicates with the different external data storage engines to implement the CRUD requests from Graphmind. In semi/dynamic mode all mindmap CRUD events are also reflected in a mindmap triple store on the Drupal site.

  4. Server side communication helper module

    Acts as a proxy for the communication layer, this makes it possible for developers to write communication layer add-ons in php, that will run on the server (easier to program, smaller Flex plugin for download).

  5. Settings module (on Drupal)

    Here it is possible to switch on and off specific graphmind plugins and to change the global settings. Certain settings can still be overwritten in a graphmind session from the graphmind user interface. This module also checks for Graphmind dependencies in Drupal (e.g. if set to semi/dynamic mode we need an RDF store).

Possible plugins:

  • Auto-complete function (when creating a new node, when adding an attribute - scans known nodes and makes it easy to cross reference, use allowed values from selectlists)
  • Visualization (replace freemind like UI with other displays Futures wheel, Graph browser)
  • Settings

Next steps:

The development of Graphmind is funded from our service business. That means that development often has to happen on the weekend... If you are as excited about this project as us, then please consider sponsering one of the 4 development sprints. It will get you a mention on the Graphmind project page and it will speed up the development pace.

Time estimates:

  1. Backend and data structure (4 weeks FTE)
  2. Transaction scheme (2 weeks FTE)
  3. Concurrent editing (3 weeks FTE)
  4. Displays (2 weeks FTE)

Kristof Van Tomme is an open source strategist and architect. He is the CEO and co-founder of Pronovix. He’s got a degree in bioengineering and is a regular speaker at conferences in the API, developer relations, and technical writing communities. He is the host of the Developer Success & the Business of APIs and the API Resilience podcasts.

Newsletter

Articles on devportals, DX and API docs, event recaps, webinars, and more. Sign up to be up to date with the latest trends and best practices.

 

Subscribe