Platyvue Project
Posted: Sun Mar 29, 2015 7:01 pm
I started learning livecode so that I could build a prototype of an idea I have for documenting open source hardware projects. It's complicated enough that it requires a dedicated application. I've shown the idea to other people and they've liked it, but they don't work in livecode.
So I'd like to see if anyone who already knows livecode is interested in working on the project with me, but there isn't an obvious place like "here's what I'm working on" in the forum. It would be nice to have a place like that to encourage people to collaborate in livecode.
Anywho, if there is a more appropriate place than the "off topic" section I can move this later.
------------- the pitch --------------
I'm more of a hardware guy and I got more and more involved in open source hardware after building a RepRap Mendel (3d printer). There's a lot of potential for an open source approach to hardware projects to rapidly advance the state of the art and reduce costs just as that approach helped in software. The problem is that hardware projects rely on a human to "compile" the object from source so they require much more complicated instructions than software projects. I've been working on a framework for handling that complexity for a few years and for the last year I've been trying to implement it by writing software. After a couple false starts I found livecode and I've made good progress learning it and working through the details of architecting the application.
Several other people in the open source hardware space like the approach I'm taking but they either don't code at all or don't want to sit down and learn livecode. So I'd like to try to convince someone who already knows livecode that this open source hardware documentation thing is a worthwhile project.
What I'm working on is 2 of 3 primary components: a text file (platypus) and an application (platyvue). The platypus files are human-readable text that serve as a kind of "index" for the entire hardware project; tying together all of the various pieces of information and incompatible files. The data structure is a list of keys that count up from 1. Some of the keys contain "historical" actions and some contain the results of those actions. When parsed into a livecode array and displayed in the platyvue application the user sees a graphical network of steps which lead them from the beginning of the project (list of tools/materials) through a series of changes to the end of the project (a finished thing). The user can create and recombine the steps and the information/hyperlinks attached to them to build up instructions so that other people can replicate their hardware project.
The platyvue application itself is based on the idea that the network of project information is too complicated to represent in only one way. So there is one consistent record (the platypus data structure) and any number of different ways to render it to make it easier to understand and edit. For example, the array itself is the rawest representation, I'm using rTree as a slightly less raw way to view the information in the array. I've also got a graphical network view that shows the steps as links and nodes that can be dragged around. Some other views to come later are a bill of materials, a list of step-by-step instructions that serialize the network, and maybe project views like a resource list and gantt chart. The idea is that all sorts of different views can provide insight into the same project by focusing on different facets of it; so it should be quite extensible in that way.
The platypus data structure it's based on records of the entire history of changes to the project (effectively it's one long undo stack). Those changes include relatively simple incremental steps like "make a new node", "link these two nodes", and "tag this node with this data." The structure is primarily made up of state and change nodes with flow links putting them in order from "earlier" to "later" in the scope of the project. The structure is also recursive in that each project has a scope and each node can define other nodes as being inside of its scope. The structure allows for linking between different platypus projects so that if someone has already created instructions you can just "include" them instead of recreating them. The structure also allows for recording pretty much any activity at all and keeping track of what order things happened in. So, for example, you could gradually build up the instructions for a project in platypus AND you could discuss your design decisions in another platypus file. That way you could link to what you're talking about and the link would always reflect the status of the project at the time you talked about it; preserving important context.
The end goal is the 3rd of 3 components which is to host this on a website so that it's easy for people to discover and remix the documentation. A website would also allow for all kinds of neat big-data utilities. For example, by crawling all of the instruction everyone has built and hosted it would be easy to build a histogram of which size bolts are most popular. Then developers might see that if they switched to a different sized bolt it wouldn't change anything significant about their hardware but it would leverage a lot of bolts that people already have, making their project easier to replicate.
It's audacious and it would be nice to work on it with someone else who understands livecode so that we can talk more nitty-gritty implementation stuff.
So I'd like to see if anyone who already knows livecode is interested in working on the project with me, but there isn't an obvious place like "here's what I'm working on" in the forum. It would be nice to have a place like that to encourage people to collaborate in livecode.
Anywho, if there is a more appropriate place than the "off topic" section I can move this later.
------------- the pitch --------------
I'm more of a hardware guy and I got more and more involved in open source hardware after building a RepRap Mendel (3d printer). There's a lot of potential for an open source approach to hardware projects to rapidly advance the state of the art and reduce costs just as that approach helped in software. The problem is that hardware projects rely on a human to "compile" the object from source so they require much more complicated instructions than software projects. I've been working on a framework for handling that complexity for a few years and for the last year I've been trying to implement it by writing software. After a couple false starts I found livecode and I've made good progress learning it and working through the details of architecting the application.
Several other people in the open source hardware space like the approach I'm taking but they either don't code at all or don't want to sit down and learn livecode. So I'd like to try to convince someone who already knows livecode that this open source hardware documentation thing is a worthwhile project.
What I'm working on is 2 of 3 primary components: a text file (platypus) and an application (platyvue). The platypus files are human-readable text that serve as a kind of "index" for the entire hardware project; tying together all of the various pieces of information and incompatible files. The data structure is a list of keys that count up from 1. Some of the keys contain "historical" actions and some contain the results of those actions. When parsed into a livecode array and displayed in the platyvue application the user sees a graphical network of steps which lead them from the beginning of the project (list of tools/materials) through a series of changes to the end of the project (a finished thing). The user can create and recombine the steps and the information/hyperlinks attached to them to build up instructions so that other people can replicate their hardware project.
The platyvue application itself is based on the idea that the network of project information is too complicated to represent in only one way. So there is one consistent record (the platypus data structure) and any number of different ways to render it to make it easier to understand and edit. For example, the array itself is the rawest representation, I'm using rTree as a slightly less raw way to view the information in the array. I've also got a graphical network view that shows the steps as links and nodes that can be dragged around. Some other views to come later are a bill of materials, a list of step-by-step instructions that serialize the network, and maybe project views like a resource list and gantt chart. The idea is that all sorts of different views can provide insight into the same project by focusing on different facets of it; so it should be quite extensible in that way.
The platypus data structure it's based on records of the entire history of changes to the project (effectively it's one long undo stack). Those changes include relatively simple incremental steps like "make a new node", "link these two nodes", and "tag this node with this data." The structure is primarily made up of state and change nodes with flow links putting them in order from "earlier" to "later" in the scope of the project. The structure is also recursive in that each project has a scope and each node can define other nodes as being inside of its scope. The structure allows for linking between different platypus projects so that if someone has already created instructions you can just "include" them instead of recreating them. The structure also allows for recording pretty much any activity at all and keeping track of what order things happened in. So, for example, you could gradually build up the instructions for a project in platypus AND you could discuss your design decisions in another platypus file. That way you could link to what you're talking about and the link would always reflect the status of the project at the time you talked about it; preserving important context.
The end goal is the 3rd of 3 components which is to host this on a website so that it's easy for people to discover and remix the documentation. A website would also allow for all kinds of neat big-data utilities. For example, by crawling all of the instruction everyone has built and hosted it would be easy to build a histogram of which size bolts are most popular. Then developers might see that if they switched to a different sized bolt it wouldn't change anything significant about their hardware but it would leverage a lot of bolts that people already have, making their project easier to replicate.
It's audacious and it would be nice to work on it with someone else who understands livecode so that we can talk more nitty-gritty implementation stuff.