We were invited to give a keynote at Foresight’s "Designing Molecular Machines" Workshop on July 10 and 11, which is seven weeks away.  I'd like to use this event as motivation to prepare a series of prototypes that demonstrate a "beginning-to-end" vision for a Realtalk-based scientific workflow.

The actual event might not be very significant, but (unless it falls apart completely) I kind of like that -- I have a history of presenting significant projects in insignificant venues.  The main thing is to have "an audience, a deadline, and an idea", which has always been my most effective motivation.

I'm imagining that the 10-minute keynote would be a teaser-trailer slideshow for the actual demo, which would take place back at UCSF in our dry lab and wet lab, with whomever we choose to take home with us.  We'd essentially be hosting our own extra-curricular breakout session, and we'd probably want to arrange this ahead of time with at least some of our chosen.  I believe we also have the option of making this part of the official program, and we can consider that when we see who's coming.

Regardless of how the event itself goes, I think it will be very beneficial to have made these prototypes, both to give shape to our own thinking as well as to engage other people later.

I'm imagining a demo that tells the story of a real scientific project (presumably the next-gen goniometer, but could be almost anything), starting with conceiving the project and ending with preparing the paper.  The protein kit prototype is an example of what might be one "chapter" in this demo, with other chapters designed to hit significant waypoints in the process (e.g. carrying out a wet lab protocol, analyzing a gel, etc).  These are all prototypes, so they only have to be real enough to convey the vision, and we can hand-wave about what happens between the chapters.

At the same time, this is also a demo of Realtalk itself, so the prototypes will also be designed to hit key Realtalk principles (e.g. at some point, two people will work together with their hands, some rule will be live-edited, etc). [1]  

Technically, the prototypes will probably be somewhere above the protein kit demo and below the mockup video.  There will be some prototypes which will definitely require new Realtalk capabilities (e.g. tracking test tubes), and others where new capabilities would be nice to have (e.g. orange cards) but we can easily fall back to dot frames if necessary without compromising the story.

In my experience [2] we'll start out considering a large set of possibilities, and as we work on them, some will grow, some will move aside, and the demo will resolve into 3-5 distinct chapters in a way that couldn't be foreseen or planned for.  The important thing is to keep moving and not get stalled by details. [3]

I think the presentation should be framed as "this is our vision for what our own lab will look like in a couple years".  This invites the viewer to be excited for us, and maybe a little envious, with no pressure on them.  Framing it as "we are developing tools for you to use" makes the viewer into a customer, and they'll spend the whole time thinking of ways in which it wouldn't work for them.

Another way of thinking of this is as an initial sketch of what could be an "Engelbart in the bio lab" demo in a couple years.

Yesterday, Shawn and I brainstormed some possible chapters:

Conceiving the project.  e.g. reading/playing an existing paper, talking about what they did, its shortcomings, how we could improve it.  Perhaps even browsing a library, where papers in the field are represented as game boxes with playable tangible models. Pulling data or models out of these papers, rerunning models with new parameters...

Initial modeling.  e.g. mocking up a goniometer + BurrH + GFP to scale, at multiple scales. Playing with them, getting a feel for them. Naive rigid-body simulation to estimate the flexibility of GFP for various linkers, and what the EM images would look like.

Designing the protein fusion.  Like last week's prototype.

Designing the origami goniometer.  Could start from my cadnano-like prototype from earlier, or something better.  Could include big-style versions of autobreak or origami sim.

Protocol generation, order management, inventory management.  Probably could be folded into other chapters, but should be represented somewhere. Dynamically-updatable protocols. Orders consolidated with other lab members and integrated into the physical space...

Wet lab.  Deviating from the planned protocol, or improvising new experiments on the spot.  Lab notebook, record-keeping, snapshots.

Cryo-EM data analysis.  Big-style image-processing pipeline.  Trying out various pipeline ideas, snapshotting interesting ones.

Drafting the paper.  All of the steps above could use the draft paper as an organizing structure, filling in paragraphs and figures with simulated or interim results.

Many people may not understand what a "prototype" is, and I think a useful analogy for scientists could be to think of a prototype like an "experiment" -- a thing you make in order to discover something rather than directly use its products.  For example, the goniometer is intended to be a technology for determining the structure of proteins, but it was developed using BurrH, whose structure is already known.  I think scientists understand why you don't want to develop the goniometer while solving an unknown protein -- you can't tell whether your goniometer ideas are working.  Prototypes are "experiments for tools".

[1]

[2] (this was at the time of Stop Drawing Dead Fish)

[3]