For users, graphs are great! Diagrams are easy to digest, nice to look at, and they can emphasize important information using connections, layout, and styling.
However, there are disadvantages to the way that graphs are currently done:
- Implementing a graph using the current frameworks can be a cumbersome task. As a result, functionality that is essential to the usability (e.g., undo/redo, copy and paste) of a graph will be left out by developers.
- Certain operations on a graph don't intuitively map to a graphical tool (i.e., deleting a parent in a tree - should the children be removed, or should the children be converted into new trees).
- Editing graphs that contain details with text requires switching between the keyboard and mouse which is annoying.
- As a result of these points, graphs end up displaying the entire model, including details that don't make sense in a graph (e.g., too many links and nodes)
The proposed solution:
- Have a model and a view.
- Use an efficient DSL (or other model editor) to edit the model
- The editor can display all the necessary details in an easy to edit format
- The editor is a more direct representation of the content, and therefore the operations that it support have a strong mapping between the user and implementation
- Display one or more graphs generated from the model
- Support only the manipulations that make sense in the graph (e.g., layout, expanding and collapsing, etc.)
The solution also used a DSL (created using XText) that facilitated the conversion of an instance of a model into a graph and another DSL for manipulating the styling of a graph.
This approach was interesting, especially for cases where a graph is user content driven. In cases where a graph's content is generated from multiple data sources, this model doesn't seem intuitive to me. Also, in cases where the user wishes to persist the rendering of a graph for later use.
No comments:
Post a Comment