Why we're building Zoo Modeling App
We're building a flippin' Graphical-User-Interface (GUI).
For the record, our decision to build a GUI was not made lightly. We have a steadfast commitment to code-first design. We believe that automation has to be a first-class citizen in any of our products, and code is the way to do that. In that sense, a GUI is a surprising move for us.
If, dear reader, you don't have a background in software development, you may not share our conviction regarding code-first design. And while we have elaborated previously, for the purposes of this post, I kindly ask you to suspend any disbelief and I'll circle back later.
A GUI does make sense for us because we are not giving up on code, in fact, we’re doubling down on code. We're using a GUI to enhance the code-authoring experience. We're combining the two.
Integrating code seamlessly into an application is no small feat. There are three compelling reasons why we believe code plays a pivotal role in CAD, but these benefits may be lost if the integration is subpar:
- Automated pipelines: Code allows us to ensure consistency between versions of a design. For instance, you can run finite element method analyses every time you change a design, ensuring you never send a design out to clients without automatically testing that it still meets requirements.
- Semantic Clarity: Well-written code serves as a clear, evolving record of the design's intent, making it comprehensible even as complexity increases.
- Abstractions: Instead of duplicating similar code segments multiple times, your team can abstract these into battle-tested, reusable, reliable functions that your team can depend on.
Let's compare Zoo Modeling App's code-GUI integrations with some alternatives. In each case, the GUI must support some kind of API for programmatic access to the software, otherwise it's impossible to integrate code. In CAD, all of the user's interactions are essentially creating data. The series of clicks and key-presses of the user, along with the software's logic, builds up more and more data internally. Users are able to do something useful with their data at the end by exporting it (into a drawing, STEP, BOM etc).
Poor code integration 1: Export a script
While this approach does support automated pipelines, the script is designed to be consumed by the GUI API, not by a human engineer. So it might not be meaningful to an engineer unless they're really well-versed in the inner workings of the software's API. Updating the script manually is pointless as it's merely an export, and can't be reimported into the software. This makes abstractions pointless too, since you wouldn't edit the script. One benefit of this approach is that it coexists alongside your familiar GUI workflows -- if you don't want to export the script, you'll never have to.
Poor code integration 2: Allow a scripting language within the GUI
This option offers the advantages of code, but divorces it from the user interface. Users must explicitly choose to enable scripting, which may not gain wide adoption. Even if used, it can segregate users into two groups: those who use scripting and those who don't, much like regular Excel users and advanced users who use macros and VBA.
Our code integration: Code generated from GUI interactions, i.e. Zoo Modeling App (ZMA)
ZMA is designed to empower users by translating their clicks into code, and that code then produces the 3d model. Users can rely on GUI interactions alone, never manually writing a line of code. But every time you click, you're actually writing code, without ever needing to learn the programming language.
The code is also the file format, so when you export the file you don't lose any data from the GUI or the code view. When you reopen a project (or import it from a coworker), you'll see both the code and GUI just like you remember.
The generated code can seamlessly integrate into automated pipelines1. Moreover, the code remains the source of truth, allowing users to edit it again later, still without having to write code manually.
If your coworker sends you a new variation of an existing design, it can be hard to tell what's changed. You've probably opened up the new and old versions simultaneously and played "spot the difference" before. But because ZMA parts and assemblies are ultimately just code, you can view changes as a text diff, which highlights exactly what changed. No need to play spot the difference anymore!
Users can also directly modify the code, improving variable names, and creating abstractions without affecting ZMA's ability to understand and allow further GUI-based edits.
Demo of user defined abstractions co-existing with generated code
ZMA users should never get lost or not know what part of the code is responsible for a given part of their model because there is a strong link shown visually between the 3d-scene and the code from hovering and cursor position.
Demo of editor <=> 3d-scene link
While we are aiming to match typical CAD workflows (sketch and extrude for example), there are a few instances where our code-GUI integration forces us to do things differently. For example, we can't yet support heuristics or related workflows. Typical CAD software uses heuristics to make tiny decisions on the user's behalf that you may have never noticed. We can't match all of these, because it's hard to reconcile imprecise nudging heuristics with the mathematical foundations of code. The resulting workflows should mostly be different, not worse, but I'd be remiss if I didn't mention some drawbacks.
To circle back to the non-programmers, we think that you'll greatly benefit by adding code to your tool belt, and ZMA should make that an easy transition. You should not have to learn any code to implement your designs, but if you want to take advantage of automated pipelines and abstractions, we'll be here to help.
ZMA is in its infancy right now, so there are many modeling features still missing, but please give it a try. There's enough built to show the workflow and make some basic parts. Download the latest version here.
Oh and by the way, the GUI is open-source.