HN Theater @HNTheaterMonth

Been working on bringing his drawing dynamic visualizations* to life! I saw the demo like 6 years ago and have been itching to build it. Finally started on it last year and am pretty excited about the possibilities.

Don't have much to show a.t.m except for an old animation I made a while ago when developing the engine: https://imgur.com/a/ELhwWo5

* https://vimeo.com/66085662

I agree — as someone with as much of a design background as a programming background, seeing something like Bubble described as "visual programming" feels a bit offensive. Yes, there's a bit of meaningful visual structure sprinkled here and there throughout their environment. But it's nothing like what one would imagine if they were left to freely ideate about some hypothetical, ideal "visual programming" environment.

In a post-Bret Victor world, we know what such an environment might look like.

Stop Drawing Dead Fish: https://vimeo.com/64895205 Drawing Dynamic Visualizations: https://vimeo.com/66085662

As a visually-minded developer constantly hunting for such tools, and even working on some myself (in a small way — nothing that anyone here will ever end up using, surely), I can assure you that there's enough smoke that eventually we'll see something like what we desire catch fire.

If I had to guess, I'd say we'll see it come out of the world of video games, not web applications. So don't fret that Bubble looks like a step in the wrong direction. They're not building tools for visual thinkers, they're building tools for MBAs.

That reminds me of more extreme work like Bret Victor’s drawing dynamic visualization demo, where drawing commands are reified and can be manipulated/abstracted in place. I saw Dan Ingals do this with some of his work, but can’t find a link ATM.

https://vimeo.com/66085662

> There is incredible motion design work that is purely accomplished in code. Certain things are faster and far more flexible in that medium.

There are, but not that much. Look at the code of this demo. It's not obvious, it was probably hard to tweak to look nice, not to mention doing any debugging.

> There are plenty of effects I've created with code that would be an absolute nightmare to try to create with a GUI.

That's kind of my point. It isn't that code is better-suited to this job - it's that our GUI tools are mostly stuck in the static world and suck for dynamic / interactive visualizations.

Bret Victor put a lot of thought on how to improve this state of affairs; he also brings convincing arguments that such things are still better-suited for direct, visual manipulation - that coding directly is a crutch we use because of lack of better tools.

Some good talks and essays on this:

http://worrydream.com/MediaForThinkingTheUnthinkable/

https://vimeo.com/66085662

http://worrydream.com/DrawingDynamicVisualizationsTalkAddend...

https://vimeo.com/64895205

⬐ azeirah

This is the most significant talk I've ever watched, this man has inspired me to explore fields I never would have. I've first watched a talk of his a year ago, I'm still not done reading up on all the interesting content he links to. He pretty much changed my perspective on the field significantly. Am extremely glad I found his content so early in life.

Extremely significant stuff.

I once saw block languages described as "What I could have typed out in twenty characters takes me 100 meters of dragging and dropping instead." Pretty much sums up the one major issue with them, doesn't it?

Having said that, I'm convinced there's a way to design an interface around it that creates an acceptable compromise with (most of) the best of both worlds, although I don't know what that interface would look like. Perhaps introducing a cursor and treating the blocks as we would normally treat glyphs in typed languages[0], using keyboard shortcuts to quickly insert and manipulate blocks.

EDIT: Also, what's notable about all these block lanuages is that they're essentially taking writing, and turning the words into things that can be dragged around and manipulated as objects. Although we do to some degree process language in that way, I wonder if it isn't doing things backwards.

If you look at Bret Victor's recent work you can see interesting alternative takes on this where the problem is approached from a concrete example first and then generalised into abstractions[1][2][3].

[0] Err... not as in typed languages, obviously, but as in languages that we type out.

[1] https://vimeo.com/66085662

[2] https://vimeo.com/64895205

[3] https://worrydream.com/DynamicPicturesMotivation/

⬐ TheLoneWolfling

Some IDEs end up being effectively doing this.

⬐ vanderZwan

Right, but in that case the IDE evolved around the existing character-based programming language. What if we try it the other way around? Start by designing an elegant block language and then create a keyboard interface around it.

⬐ TheLoneWolfling

Did it? Look at tokenized FORTH, for instance. Now, admittedly there's not a whole lot of syntax there to begin with, but still.

People tend to shy away from languages that don't have textual representations, and for good reasons. It's harder to share code, among other things.

I think the best approach would be to come up with something that is human-readable and writable, but is optimized for the block approach.

And I'd argue that some languages (lisp?) already fit this.

⬐ TeMPOraL

> And I'd argue that some languages (lisp?) already fit this.

Yup. And with proper editing help like Paredit, you start to actually think in terms of moving tree nodes ("blocks") around instead of typing in text. With that, all you'd have to do is to start drawing colored boxes around the code instead of parens, and you'd have a decent, keyboard-operated "block language".

