The Ultimate Card Building Tool
Introducing Cardstack Builder & Cardstack Workflow
Meet the Cardstack Builder — the product that makes the complete, full-stack Cardstack Experience possible! All the coding work done by engineers and Web developers finally empowers the users without coding skills, so they will never have to ask a developer to build them an entire app from scratch again.
Essentially, the Cardstack Builder provides a user interface that contains all the card concepts and data models, all the front-end and back-end code necessary to build an application up from parts, enabling users to create dApps that are composed of little bits of information and functionality to form larger workflows. This card building tool is the goal — the product — we have been working towards, considering all the different aspects of Cardstack’s full-stack environment; the point has always been to address the needs of the constituents, so as to reach the maximum number of users.
It sounds simple: Card makers are the people who make cards, which are mini-apps that contain both the user’s own data and the user interface. But it all starts with the Cardstack Framework, which provides the tools. The framework, built by our relatively small framework team, enables the product team, the back-end engineers, the front-end engineers, and the Web developers to leverage these tool sets and expand on them to reach the users. This high-leverage framework provides a lot of capabilities — from server products and Node.js code to the ability to index data from both cloud and blockchain sources, as well as authentication, security, grants, and everything else you expect from a full-stack application framework.
But Cardstack is much more than a regular open-source project. We are building a product! This product allows us to provide a complete experience that can be extended through back-end engineering resources (who can connect enterprise systems) and front-end engineering resources (who can customize functionalities, add widgets, or include animation), with the goal of reaching Web developers (who can add themes and further customization) and, ultimately, the users themselves.
Most of the work necessary in this process requires coding skills. Yet, coding skills are a scarce commodity in this world, since not everyone can be a developer; in fact, most of humanity does not know how to code. That’s why we want to lift ourselves away from all the work developers or engineers or architects can do and serve the actual users — the millions of people who know how to use Excel and how to configure SaaS software (like Airtable, Salesforce, Notion, or invoicing tools) for their needs. These people know how to use software to create their own reality, but they have never learned to code. Therefore, we give these users the entire power of the Cardstack architecture in the form of card building tools, which require coding skills to be built in the first place, but no coding skills to be applied by the users. As the users use these tools, they don’t see any of the programming aspects that are happening in the background; they don’t have to learn anything about APIs; they don’t need to know how to type code and read our developer documentation. Just by understanding the card concept, they are able to be productive and construct something on their own that becomes a substitute for a Web development project they would otherwise have had to outsource; instead of hiring a firm to build it, they can now build it themselves. These card building tools are the powerful product we offer users — and that is what we call the Cardstack Builder.
The Cardstack Builder: Viewing, editing, and configuring cards
Viewing a card (04:29)
Let’s use the example of an account card, which could represent an individual or an organization, an employee or a customer, who has an account at a bank or in a company’s database. Anatomy-wise, this account card has a certain schema, meaning that it represents a certain type of data, like a tab in Excel or a table in a database. As a user, you can now view this account card, which contains various fields that give you information about this particular account, such as the person’s name, address, or additional notes concerning this person.
At Cardstack, we always say everything is a card. An account is a card, an invoice is a card, a user is a card, a membership is a card. But the concept goes deeper than that. In this example, the account itself is the obvious card. That card contains several fields, such as the person’s address. Now, that address field is also a card! It has its own individual fields (like street, zip code, city, state, and country) and it may even have a little control to do a Google lookup, which auto-completes the address as you type it. The button to send an invoice to this account is also a card. This is a significant aspect of our concept that everything is a card: All of these cards can be used as fields and embedded within each other!
Editing a card (06:25)
Let’s say someone has sent you this account card or a colleague has already entered it into the system. As you view this card that has a set of fields, you want to be able to edit those fields. In order to edit the name field, for example, you simply click on it, which turns the field into the corresponding edit view, so that it becomes an editable text field where you can now insert or change the name. Similarly, the address field opens a custom widget for an address card. Note: The address card is not actually made by you. It either comes with the system or has been shared by other people in the environment, ready for you to use — including the capability of this built-in field editor, which allows you to edit the information displayed on the card.
Configuring a card (07:03)
How did that card come into being in the first place?
The account card is constructed one column or one row at a time, similarly to the way in which you add columns on a website. When you want to create this card yourself, you first go to the Card Catalog, which offers you a full selection of pre-built cards/fields. Some of them are pretty simple, like a text field; others are more complex, like an address or event card. You choose the fields you want to include in your account card and drag them from the catalog into your card.
Having added the fields to your card, you can configure them individually. As you click on the address field, for instance, it is like opening a folder on your computer. You zoom in to view the field as a full card, showing you all the fields that make up this address card (street, zip code, city, state, country).
You can construct your own fields too! You don’t have to stick to the core fields you see in the shared catalog (which could be cards and fields that are publicly available or ones that are only available for your team). This environment, which we call the Cardstack Builder, also enables you to assemble your card with fields you have created yourself.
Say you’re in a life coaching business. You figure out yourself which fields would be ideal to describe a life coach. Then, you customize the fields, adjust the layout, set the date/time structure if you like, save the card, and end up with a self-made card that is ready to be filled out with the information for one of your coaches. In the future, if you want to assign a coach to a particular client, you can just drag the coach card into the respective field of your application. Note: This could be an existing account card of one of your coaches or a card you fill out with information about a new coach before you assign it to a client.
This is the power of Cardstack: You can create many different types of cards — some of which come with the environment, some of which you build yourself!
Interesting fact: You’re actually doing the same thing developers do! When developers configure something for you, customizing and tweaking a form, for instance, they are using software code by typing configurations into an editor. Now, because we own the full stack of the Cardstack architecture — from the top all the way to the bottom (the revision control system for the code and the official authoritative data) — we can enable you to make edits within this Cardstack Builder environment that are doing exactly the same thing that a developer would do if he/she wrote the code in a code editor. It is as if you were coding yourself! Your actions and the developer’s actions have identical consequences in the bottom layer, except that the developer uses code and you don’t.
This works because the Cardstack Builder is actually writing code for you in the background. Although you don’t see it, the system is generating code — data schemas in JSON, stylesheets in CSS, as well as templates in JavaScript and HTML. That means developers can still use their programming skills to do as much code tweaking as they like. So, if something happens while you configure your card by dragging and dropping or if you’re not satisfied with the result, you can always ask a developer to fix it the old-fashioned way, by making changes to the actual code through manual typing. Once the developer checks in those changes, they affect the model, fixing the bugs of your account card for you.
Plus, all the changes anyone makes in the Cardstack Builder — whether it’s you by dragging and dropping or a developer by writing code — are revision-controlled. You can always revert to a previous version of your card or app if you prefer.
How does the Cardstack Builder relate to the overall Cardstack experience? (10:48)
The Cardstack Builder comes with the three default modes described above: view, edit, configure. You can use this set of built-in modes for any card you create.
First, you configure the card, set up the fields, and choose your layout. Then, the edit control allows you (or your colleagues/clients/etc.) to fill out the fields with the corresponding information, such as name, address, and memos. By the way, you don’t have to figure out how to do dropdowns yourself. If you have a list with multiple items, this default edit control automatically generates a drop-down and creates a list with a nice layout for you. Finally, when you save this card, you (or your colleagues/clients/etc.) will be able to view it. Once the card is in view mode, it can be used to trigger an action, for instance by clicking the “send invoice” button (more about triggering actions in the next section). Note: Our grant system will give the people you choose the permissions you choose, enabling them to see only the cards and fields that you want them to see.
When building such a software builder program, one of the hardest things to do is to offer a combination of off-the-shelf and customizable software. You usually get one or the other — you can either customize software from beginning to end, to make it look exactly the way you want, using none of the common off-the-shelf characteristics, or you can use 100% off-the-shelf software that barely lets you add your logo or change the color. Cardstack is doing the impossible, giving you the ability to build apps quickly by dragging and dropping (no coding skills required) plus theme them later on to make them look completely custom (by getting a developer involved).
This means: In addition to the standard view/edit/configure modes, you always have the option to ask a Web developer to further customize your card. The developer can go in and build you a custom layout component, so that your card can be company-themed, for example. This custom layout could use a gradient, place your fields in a particular way, or show a fancy photo in the background.
Because all the edit controls are built into the environment, this custom layout offers exactly the same features as the built-in layout. So, if you create a field that lays out your company name in a bigger font, we automatically make that text field editable in place. When you type in a different name, you don’t need to preview it; it will show up right away in the customized font size. When this in-place editing is not possible — let’s say you have an “edit address” control and you need to look up the address using Google — we would pop it out as an overlay, where you can make your changes; and once you save them, you can see the results in the card.
Ultimately, it is all about not requiring people to redo everything from scratch. A lot of custom development has great delivery risks, especially in regards to timelines, e.g. because the developer can’t get to the UI until the back-end is done. At Cardstack, you get an end-to-end, working app with default fields right away; and then you can decide how much customization is important to you. If you only want to theme the layout for the home page or fine-tune the way your coaches are displayed on your team page, you can hire a developer to do this customization work for you quite easily. If you need more extensive customization, such as a special edit control for scheduling, you can hire a front-end developer who reads the documentation on Cardstack, creates a new type of control, and swaps the default control with the customized one that was specifically built for your business. The amount of customization you get is entirely up to you!
Here’s an analogy: Imagine you are furnishing your new apartment. Naturally, you would like to do it as efficiently as possible. So, you use off-the-shelf furniture from Ikea to get started. But there is one piece of furniture that you really want to be perfect. So, you work with a carpenter to customize it exactly to your taste. Similarly, within your assembled Cardstack application, you can choose which parts you want to use off-the-shelf and which parts you prefer to be customized and unique. That is the type of efficiency we want to bring to the market.
The Cardstack Workflow: Action triggering, card chaining, and message threads
Triggering actions and chaining cards (16:04)
How do you use your cards to make something happen?
When you have created a card, you want to be able to act on it — for example, to send the person whose account card you are viewing an invoice. That is possible because Cardstack offers you much more than just a CMS. All you need to do is click the “send invoice” button on the account card. This action generates an invoice card, copying over all the account information without transcription error and without requiring you to copy or paste anything. In other words, the account card gets automatically embedded into the new invoice card, so that the invoice can display the account information in the corresponding account information field. After that, you fill in all the other required details, such as amount and due date.
Once you have added all this information to the invoice, the next step in this multi-step workflow is setting up the payment methods you support by selecting Visa, PayPal, Bitcoin, Ether, etc. All these individual payment methods are cards as well, which means that you can build up your application like Lego bricks. You don’t have to do any integration; you just drag in the respective cards to set up the payment methods you accept, and that is it.
Embedding cards in message threads
As you go through this workflow, you are sequentially initiating the different steps via action chaining (which means that your action in one card triggers the creation of another card). But once you are sending someone an invoice, you want to be able to go back and forth, maybe to negotiate with that person or to provide new contacts and details or simply to get a payment confirmation. That is the point at which the card gets embedded within another concept called a thread.
A thread is a container similar to chats in Slack or other direct messaging applications. The invoice card that you have created — through the previous action chaining process — has all the aspects you added embedded inside it, condensed into bite-sized chunks. Now, you can insert this invoice card into a message thread and go back and forth with the other person, until further action chaining by the other person turns that invoice card into a payment card.
Important to note: You don’t have to build that payment card yourself. When you drag an accepted payment method into your invoice card, that payment method card already includes the actual payment method; in other words, it allows the other person to initiate a payment directly. When it comes to currency and payments, we are able to support many types of checkout workflows, which will look different in the card payment UI, depending on whether you pay using Visa / Bitcoin / a bank account / a subscription / etc. That capability usually requires people to do a lot of system integration, using SaaS platforms. But Cardstack’s payment cards are standalone cards, which you can interact with and include in a thread.
To summarize
The Cardstack Builder allows users without programming skills to do the same thing developers do — build full-stack Cardstack applications — using nothing but their mouse and drag-and-drop tools. With that, they get the free features of the Cardstack Workflow, where actions chain cards together sequentially.
A card first gets configured, then edited, viewed, plus (if desired) further customized and themed. Once it is complete, it can be used as part of an application and shared with various parties within or outside of an organization. This collaborative workflow may include several steps; for example, the other person may need to sign a confidentiality agreement (which would be a separate card that is added to the thread) before you can send them a payment. This thread is the final piece of the puzzle, where cards and communication are combined in a very organic, structural, and chronological workflow for coordination that is based on the idea of a chatroom.
The infrastructure for these workflows is shared — as is the Card Catalog, which is accessible for all people who use Cardstack. As this catalog of cards/fields/templates grows, it becomes a sort of app store; you could also call it a component gallery or a registry of software code. Essentially, it is a shared folder of templates. Anything that you have made — whether you are a developer or a user — can be added to this catalog if you want to allow other people to use it to build their own applications.
Status and Strategy
At Cardstack, we are building the foundation and climbing up the layers as the capability firms up. Our documentation already covers numerous use cases, enabling developers to start building Cardstack applications. Yet, we know that learning how to build something using a brand-new tool — even if it is a fully documented tool — is challenging. That is why we are building the Cardstack Builder on top, so as to allow users to bypass this learning step. To fill the gaps, they can still hire developers with JavaScript and Web development skills to extend existing features; e.g. a back-end engineer who connects their app to an existing accounting system or a front-end engineer who builds them a new booking module. But users will never need to ask anyone to build them a whole app from scratch again; they can build something out of Cardstack’s off-the-shelf software completely on their own and merely need to ask experts to customize it if they so desire. At the end, they have created a real working app they can use immediately!
These are the three tracks of development we are conducting, so as to turn the Cardstack Builder into a product we can launch for the users to use:
Track 1: Card Schema (V2) data architecture
A card schema is the underlying definition of what a card is. This is critical because it allows for the mobility of cards across different hubs as well as different workflows and threads, by encapsulating both the definition of the card (the form fields) and the template. This means that you can skin or modify a template without affecting the rest of the app. We are making this unique experience possible by combining card schemas (our data architecture) and our template layout compilation system (our rendering architecture, which is based on a lot of work that our team has done in the JavaScript front-end framework space, with our focus being on Ember).
Check out this talk or blog post about card schemas for more details and feel free to follow our work in our main Github repository.
Track 2: Boxel design system
This is a new, composable user interaction system for creating real apps based on cards. At its core, it is an attempt to revisit the question of what a design system is. Google’s Material Design started the entire design system movement, creating a consistent way of thinking about layers and buttons and ways in which things interact. The Android operating system is based on the spirit and the philosophy of Material Design. Yet, Material Design is only good for user-facing applications, which are built by developers and merely used by users, as they tap on it and look things up; it is all very efficient and mobile-focused. In contrast, we want to build a system where the users are not just experiencing an application, but actually building it, composing something themselves by dragging and dropping. They can already do this in Excel and on the desktop. But on the Web, things are not very composable; the work is usually done for you by a very talented development team. We are working to bridge that gap.
A lot of the things demonstrated by the Cardstack Builder are part of the Boxel design system. Once it is ready, we invite the community to not only test the Cardstack Builder, but also help us refine the philosophy behind it.
Track 3: Catalog of pre-built cards for common use cases
When you use a card builder, you want to start with more than just a text field and a number field. In Excel, that is exactly what you have — you can enter numbers, dates, and text, and that is it. Yet, people do amazing things in Excel, building up entire financial dashboards on those three primitives. But on the Web, we don’t think in terms of text strings and dates; we have concepts of an event, a video player, or an RSVP widget. And while many things have been built on the Web, they are not as composable as they are in Excel. On the Web, you can create a blog page out of images, but you don’t get a page of components that actually work well together; whereas with Excel, the more you build, the more powerful your application becomes. This raises the question: Can we get the best of both worlds? The answer is yes.
We are building a Card Catalog with the aim to unify and publish common cards needed for data collection, content management, asset encapsulation, workflow orchestration, and much more. There could be common cards around both crypto and regular finance, for example. You could have a card that represents your bank balance, transaction, or receipt, which you could then add to a workflow.
These cards will be built in a way that allows them to be used not only as cards, but as embeddable fields as well. Say you want to submit a proposal for a conference talk via a Rich Text template like Medium, which you can format very nicely; you can simply embed that completed Medium blog post as a field in the proposal packet you submit. That is very hard to do today. With Cardstack, you can just drag an article card into a field, provide some instructions, and send it to someone else in a workflow.
This Card Catalog will be extremely decentralized. Initially, it will be on GitHub, so all the different cards that are formatted in card schema V2 and contributed to the catalog will be in our GitHub repository. Our team will decide which cards can be approved and thus added to the official catalog. There may be a kind of holding area for new submissions that haven’t been approved yet or that haven’t been very popular, so that only people who really know what they are doing will be able to use those cards; but as it turns out that those cards have no security risks (and don’t steal people’s data, for instance), they will get promoted to the official catalog. Eventually, we will transfer the logical control that governs submissions to the catalog away from a single team of developers to a smart contract. That will be an excellent use of the type of blockchain infrastructure and the tools we are building on Githereum, the codebase of which is already open-sourced.
To summarize, the schema system is well under way and we are currently working on the UI of the Boxel design system. Once Boxel is completed, we will be able to use our own builder tools to build a catalog of cards, all of which people can then reuse as templates for their own apps. We look forward to the community’s feedback, especially as we put a beta list together and get users playing around with the Cardstack Builder (stay tuned for updates in our Telegram and Discord channels). We want to see what kinds of cards you can build with the tools we provide, while starting to share the templates, fields, and cards you have created with a broader community. Note: While all these tools are essentially software that captures data, you own that data. You can control it and see the history of everything you do through the version control that comes with every card.
The goal is to provide a real decentralized alternative to SaaS software — allowing people to pay one subscription fee to the community and allocating that money proportionally, based on whose tools/cards/templates people use. At the end of the day, they are going to look at an application, play with it, fall in love with it, and feel very powerful creating new software on their own without having to do any coding. That’s what we hope to achieve with the tools we put in front of them.
To get all our latest updates, sign up for our newsletter on cardstack.com, star Cardstack on GitHub, and join our Discord channel or our Telegram group and announcement channel.
