Today, I’m sharing a first glimpse of my new programming environment for prototyping and building user interfaces and apps. It’s like a breadboard for building software. You can wire up components, prototype, figure out, think, iterate. It’s a tool for creating tools. I think the closest reference I’ve looked at is Fabrik (as seen in @Ivan Reese’s Visual Programming Codex). It’s tough to share all the potential things it can be used for in one short video. I’ll try to refine it through more videos and writing in the next weeks. 🙂 The video is uncommented. So here’s a summary of noteworthy things: • There are workspaces, blocks and wires. It’s like nodes & wires, but with strict layout and user interfaces in mind. • This doesn’t try to replace code, but makes working with code easier. • Programming (dealing with data and organizing chunks of code) can be done visually. • Copy & Paste as first-class citizen → Code becomes tangible • By visualising and showing data, it reduces the mental overhead of keeping state and data in my head. • Wires are a tool, not a necessity (in theory, a workspace could have a single self-contained block and no wires at all) • Instead of needing to wire up every input, blocks can define their own inputs through inspectors or by providing their own UI – some blocks allow both: external inputs and UI • Blocks can have high levels of abstraction (no need to create blocks to do something easy like

a+b

) • Wires can be hidden and the program still makes sense because there is always some layout, user interface, … • Various mechanisms for abstraction (wire up something, then copy the resulting block elsewhere), collapse blocks to hide data/UI, combine low level blocks (many inputs) into larger blocks (few inputs) https://vimeo.com/573378340

Holy shit! This looks like a promising start. I like that you've picked a specific spot in the conceptual space for this to sit — in between existing code and existing data, to make working with both better. I can see this being a really powerful alternative to something like Paw / Postman, and a good tool for building integration tests. I'll be keen to see what you use it for, and how you choose to refine it as you go. What sort of feedback are you looking for at this point, if any? What sorts of questions should we be asking?

Ha, Paw/Postman are good references. Fetching data, extracting parts of it and listing results are common tasks when building apps (aren’t the majority of apps just lists?), which is why some of my first blocks were for data fetching, extracting and listing API results. With Ratio, I want to be able to move fluently from looking at data to the next step which is manipulating and rendering the data in a user interface. The interesting part is that I can build up a Mini-Paw, mess with the API/Data and once finished, can move on. Besides lists, I’ve been working with HTML and CSS parsers, building AST explorers / editors on top, eventually moving on to more visual design/dev tools. Incrementally progressing. The goal is to have useful tools at any time. Starting with raw code, followed by simple structure editors, onto more specialized UIs. I’ve also built personal apps: time tracker, notes, todo list, reading list, … only to realize that this is becoming an user-programmable operating system. 😅 I’m currently not looking for specific feedback on the UI as I’m trying to focus on the bigger conceptual ideas. Maybe some questions in return: • What general questions do you have? • What would you like to see me build as a proof of concept? • Where do you think this approach might fall short?

Florian! I want this and I will pay you to use it! This is exactly what I’ve been looking for in a rapid prototyping tool (which is what I attempted to articulate in a tweet of mine, but you did a much better job of it: https://twitter.com/crabl/status/1352496218488803328?s=20), and it looks like it’s even more powerful than what I had in mind with all of the programmatic features that you’ve built. Incredibly cool project.

@crabl Thank you Chris. Your demo shows the beauty of the browser: its layout engine. A lot of the complexity of writing HTML is nesting, moving, renaming, … and all that can be simplified by turning the code into tangible objects that can be selected, clicked on, copied, pasted, manipulated. I love that you use prompts in your prototype. It’s raw, yet functional. I’m glad that you see potential in the prototyping capability of my environment. If any, what JavaScript frameworks are you using for prototyping?

Angular is a big one for me, mostly because the intervention with Typescript is first-class, and because writing out type signatures is a big part of my prototyping process. That said, I could likely settle for Vue since it's conceptually a lot simpler, and it accomplishes most of the same goals (two-way binding, event handlers) as Angular for the purposes of prototyping. The reason I'm so interested in this kind of tooling is because it is directly relevant to my day job: at work, we have implemented a version of Basecamp's "Shape Up" process, which suggests using "breadboards" as a way for product managers to convey ideas to designers and developers (https://basecamp.com/shapeup/1.3-chapter-04#breadboarding). I have tried using Sketch and Figma for this, and while it works for me because I am comfortable with using design tools to achieve this goal, the other developers and product managers in my org tend to be intimidated by large "blank canvas" apps. I've had some degree of success introducing this proof-of-concept app to a couple folks (https://breadboarding-poc.netlify.app: note, I didn't write this, I just found it) but it is limited in terms of how you can lay out the screens and what sorts of components can be placed on them. Additionally, it's not possible to share a link to a runnable/editable version of the mock-up, which is highly limiting since the product design process is very collaborative and requires the frequent exchange of ideas in order to be successful.

Thanks for sharing how you work! Great, that you’re mentioning the Breadboard metaphor mentioned in Shape Up. When I read the book a while ago, that concept stuck with me. The idea of a radio that can be wired up on a breadboard to test out the functionality and then put into a nicely designed box for production. I think breadboards are two things for me: low fidelity (few visuals, you see the wires, raw components…) and simplified layout (your parts go here). Good constraints. The breadboarding web app you shared nails it: it is so limited that all you can use it for is to deeply think about what elements go there in what order and how different views connect. I think this is what protoyping should care about. In contrast, I think wireframing often focusses too much on the “low fidelity visual style that is faster to draw” than the content.