⬐ sukilot

Right, what you want is a seamless view that shows the block diagram while you type, perhaps by "dissolving" a single block while you type in a way that transiently corrupts the block, and condenses the block when the incremental compile notices that there is once again a valid block.

⬐ TheLoneWolfling

Some editors already do this, by, for example, highlighting pairs of brackets.

The Pharo guys are working on that:

https://vimeo.com/channels/ndc2014/97315968

Starts slow, but gets really interesting (disclaimer: I'm a biased interaction designer in this regard, I love this stuff) halfway in.

Pharo might actually become a very good fit for Victor's idea of a big-screen "seeing room" debugging environment, now that I think of it - combine it with some of Victor's idea of drawing dynamic visualisations[1] it would probably be a great environment for creating tools on the fly, and the "everything is an object" model is fitting for the tinkering-mentality of the maker space.

[1] https://vimeo.com/66085662

⬐ seanmcdirmid

Does Pharo support anything more than the standard hot code swapping and live object (but not code) manipulation?

⬐ vanderZwan

If you're familiar with Smalltalk, skip the first twenty minutes of that first video I shared and then stick around for at least fifteen minutes, that's where the customizable views are explained. I think that answers your question - although I don't know how innovative this if you take into account all the alternative UI's that failed. However, the way it is being implemented in Pharo really appeals to me, and I can see it really work well in this "visual debugging seeing room environment thingy" Bret Victor wants us to aim for.

Some of the software shown in the first minute: http://vimeo.com/66085662

Some pretty tools in there.

Relevant Bret Victor video : https://vimeo.com/66085662#t=9m20s

⬐ agumonkey

Can't be clearer.

ps-edit: of course he's always clearer, that's why we watch his talks.

Bret Victor is working on some amazing stuff right now. I suggest his talk Drawing Dynamic Visualizations to see how he’s making programing more direct and less “code”-ish: http://vimeo.com/66085662

Well done guys. For good insights on how you could approach some UX challenges in a tool like Plotly, I highly recommend watching Bret Victor's "Drawing Dynamic Visualizations".

For the non-Plotly folks reading this, Bret's presentation is also very effective at blowing your mind in general.

http://vimeo.com/66085662

⬐ jparmer

Thanks! We are indeed huge fans of @worrydream

Bret Victor also has many other amazing and thought provoking talks:

Inventing on Principle: http://vimeo.com/36579366

Stop Drawing Dead Fish: http://vimeo.com/64895205

Drawing Dynamic Visualizations: http://vimeo.com/66085662

The Future of Programming: http://vimeo.com/71278954

Bret Victor, who has been inspired[1] by Doug Engelbart, has showcased plenty of innovative ways on design/user interaction on his presentations/writtings:

* Magic Ink[2]

* Stop Drawing Dead Fish[3]

* Drawing Dynamic Visualizations[4]

* Media for Thinking the Unthinkable[5]

* LearnableProgramming[6]

* Inventing on Principle[7]

[1] http://worrydream.com/Engelbart/

[2] http://worrydream.com/#!/MagicInk

[3] http://vimeo.com/64895205

[4] http://vimeo.com/66085662

[5] http://vimeo.com/67076984

[6] http://worrydream.com/LearnableProgramming/

[7] http://vimeo.com/36579366

Watch his presentations, they are incredibly inspiring and impressive.

https://vimeo.com/36579366 https://vimeo.com/64895205 https://vimeo.com/66085662

All are required viewing for the HN crowd.

We need to think beyond the limitations of tools no matter how pervasive their use. It reminded me of : http://vimeo.com/66085662 (you can skip to the demo)

⬐ consta

Bret Victor had this talk in February 2013. Is his drawing dynamic visualization tool already available somewhere?

Drawing Dynamic Visualizations. A talk about a new approach to creating data graphics. (35 min)

⬐ justncase80

Bret Victor hits another homerun with this video.

⬐ cing

Data-driven visualizations like these seem well-suited for data exploration, but the suggestion that scientists lives will change for the better from them seems like a stretch. I'm not just talking about constructing original visualizations like "Feynman Diagrams". As far as communicating science goes, plots need to be "as simple as possible but not simpler" and as reproducible as the science. If I see a paper with some homebrew plot and I can't immediately compare my data to it, that's a problem.

⬐ tl

Bret mentions the symbols (in this case, code) still being used. What I would foresee is this: take the recent LightTable video that showed a code on the left, output on the right view (or Bret's similar construction from a prior talk). Now, add a "design" switch that converts the code half to something similar to the left panel from the video. Finally, turn your paper into something where the entire body is html, the "homebrew plot" is a javascript expression, and the entire work (data and code) is accessible via View Source and Inspect Element.