Empower non-programmers to generate an OPK script for a USB drive

[rjcorwin]

We'll build a GUI that talks with hub.openpipekit.org, presents some forms to users, and then gives them a download to put on a USB Drive for their Pipe hardware.

Template started here -> https://gist.github.com/rjsteinert/32c43313cf80e4ce6c10

[rjcorwin]

When we build autorun files for Linux, when we build a sketch, we create a recipe... for a robot. Sometimes robots shoot rockets and talk about coming back, but a lot of times they are just picking something up and putting it down; there are different types of Robots. A Pipe is a kind of Robot. When we create a Pipe script, we create recipe for a Pipe Robot. For example...

blink yellow

watch -n60 "./drivers/opk-temper1-cli-0.5.0/pull --path USB1 | ./drivers/opk-phant-cli-0.3.0/push --url data.sparkfun.com --public_key E9fejd9efjfj --private_key IIF9efejfese83n" &

blink green

That's a pretty simple Pipe Robot that pulls from a temperature sensor every 60 seconds and pushes it to a phant server. It's also a recipe that someone else could use for their own needs by replacing the public and private key parameters.

blink yellow

watch -n60 "./drivers/opk-temper1-cli-0.5.0/pull | ./drivers/opk-phant-cli-0.3.0/push --url data.sparkfun.com/ --public_key G44jd9oDJetbsoh --private_key iDIgensiDeksj" &

blink green

This is pretty common in coding. You write some piece of code and it ends up as a template for when you want to do the same thing but with slightly different ingredients. The trick is to remember which ingredients should or can be replaced. This is sometimes solved by setting some variables at the top of the file to remind us of what can be tweaked in the script. Another approach is to generate the code by feeding data to a template, often referred to as a "generator", or "scaffolding", or "automatic programming". I'm interested in shareable generators for our MVP.

Imagine if I published a generator for a recipe like...

blink yellow

watch -n<%= frequency_in_seconds %> "./drivers/opk-temper1-cli-0.5.0/pull | ./drivers/opk-phant-cli-0.3.0/push --url <%= url %> --public_key <%= public_key %> --private_key <%= private_key %>" &

blink green

If I gathered some ingredients like...

{
  frequency_in_seconds: 60,
  url: data.sparkfun.com,
  public_key: E9i4kf93e9jf3,
  private_key: Eeife3e00fkkfh
}

... and then ran those ingredients through the generator I would end up with a recipe like ...

blink yellow

watch -n60 "./drivers/opk-temper1-cli-0.5.0/pull | ./drivers/opk-phant-cli-0.3.0/push --url data.sparkfun.com --public_key E9i4kf93e9jf3 --private_key Eeife3e00fkkfh" &

blink green

Imagine an app that...

1. Users can submit generators.
2. Users can find other people's generators.
3. A User can tell the the App to parse a recipe into a configurable form that the user then fills out and gets an autostart/sketch file as a download.

In hindsight, what we have been prescribing around drivers is to build a driver that describes itself as half of a generator in a pipe. Put two together and you get a pipe. A Pipe is a type of Robot, and a point we will not lose sight of. We can build a GUI App that, from OPK Compliant CLIs, can generate generators that can then be used in the mentioned workflow above. This is a "generator of generators", sometimes referred to as a generator with sub-generators. But back to MVP, before the generator of generators, I think we need a healthy, low barrier to entry, social way of sharing and using generators.

With the goal of build an app that can use generators to build recipes, we're free to start being creative with our own hand written recipes and see how they evolve into generators, and then later into sub-generators.

Let's build recipes, lets build recipes, lets build robots!

[dwblair]

This is brilliant.

It sort of reminds me of some of the approaches to 'generating embed code' for HTML: e.g. for video you want to embed, you're asking to check off dialog boxes / enter text in fields to specify certain features -- width / height / format -- and then you're, in real time, the HTML that this generates, and which you could then paste into your own HTML code.

Maybe that's an accessible potential approach -- showing the user how changing options affects the autostart script, live?

I really like these ideas!

One caveat that occurred to me: in the end, the action is happening via these command line drivers and the scripts that run them. Here, we're trying to build accessible entrees into that, by autogenerating useful combinations of these CLIs and scripts. This can be useful and important; but it also adds another 'layer' on top of the action -- and we end up with another 'language' -- a sort of 'metalanguage' that the user needs to learn ...

In the end, I guess I'm just backing up RJ's idea, here, and love the recipe idea -- but right now I'm thinking of it terms of a 'language' metaphor: what we've done so far w/ OPK is to specify a sort of loose 'pipe grammar' for how to build up sensor data flows: "Let's PULL data from a sensor and then PUSH that data to a database"

