System overview Using the editor The Exotool language HTML templates The diagram The element catalogue

Exotool — System Overview

This is a high-level, user-facing introduction to Exotool: what it is, what you build with it, and how the pieces fit together. It does not assume any programming background beyond a willingness to write small snippets of logic where you want custom behavior.

For the details of the small language you use to describe behavior, see the companion references:

• Using the Exotool Editor (exotool_docs("editor")) — building apps in the visual editor.
• Exotool Language Reference (exotool_docs("language")) — the activity language.
• HTML Templates Reference (exotool_docs("templates")) — dynamic content and appearance.

Contents

1. What Exotool is
2. The big idea: design once, run everywhere
3. How you build an app
4. The building blocks
5. Activities: adding behavior
6. Location transparency
7. Data and persistence
8. Dynamic content: templates and parameters
9. What Exotool produces
10. A worked example
11. Where to go next

1. What Exotool is

Exotool is a RMAD platform — Rapid Mobile Application Development. You use it to build Progressive Web Apps (PWAs): applications that run in a web browser, work across phones, tablets, and desktops, and can be installed and used much like native apps.

The defining quality of Exotool is that you build your app visually. Instead of hand-writing the layers of code that a modern app normally requires — the screens, the navigation, the device-side scripting, the server-side logic, and the messages that travel between them — you design your app as a set of diagrams in the Exotool editor, and Exotool builds the working application for you.

You concentrate on what your app should look like and do. Exotool takes care of how that becomes a running program.

2. The big idea: design once, run everywhere

A typical web/mobile app is really several programs that must cooperate:

• the screens the user sees,
• the logic on the device (what happens when a button is tapped),
• the logic on a server (saving data, enforcing rules, sharing data between users),
• and the communication that shuttles information back and forth between the device and the server.

Normally you build and maintain all of these separately, in different languages, and you have to design the messages between them by hand.

Exotool collapses this into one design. You describe your app once, in one place, using one simple way of expressing behavior. When you build the app, Exotool automatically:

• generates the screens,
• generates the device-side program,
• generates the matching server-side program, and
• works out the communication between device and server for you.

You never have to decide "should this run on the device or on the server?" or write the plumbing to connect them. That is the single most important thing to understand about Exotool, and it is covered in Location transparency.

3. How you build an app

You build an app in the visual editor, whose interface is itself a web page — so there is nothing to install to start designing.

Working in the editor, you:

1. Lay out your screens. You add visual elements — pages, panels, lists, images, buttons, and so on — and arrange them to form the app's interface.
2. Set properties. Each element has properties you fill in (a title, a color, what data it shows, and so on) through a property panel.
3. Add behavior. Where you want something to happen — a tap, opening a screen, submitting a form — you attach an activity and describe what it does in the Exotool language (exotool_docs("language")).
4. Build and run. Exotool compiles your design into a complete, working PWA.

You repeat this — adjust, build, try it — until the app does what you want. The design is the source of truth; the running app is generated from it.

4. The building blocks

An Exotool app is composed from a palette of elements. They fall into a few broad groups. (The exact set available evolves; the categories below are the way to think about them.)

Structure and navigation

These define the shape of the app and how the user moves through it:

Content

These present information and let the user interact with it:

Behavior

These are not seen directly; they make the app do things:

5. Activities: adding behavior

Whenever your app needs to do something beyond displaying a screen, you use an activity. An activity holds a short piece of code written in the Exotool language (exotool_docs("language")) — a small, readable language designed for exactly this purpose.

You attach behavior in two main ways:

• On an element, through hooks like Do On Action (runs when the user taps or activates the element) and Do On Entry (runs when a screen is shown).
• As standalone activities connected in sequence, when you want a series of steps to happen in order.

A piece of activity code looks like this:

image = imageprompt()
if (upload_error) {
    alert(upload_error)
} else {
    image.itemtitle = image.original_filename
}

You write logic like this — assignments, if/else, calls to built-in operations like alert(...), working with your data — and you never specify where it runs. See the Exotool Language Reference (exotool_docs("language")) for the full set of statements, operators, and built-ins.

6. Location transparency

