Captain's log stardate 20171127.1223... Alloy's, data, hierarchy, is... very, flexible! (That's enough of the Kirk monologue) The intention of the flexible data structure was to allow customers to make components out of their assets and break them down into a more logical structure. This also works for non-assets, things like data driven lookups or meta-data. As the project has evolved the data structure has gone where no man has gone before... We aren't talking the architectural data structure, things like the database tables, the foreign key references, the indexes etc. We are talking about the implementation structure, the core configuration for customers that models a connected asset management system e.g. how do lights connect to feeder pillars? How do teams link to projects?
We found that a weakness in designing a database inside a database can be visibility. How does a developer working on the front end navigate a complex hierarchy of stuff to get to his destination? Kirk would have us think that:
One weekend I was playing with a library called d3.js which is a JavaScript drawing library for manipulating documents based on data. At it's core is a sophisticated SVG drawing engine that allows you to abstract the data model from the visual model. This is key as with some libraries the data and UI can end up interwoven and make enhancements or changes difficult.
A little suffering is good for the soul - James T. Kirk
One weekend I was playing with a library called d3.js which is a JavaScript drawing library for manipulating documents based on data. At it's core is a sophisticated SVG drawing engine that allows you to abstract the data model from the visual model. This is key as with some libraries the data and UI can end up interwoven and make enhancements or changes difficult.
Using the Alloy REST API and a little Node.js I interrogated all designs and relationships in the system and came up with a mapping between designs, this structure was simplified into a document which describes nodes and the links between nodes. Finally this document is saved as a JSON file and published next to the Alloy Explorer page on publish.
Sometimes a feeling is all we humans have to go on - James T. Kirk
With our data compiled and made static the load time is instantaneous in the web client. I then used d3.js' implementation of a force layout. This weights each node according to the number of links it has and increases its gravity, with a little tweening we get a very dynamic view of the data. Designs that are integral to many other designs cluster together into a dense core set of designs whilst those that are reference data or used sparingly sit on the outer fringes.
I then took the prototype further and added support for exploring. Again d3.js does most of the work here allowing us to pan, zoom and with a few selection handlers it was fully navigable. Clicking on designs would even show a breakdown of the attributes and incoming/outgoing links to that design via the left hand panel. This also shows internal codes that are useful for developers who need to code implementation specific functions.
Without freedom of choice there is no creativity. The body dies - James T. Kirk
Finally we added some search functionality, a simple full text search style implementation across all the design names, attributes and relationships as well as id's and codes. Anyone diving in from the database perspective or knowing their specific design(s) can get what they want immediately.
Alloy Explorer has been available to the development team for some months now and it has helped us communicate better about designs and relationships. It really showcases the power of visual tools for data exploring.
Until next time, Kirk... I mean Craig out.
Comments
Post a Comment