How we created Blocks: an online drag-and-drop smart contract editor.
Good news: you no longer need to know Solidity (or any programming language) to design blockchain smart contracts.
Blocks is an online visual node editor which simplifies the learning curve for building decentralized applications (dapps) on the Internet Computer. After receiving a $25,000 development grant from the DFINITY Foundation, I embarked on a journey with Nate St. George to create the first low-code graphical editor for decentralized software.
Here is the story of how we built Blocks, what you can do with it, and where we plan to go from here.
What’s a Smart Contract?
For a quick refresher, a “smart contract” is a piece of software which runs directly on a blockchain or similar peer-to-peer (P2P) network. This is often associated with the Ethereum blockchain and its “Web 3.0” dapps, some of which received viral news coverage such as CryptoKitties in early 2018.
Dapps are becoming increasingly practical for real-world applications. While the Ethereum network is known to take at least 5 minutes to confirm every transaction, a recent competitor called the Internet Computer (IC) makes it possible to process requests in about 1–2 seconds. This is a promising sign for the future of decentralized software, and hundreds of dapps already use the IC technology stack among thousands across all blockchain ecosystems.
Why a Visual Editor?
The fundamental goal of software engineering is to define clean, well-understood business logic to solve a given problem. We do this by creating layers of abstraction, equivalent to saying “make a peanut butter sandwich” rather than “take two pieces of bread, place them on a table, open a jar of peanut butter,” and so forth. These high-level descriptions make it easier to reuse, combine, document, and test our software.
Visual editors are often used to connect high-level modules written in a conventional programming language. These environments make it possible for non-technical users to understand a program’s logic while doubling as a powerful learning tool and reference point for the underlying codebase.
Especially in the field of blockchain dapp development, every line of code must be carefully scrutinized for possible vulnerabilities. A single mistake or oversight could spell disaster for your project, making a graphical editor highly practical for spotting security issues and encouraging better code encapsulation.
Competition
While experimenting with visual editors in my User Experience (UX) Design class last year, I learned something unexpected: almost no equivalent coding style existed for dapp or smart contract development. While a quick Google search reveals a simple drag-and-drop editor called EtherScripter and abandoned landing pages such as SmartChain and HyperLedger Composer, it’s immediately clear that none of these projects are currently usable for building and deploying real-world smart contracts.
However, there’s obvious market interest. In 2018, Erik Marks wrote a Medium article called The Case for Graphical Smart Contract Editors, in which he advocated for developers to experiment with ways to solve the UX problems associated with visual flow-based editors. For example, Erik highlights a near-universal concern that “for technical users, they’re less convenient than text, and for non-technical users, they’re hardly more intelligible.” I have personally experienced both sides of this problem and quickly realized that an extremely short user feedback loop will be crucial to the success of a new visual smart contract editor.
Generative Research
In order to maximize the chance of creating something vaguely user-friendly, I ran a generative research study consisting of six people from academic, professional, and non-technical backgrounds. During each interview, I asked the participant to explore Motoko Playground (an online code sandbox for Motoko smart contracts) and Unreal Engine Blueprint (a popular visual node editor), only giving minimal directions when necessary.
While everyone took a slightly different approach to understanding these applications, I was fascinated by the cases of unexpected, highly specific feedback repeated by multiple participants. For instance, while I hadn’t noticed or minded that the toolbars on Motoko Playground were non-resizable, several users mentioned that this was a major problem for them. Eventually, I found the common thread: they were using laptops with relatively constrained screen space.
These insights made me truly appreciate the power of UX research studies as part of the software engineering process. Especially when developing a highly unconventional user interface, I was amazed by how much I learned from simply asking a few people for 20 minutes of their time.
Here’s a summary of what we learned:
- When it comes to visual editors, form is function. Keyboard shortcuts and ergonomic design make or break the workflow, similar to text-based IDEs.
- Natural language is more approachable than code syntax and identifiers.
- People always want more examples! The most common use cases should be available as templates.
- A real-time feedback / evaluation loop is critical for exploratory learning.
Timeline & Priorities
At this point in the process, Blocks received the $25,000 DFINITY Developer Grant. Now collaborating with my long-time friend and colleague Nate St. George, I started planning out a technology stack for the full-scale implementation of the “Blocks” editor.
Below is our early roadmap for the application:
Here is a comparison of our beta-release features with UE4 Blueprint, Motoko Playground, and Remix IDE:
We also used the following How Might We (HMW) questions to further refine the list of planned features:
1. How might we help educate the software engineering community about the tradeoffs between centralized and decentralized applications?
2. How might we make dapp development more approachable for non-blockchain developers?
3. How might we reduce the learning curve for smart contract languages such as Solidity or Motoko?
Technology Stack
Since current open-source visual flow editor libraries are rather sparsely documented and maintained, I spent several days fiddling with various alternatives to find the best fit for the project.
- Node-RED — used by a similar abandoned project; extremely opinionated
- React Flow — beautiful flowchart library for React; similar use case to Node-RED
- LiteGraph— fantastic built-in widgets; specialized as a dataflow editor rather than AST generator
- Rete — popular and relatively unopinionated; powerful but requires custom hooks and configuration
- Flume — a newer, shinier, and somewhat popular alternative to Rete.js; missing important features such as custom styling
We eventually settled on the Rete.js ecosystem, leading to the current technology stack:
- GitHub — issue tracking, project management, hosting, CI
- Husky — Git commit/push hooks
- Webpack — build system
- Jest — testing library
- ESLint, lint-staged — code style enforcement
- React—rendering framework
- Bootstrap — style conventions
- Sass, styled-components — supplementary to Bootstrap
- Feather — clean, minimalistic icons
- Rete—node and connection rendering logic
- Monaco — syntax-highlighted code editor
- WebAssembly — static smart contract validation
Design Process
A visual low-code environment for the Internet Computer will reduce the initial learning curve and make the ecosystem more approachable for new developers.
Eager to make progress on the implementation, we began designing and developing in parallel. To give a sense of how much the project has evolved over the past few months, below are some screenshots from previous versions of the editor:
While I focused on the editor workflow, compiler functionality, and block implementations, Nate contributed themes, graphics, and the project’s landing page. Since functionality and user experience are both critically important for visual editors, our technical specialization ended up being highly efficient for this project.
If you want to participate in the current open beta testing, here is a link to the Blocks web application.
Evaluative Research
Our first round of user testing was far more useful than I ever would have guessed. At this point, the app was closely based on Unreal Engine Blueprint, so we expected users to have similar expectations and reactions. Instead, we ended up uncovering problems and solutions that allowed us to propel our user experience beyond the status quo of most visual node editors.
- Firstly, although the editor includes intelligent type-based block suggestions, most users didn’t realize how this worked and instead agonizingly searched for every block in a global placement menu. Counterintuitively, by removing this global menu and forcing users to use our contextual suggestions, we managed to significantly improve the learning speed and overall productivity of our users.
- Many of our alpha testers had zero prior experience with visual node editors. While the color-coded input/output socket connections make sense coming from Blender or Unreal Engine, several users had trouble understanding which sockets were compatible with each other. This confusion was compounded by the underlying type system, in which some colors are compatible with each other in a specific direction. We found that by adding a clear visual indication when dragging a connection, users can easily understand which sockets are compatible without needing to understand the colors or connection rules. This is a paradigm shift in user experience and needs to be adopted by other visual editors.
- The Blocks Editor also includes tooltips which provide information about buttons, nodes, and type sockets. While this is a tremendous improvement over similar visual programming environments, several users suggested that we should add a “Learning Mode” which includes even more detail in the application’s tooltips. Over time, we intend to expand this concept so that anyone can use Blocks without referencing external documentation.
Reflection
Given the tremendous challenges inherent to building user-friendly visual editors, I am proud of the innovative UX features we discovered while working on Blocks. The editor’s algebraic type system, transparent code generation, and convenient workflow allow users to design smart contracts on a scale far surpassing any other popular visual programming environment.
The main technical hurdle in this project was the current state of browser-based visual editor library ecosystems. While it was helpful to use Rete.js for rapid prototyping, we frequently ran into shortcomings such as a lack of control customization and missing features such as undo/redo history. From this experience, I would recommend that future browser-based visual editors start with a custom fork of Rete.js in order to maintain full control over the application’s functionality.
My overall personal goal was to raise the bar for online visual programming environments. While the Blocks interface will make it easier to learn Motoko and to leverage the Internet Computer for smart contract development, I hope that some of our UX discoveries will also eventually find their way into mainstream node editors over the next few years.
The Path Forward
Here’s what you can expect from Blocks over the next few months.
- One-click deployment. Rather than copy/pasting the generated code into a runtime environment such as Motoko Playground, we intend to create an end-to-end workflow for users to fund and deploy smart contracts directly from the editor.
- Real-time evaluation. The ability to instantly evaluate expressions is a game changer when learning a new programming language. We intend to make it as easy as possible to run and test your project within the Blocks Editor.
- More interactive tutorials. While it’s relatively easy to understand Blocks coming from other visual node editors, our goal is to make smart contract development accessible to those without a software development background. Expanding upon our current tutorial system, we hope that the editor will become a general learning resource for blockchain and decentralized software development.