This is Exotool's headline feature, and the thing most worth understanding.

In your design there is one body of logic. You do not split it into "device code" and "server code." When Exotool builds your app, it analyzes that logic and decides, automatically:

• which parts must run on the device (anything tied to the screen, taps, and immediate interaction),
• which parts must run on the server (anything that stores shared data, enforces rules, or must be trusted), and
• what information has to travel between them — Exotool generates that communication for you.

The practical effect: you write save this picture or delete this item as a single idea, and Exotool produces the device-side action, the server-side operation, and the request/response that links them — without you designing an API.

A few things are worth knowing about how this plays out:

• Most logic can live in either place, and Exotool will place it sensibly.
• Some behavior is inherently device-side. For example, logic that reacts the instant a value changes (see always in the language reference) runs on the device. Because of that, values it depends on are made available on the device, so you should not feed sensitive data (like passwords) into such behavior.
• You can give hints when you need to. If a particular value or piece of logic must live on the device or on the server, the language lets you say so explicitly (see declarations in the language reference). Most of the time you won't need to.

7. Data and persistence

Apps need to remember things. In Exotool, persistent data is stored as cloud objects — structured records kept safely on the server and made available to your app as needed. Collections of related cloud objects form cloud sets, which you can search and list.

From your point of view in the editor:

• You describe the kind of data you are working with (for example, a picture with a title and an image file).
• You read and write it in activities as ordinary values — assigning fields, creating new records, deleting them.
• A data-driven List can display a cloud set, and updates as the data changes.

Exotool handles the rest: storing the data, retrieving it, keeping the device's view of it current, and converting it back and forth between the device and the server. You don't write database queries or wire up storage by hand.

8. Dynamic content: templates and parameters

To make content that adapts to your data — a list of products, a personalized heading, a card per record — Exotool uses HTML templates. A template is ordinary content with simple {{ ... }} placeholders that get filled in from your data when the app runs:

<h2>{{title}}</h2>
{{#each pictures}}
   <div class="card">{{name}}</div>
{{/each}}

Templates also support parameters — named, configurable values you set in the editor's property panel (a heading, a default message, an image to use). This lets you build a reusable element once and configure it differently wherever you place it.

Templates and parameters are covered in full in the HTML Templates Reference (exotool_docs("templates")).

9. What Exotool produces

When you build your design, Exotool generates a complete Progressive Web App:

• It runs in a browser on phones, tablets, and desktops.
• It can be installed and launched like an app, and behaves like one.
• It has a device side (the screens and on-device behavior) and a server side (storage and trusted logic) that are generated together and already know how to talk to each other.

All of this is produced from your visual design. You work at the level of screens, data, and behavior; the generated program underneath is Exotool's concern, not yours.

10. A worked example

Consider a simple Picture Database app:

• A Home screen shows a List of the user's pictures, each with a title.
• A toolbar button lets the user add a picture. Its Do On Action activity prompts the user to choose an image, and — if the upload succeeds — gives the new picture a title from the uploaded file's name. If something goes wrong, it shows the error.
• Swiping a picture reveals a delete control. Its activity asks the user to confirm, removes the selected picture, and tells them it was deleted.

To build this you would: place a Page, drop a List on it bound to your pictures, add a toolbar button with an "add" activity, and add a "delete" activity to the list items. The add and delete logic is a handful of lines of Exotool language — nothing about uploading, storing, fetching, or syncing the pictures between device and server, because Exotool generates all of that from the design.

When built, this becomes a real, installable picture-management app with its data stored safely on the server and kept in sync on every device that opens it.

11. Where to go next

• Using the Exotool Editor (exotool_docs("editor")) — a practical guide to building apps in the visual editor: the canvas, sheets, connecting screens, and best practices.
• Exotool Language Reference (exotool_docs("language")) — everything you can write inside an activity: values, expressions, if/else, loops of behavior, built-in operations, and more.
• HTML Templates Reference (exotool_docs("templates")) — building dynamic, data-driven content and configurable parameters.

Together, these let you go from a blank canvas to a working, multi-device app — designing what you want, and letting Exotool build how it runs.