Dealing with darn data
My next mini-experiment is to explore different ways to getting data into Kinetic diagrams.
Kinetic diagrams are stored in plain text files. Initially, my idea described in earlier posts was to create a custom domain-specific-language (DSL) using Ragel, to define all the objects in the diagram. Each object can have metadata attributes. For example, suppose there’s a “Salary” box in my finance diagram. “Salary” might have the following attributes: label=Work Salary, vendor=Coal Mines, and amount=3580. Here’s how the DSL would describe the objects in the finance diagram:
+ Salary | label="Work salary", vendor="Coal Mines", amt=3580
+ Checking | label="Checking", vendor="BigBank", amt=400
+ Emergency | label="Emergency fund", vendor=" ", amt=150
+ Savings1 | label="Savings", vendor="MegaSavings", amt=720
+ Savings2 | label="Savings", vendor="BigBank", amt=214
+ Stocks | label="Stocks", vendor="Tradetek", amt=1196
+ Wallet | label="Wallet", vendor=" ", amt=143
+ Purchases | label="Purchases", vendor="stores", amt=212
But something about this approach just feels wrong. After all, can I realistically expect users to type vendor=”Coal Mines” in order to set an attribute value? Of course not. Most users aren’t programmers, nor care to be. So my next idea was to allow the user to type a textual data table:
-------------------------------------------------------------
name | label | vendor | amt
-------------------------------------------------------------
Salary | Work salary | Coal Mines | 3580
Checking | Checking | BigBank | 400
Emergency | Emergency fund | | 150
Savings1 | Savings | MegaSavings | 720
Savings2 | Savings | BigBank | 214
Stocks | Stocks | Tradetek | 1196
Wallet | Wallet | | 143
Purchases | Purchases | stores | 212
-----------------------------------------------------------
This textual table is much clearer and readable. The gotcha, however, is that this requires the user to format that textual table perfectly. I’d need to define some required format in order to distinguish the header values from the rest of the table, and separate columns from each other. So while readable, this approach is still too brittle for real-world use.
The new approach I’m exploring now is to just read the data from a spreadsheet or database directly. After all, wouldn’t it be great if the user can just edit the data in a spreadsheet?
This will be a fun mini-experiment…stay tuned.