Future of Coding • Episode 60 Bret Victor • Magic Ink 🔗 https://futureofcoding.org/episodes/060 Hey, ya'll ever hear of this guy? He posts some wild stuff. Feels like it might be relevant to the folks here. Maybe a little fringe. For instance, he thinks that software could be — get this — better! You might be surprised to learn that I also think software could be better. Radical idea, yes, but it feels like it's finally time for us to take the idea seriously. Next month, we're reading Peter Naur's Programming as Theory Building, with a little bit of Gilbert Ryle's The Concept of Mind as background.

Thank you so much for making this episode! I love Brett Victor's presentations and most of his essays, but I've never been able to get into Magic Ink. I'm not sure why, but I've always struggled both to follow that essay and to stay interested while reading it, so it's great to get your distillation of its contents. Several of the ideas that you discuss, such as showing the distributions of reviews with tick marks under the stars, remind me of Edward Tuft's wonderful work on presenting information graphically. I love Robot Odyssey, and also Rocky's Boots which was a similar game, also from The Learning Company, that dealt with solving puzzles by creating digital logic circuits. For good time, you can play both of them in your browser at archive.org. https://archive.org/details/d098s1-robot-odyssey https://archive.org/details/RockysBoots41

Here's to Robot Odyssey and the Witness! The best views of data tend to combine perspectives, like a "three quarter view" https://en.wikipedia.org/wiki/Portrait_painting#three-quarter_view does the face. It let you see the interaction of properties rather individual properties in isolation.

Just finished listening…great! Some thoughts on the whole “drawing the interface” vs. “building a machine arranging widgets using a grammar”: 1. Widgets vs. drawn UI We used to actually be much more in the “draw the interface” space, basically Views that draw what they have to display. Widgets were added later on for standard interactive elements such as text boxes and sliders etc. And there was a clear distinction, in that for most applications, the dynamic content (document) would be drawn dynamically using a custom view, whereas ancillary/auxiliary information (inspectors etc.) would be fixed layouts of widgets, which might be dynamically enabled or disabled. But the whole structure of the UI was largely fixed (dynamic content inside the views + widgets in static layouts). Although there was a bit of a trend towards widgets, that trend really took off with the Web and the iPhone. With the iPhone, the content both got more dynamic, partly due to latency hiding with animations, partly due to the small screen making it necessary to hide unused UI, rather than juts disable it, and at the same time our tooling got more static, with UIViews that have dynamic content discouraged and preference given to static layers that are moved in and out and around. With the DOM, you really don’t have many options except to change the structure if you want dynamic content (Canvas notwithstanding). So we’ve been moving more and more towards a situation where even purely informational applications display their information via these static/rigid widget sets, at the same time that they information got more dynamic.

@Marcel Weiher what do you think of Naked Objects from Richard Pawson? This model harkens back to the original smalltalk model of objects being able to present their own user interfaces to the user, and messages to objects could be manifested as dynamic menu items - https://en.wikipedia.org/wiki/Naked_objects

Thanks for bringing up Naked Objects! IMHO, NO is awesome, and definitely a part of or at least a starting point for the “somewhat tricky” way I think we can figure this out. I think it needs to be amended somewhat so that any automatically generated (through reflection, not code-gen) UI becomes a starting point that can be refined further. How to refine something that’s only implicitly defined is one of the tricky parts, but probably solvable. WebObjects had a way of doing this with the Direct2Web system. The other even trickier part is how to also support visual-first workflows. For that to work, the visual editors must be connected to an NO-like core model in such a way that structural changes are passed more or less transparently to the NO core and then reflected back up visually, while the purely visual portions remain in the visual layer. Yeah: tricky. And I always loved the way IB and AppKit colluded to let the user become an active participant in the web of objects that make up an application, for example with a button wired to send a message to an object or down the responder chain.

Naked Objects... now there's a phrase... I always liked the idea of having a conceptual UI layer one step removed from the rendering of objects on the screen.