PULL [sensor] | PUSH [database]

Now we're talking about scripts that use this basic grammar to accomplish more data flows -- monitoring several sensors every 5 minutes, say.

If you really understand the grammar, and how to form sentences, then you're good to go. But for people who don't quite grasp the grammar, or who want to use some of the tricks (colloquialisms?) of the UNIX command line, we provide a 'phrasebook' ...

• PULL data from a [TEMP SENSOR] and a [CONDUCTIVITY SENSOR] and PUSH it to [PHANT DATABASE]

[OPK code here]

Another thought just occurred to me: this is also sort of like having a book of 'common pipe fitting arrangements' or something ...

... maybe it'd be nice to have a graphical metaphor for what we're doing?

[rjcorwin]

What are those games called that you fill out a verb and then an adjective and then a noun and then a .... and then it shows you a story using those words and it's totally ridiculous?

[dwblair]

Mad Libs!

http://www.madglibs.com/showglib.php?glibid=185

On Fri, May 1, 2015 at 2:37 PM, R.J. Steinert notifications@github.com
wrote:

What are those games called that you fill out a verb and then an adjective
and then a noun and then a .... and then it shows you a story using those
words and it's totally ridiculous?

—
Reply to this email directly or view it on GitHub
#32 (comment)
.

[rjcorwin]

Haha ya. Mad Libs.

So one of the "pipe dreams" of computing is the ability to tell a computer to do something in plain English like...

"Make me a sandwhich."

Oh wait, it's a computer, so...

sudo apt-get install sandwhich --directory /home/me/belly

Converting statements from humans to something computers understands has a long way to go. It seems like most of the speech recognition out there is a Mad Lib. For example, the Mad Lib, or statement maybe is a good way putting it, that we're after in it's most simple form is :

"On a [hardware], pull from [sensor] and push to [database] every [number] seconds"

Going after this "pipe" statement is what I was doing in the On-Pipe App. Here's a screenshot of the last question for the Mad Lib that results in a computer statement.

A simple sentence but the devil is in the details. Those things you fill out for each "filler" in the Mad Lib result in various dependencies, specific drivers, lots of options to determine how those drivers work, etc. The schema I've been brainstorming for hub.openpipekit.org is a sort of Ontology that a computer can work with that users define that result in being able to do that particular statement as a Mad Lib.

I must say though, these kinds of projects are tough. There's a reason why loose JSON APIs with accompanying documentation are popular on the web and APIs based on RDF/Ontologies are mostly ignored. Working with a strict vocabulary is HARD. Hard to program and hard for end-users to wrap their minds around.

[rjcorwin]

Wireframe of a "Recipe" page. It's kind of like gist.github.com except each gist is a recipe template and there is a form below that allows you to customize the recipe for your needs.

[rjcorwin]

I whipped up an App that picks up a json file that describes a recipe and presents it like so. In this example I set the {{number}} ingredient to 30, clicked "Bake It", and now we see the Recipe script in the Muffin box with {{number}} set to 30. Next step is to tie this app to a backend with user authentication and the ability to create new recipes. That will get us to MVP, then we can work on improving this UI to make it inviting for both programmers and non-programmers. I'm also interested in brainstorming the name for this kind of thing. It's not just about pipes, it's recipes for robots.

[chrowe]

Mad Libs Input Form

Interesting that https://ifttt.com/ uses the recipes term as well

https://zapier.com/ has some good examples of how to handle complex forms that are conditional based on the input and the output.

[rjcorwin]

Wooooow. That article on Madlib style forms is really interesting. We could
incorporate the form into the statement and get rid of the muffin because
the code would just be the result of what is in the statement. That makes
documenting the variables in the form and the statement the same thing. I
think that might be a really good idea.

On Monday, May 4, 2015, Chris Rowe notifications@github.com wrote:

Mad Libs Input Form
http://tynerblain.com/blog/2010/03/01/measuring-interaction-design/

Interesting that https://ifttt.com/ uses the recipes term as well

https://zapier.com/ has some good examples of how to handle complex forms
that are conditional based on the input and the output.

—
Reply to this email directly or view it on GitHub
#32 (comment)
.

• RJ

rj@rjsteinert.com
http://rjsteinert.com
http://twitter.com/rjsteinert
http://github.com/rjsteinert

[rjcorwin]

Bam. Working prototype. Two screenshots. First one is the form on load. Second one is after the user types the number sixty. The recipe code updates on every keystroke in the statement form.

Screenshot 1

Screenshot 2