## Feb 7, 2019

* TOC
{: toc }

### Last week till now 02/07/19

I spent a bit more time Thursday last week visualizing single Hareactive events and behaviors. I spoke with JE and he thought I was roughly on the right track. I came up with a simple pan-and-zooming interface and had this wacky idea that we could simply shrink a large object so you'd have to zoom way in to see the values. But then I got bogged down in SVG text layout algorithms and gave up. I felt like I was losing the forest for the trees.

Friday was devoted to researching mbeddr for Dark, which was fun. I watched a bunch of their videos, got it installed, messed around, and, even read a few papers they published. I then finally printed out and read most of Cognitive Dimensions of Notation, which I realized was an instant classic, and I then spent an hour trying to compile a list of "classics."

On Saturday, I recorded a very long in-person conversation with rntz, which was fun but also exhausting due to the length. It was a fun, math-heavy conversation. I recorded it on my new H4N mic where each of us was speaking into one of the stereo mics, which I think came out OK.

On Monday, my girlfriend and I flew to Rome for more sunshine in our lives, so I didn't get any work done.

Tuesday morning was working on mbeddr for Dark. (I have been scheduling these Dark presentations every 3 weeks or so to give me more time for other work. The next two will be Coda and Retool. Maybe I'll be in SF in March to give one of these in person!)

Yesterday and today were mostly research and I got a decent bit done, mostly in pencil and paper and Figma...

### Turbine Viz Sketches

After getting lost in the weeds with text layout last week, I realized that I'd be better served prototyping in diagrams first rather than code, so I tried my hand at visualizing the first few 7GUIs tasks.

<img src="https://user-images.githubusercontent.com/2288939/52425585-9b787a00-2afc-11e9-901d-f48356c142da.png" height="400px">

I should probably put `{ ... }` or `DomEvent { ... }` as the values in the first line of the counter but I guess I forgot. Besides that it seems to make OK sense. It's a bit weird that the `7` is at the bottom but it appears next to the count in the diagram, but that could be solved in a few different ways, for example putting the `7` where it belongs and sending an arrow up to it.

<img src="https://user-images.githubusercontent.com/2288939/52425583-9adfe380-2afc-11e9-803c-a3ab4b69f0a4.png" width="600px">

The temp converter has a nice parallel structure, but then there's that awkward 3rd-and-4th switch over on each side. One possible way to simplify this is by only computing C (by converting F to C, combining, and stepping) and then mapping over that Behavior to get back to F. But it's really half a dozen of one or six of the other...

I experimented at the bottoms with heights as a function of magnitude, which I think came out nicely. The loops at the bottom make reasonable sense. The main thing I dislike about this example is that `newValue` at the top and `setValue` at the bottom feel very imperitive, breaking the nice denotations, but I guess that's kind of unavoidable given the way the HTML DOM works...

For the temp converter, I also tried an [alternative with timelines that all line up that didn't quite come together](https://user-images.githubusercontent.com/2288939/52426228-dcbd5980-2afd-11e9-9e0e-e600fcca4cf5.png).

<img src="https://user-images.githubusercontent.com/2288939/52425584-9b787a00-2afc-11e9-92d1-3520e3a5f3ae.png
" width="800px">

The flight booker was a fun. Here I experimented with a few different ways to display Behaviors. All the way to the right, I have a Behavior that's always true and it's simply a line with a T over it. Then down at the bottom-left corner, I have a Behavior that's switches between T/F a few times, with hard lines between switches, and soft dotted-lines between where computations occurred but returned the same value as before. In the actual prototype you could imagine hovering over that place to see the computation that occurred there. (However, as I reflect on it now, this diagram might reflect the implementation detail that these behaviors are push-based too strongly...) One interesting note: I realized while making this diagram that the `keepWhen` function is a better use that what I actually had in the code (`filterApply`).

I don't mind that the GUI elements are spread out haphazardly on the canvas here, as long as elsewhere I can see them in the order that they appear on the page. Another possible interface is to not have them rendered in the SVG at all, but when you hover over them, it'll light up in the respective GUI, much like the HTML devtools inspector.

This is also the first time I experimented with putting a lot of code (for the lift in the bottom-left) on the screen. It doesn't quite make sense in context (I just copied and pasted), but it's a reasonable placeholder. In the first version of the prototype, this will not be possible, because we won't have access to the source code. 

The loopy bits for the background colors of the textboxes is pretty straightforward. I like how that came out much, much more than with the temp converter, because setting the background color to a Behavior feels more semantic.

<img src="https://user-images.githubusercontent.com/2288939/52425581-9adfe380-2afc-11e9-9b33-d8511243d032.png" height="800px">

It was fun to work with time and higher-order flows. I simplified this diagram by assuming access to a "seconds since the app started" stream that you see in the top-right and bottom-left. Like the last example, I put some "filler code" for the `snapshotWith` that won't be possible in the prototype. 

The higher order stream came out well. I think it's important to keep them lined up the way I did for clarity. I don't know if it's obvious that the third stream is always `5.7`. Maybe I should put the dotted line markers at `5.7` throughout and put the `5.7` at the end as well? The dotted markers are an interesting trick, but there's also the step-function approach. And here's another idea: number lines with firm line markers usually represent continuous numbers, but that's how I've been representing Events. Maybe I should represent events as circles with no line (or a really stylized / faded line) and leave the timeline to Behaviors...

#### Deep diagrams

These diagrams were initially disappointing. Even when I look at them, they are immediately intimidating, even off-putting. They don't yield to insights in 3 seconds, like many other visual aids do. 

However, upon reflection, I thought about how many of Tufte's diagrams take many minutes of study to fully grasp, and then even more time to mine for interesting insights. So while these diagrams might take 30 seconds or 5 minutes to comprehend, that's an order of magnitude better than an hour or two to understand the code. And they will likely be helped along by *liveness* when they are connected to GUIs that can be interacted with, turning the crank on these diagrams.

### Next steps 02/07/19

I'm going to finish preparing for my mbeddr presentation for Dark in 3 hours tonight. Tomorrow and Monday I will try to continue pushing this work forward for my meeting with JE on Monday, maybe switching to coding some of this up... I'd like to do a visualization of my buttons that create buttons example before that.

As far as next steps on coding, I'd like to go high level and see what I can inspect/crawl out of Turbine stream and component data structures to turn into the diagrams above. Then I'll combine the low-level work from last week with this high-level work to have beautiful diagrams! (I also need to do a bunch of refactoring with last week's code. It was getting a bit annoying working with SVG in the way I was. I am wondering if I should build an abstraction over SVG that converts it to a normal X-Y plane...)

I think Tuesday next week would be a good time to finally publish the Tudor Girba podcast, and finish editing the JE podcast and send it off for transcription.

Wednesday could be a good time for some FRC work. Thurs and Friday I'll plan on getting back to working on the research.

Author: Steve Krouse