This project involves two pieces:
- A ‘Bubble Map Viewer‘. Viewing a bubble map (Demo here).
- A ‘Bubble Map Creator‘. A tree-structure editor for creating maps (Demo here).
My coding accomplice Shad found a demo of a d3’s ‘Zoomable Circle Packing’ feature while brainstorming ways to create visual concept maps (a shared interest). The demo was simple, elegant and visually striking, and we were curious to see if that format might be a good way to visualize conceptual information. And so this project was born as a way to prototype ‘concept bubble maps’ to see how well they could communicate conceptual information.
Like most web-apps, this one has two parts: the frontend and the backend.
The frontend is handling most of the work of this project.
The ‘Bubble Map’ page, draws heavily from the D3 demo. The demo was modified to include an additional ‘Description’ attribute to the bubbles in the map. This attribute is used to populate a popup box that is meant to display more in-depth information about the node. This part is critical for our use since we are hoping to convey a lot of information about concepts using the map. Also was updated to change the way it displays and zooms so that it only will display the current node and the children nodes.
The form interacts with the backend entirely via a REST API. This means creating, loading and saving of the maps are done via ajax calls. Doing things this was (as opposed to a traditional form submit) means that you do not have to reload the page while working. I have grown to prefer using this approach whenever possible as it makes for a more seemless user experience and leaves open the option for ‘auto-saving’ in the background while working. Also, since the REST API library I built takes care of the details, it means I don’t have to spend time writing code in the backend to handle processing the form requests.
I chose to store bubble tree data in a MySQL table:
- BubbleMapId: A unique ID for each bubble map
- Code: A machine-friendly name for each map (‘ArgumentationChapter1’)
- Name: A human-friendly name for the map (‘Argumentation: Chapter #1’)
- Content: Entire bubble map definition in JSON format
- DateTimeStamp: The last-modified timestamp for the map
Storing the whole bubble map definition in JSON severely limits the ways I can use it in the back-end. For instance, I cannot not query the database to get an individual node of a bubble map and update it’s content. Instead I’d have to first retrieve the entire map from the ‘Content’ field, decode it, traverse the results, update the node, then re-encode it to JSON and then update the ‘Content’ field.
Given this, why not create a more detailed structure in the database that would make the data easier to access in the back-end?
- I did not foresee much need to manipulate the bubble map data on the backend. This is a prototyping project and at this point only the front-end is really the only one using the data.
- I’d have to create separate tables and fields that map the structure of the bubble map onto the database.
- I’d have to write code that maps the JSON data received from the front-end to the DB.
- I’d have to update the DB structure every time the bubble map structure changes. For instance, if at some point I decided to add a ‘color’ attribute to the bubbles, I’d not only have to update the front-end, but also update the table structure and code for storage/retrieval.
No need for a detailed back-end representation of the data plus the time it would take to build and maintain made this an easy call. In future, if we ever decided we wanted to do some serious work in the back-end on the data, I could always migrate to a more detailed structure.
It occurred to me after building the backend that this could have been a good opportunity to try using mongoDB, since I’ve heard that there is less need to manually maintain the data structure, but I have not used mongoDB yet and did not want to tackle that as part of this project.
- Add ‘on-hover’ events (view inner nodes, display summary as tooltip
- Better integration of the ‘in-depth’ dialog view
- Resizing window = resizing map.
- Sidebar map of structure.
- Add permissions
- Better interface for loading your maps (right now you need to remember name)
- Better way of presenting the ‘in-depth’ information (right now the pop-up box is cumbersome and generally a not-so-great solution)
Resources / Notes:
- The project’s GitHub page
- The D3 demo that inspired the project
- This web app builds upon:
- The demo map uses chapter 1 from the Great Courses’ Argumentation