Build a small internal tool with Applications
Describe a tool your team keeps in a spreadsheet, and Jigward builds it as a page with data of its own. How to ask, how to load your data, how changes and versions work, and what an Application cannot do.
Most teams keep a few tools nobody built on purpose: a spreadsheet of regression cases, a document listing who checked what before a release, a tracker someone updates by hand. An Application is Jigward building that tool properly for your team: a page, a database of its own that the page reads and changes, and named actions Jigward’s other work can use.
The example below is set at Orbit Cab, a made-up cosmo-taxi company. It shows how an Application is built and changed. It is not a recording of a real one.
Before you start
An Application belongs to one Context, the area of work it serves, such as a product with its repositories and Tasks. Any member of the organization can create one. Decide who it is for:
- A team Application is seen and opened by every member working in the Context.
- A personal Application is seen by its creator alone. Tasks and scheduled checks cannot see it either.
1. Ask for it
Open the Context’s Applications screen and choose New application: give it a name, say what it is for in your own words, and choose who can use it. You can also ask for one in a Chat.
Example request
A team tool for our regression cases. One row per case: the area, the steps, the expected result, the last result, who checked it and when. A filter by area, and a count of cases not checked since the last release.
Jigward designs the tables, builds the page from source it keeps for the Application, and makes it look like the rest of Jigward. Before designing, it looks at how the team wants its tools to look and at the Context’s other Applications, so the team’s tools feel like one set.
2. Load your data
Attach the spreadsheet as a CSV file to a message in the Application’s conversation.
Example follow-up
Here is the sheet we use now. Load it.
Jigward looks at the header and the first rows, shapes the table to fit, and loads the file. The rows go from the file to the table without passing through Jigward’s reasoning. It tells you how many rows were loaded and how many the table refused.
Data can also come from one of the Context’s custom integrations, the connections to your own HTTP APIs. Jigward sets up a fetch that calls a reading operation and stores each answer, and the integration’s key stays where it is: neither the page nor the Application ever sees it.
3. Use it and change it
The Application’s page has these tabs:
- App, the page itself.
- Data, its tables and their first rows.
- Versions, every version that went live, with a summary of each.
- Capabilities, the actions it publishes and what it has been allowed to start.
- Activity, the latest runs of its operations and actions, and the changes to its tables.
To change it, talk to Jigward in the conversation beside the page:
Example follow-up
Add a column for the build number, and mark a case red when its last result failed.
Every change that goes live is a new version, and an earlier version can be restored. A build that fails leaves the live page as it was, and Jigward says what went wrong. When a change to the tables would drop data, Jigward copies the affected rows aside first and asks you before running it.
4. Let the rest of Jigward use it, if you want
An Application publishes actions: named steps with what they take, what they give back and whether they read or change its data.
- In any Chat of the Context, Jigward can read what a team Application holds and call its actions.
- A Task, or a scheduled check (a Duty), can read team Applications and call their actions.
- A team Application can run one of its actions whenever a Task in its Context completes or breaks off, with no page open and no model involved.
- Its creator or an admin can allow the page to start a Task. Each time, Jigward shows the person looking at the page the exact words of the Task, and nothing starts until that person confirms.
Where people come in
- You say what the tool is for and judge whether the page does it.
- You confirm before a change drops data, before an earlier version is restored, and before the page starts a Task.
- The creator or an admin changes who can use it, allows it to start Tasks, and deletes it. Deleting removes its data at once and cannot be undone.
Limits worth knowing
- It is a tool for the team’s own work, not a general-purpose app platform, and nobody outside its Context can open it.
- The page is sealed. It reads its own data and calls its own operations, and nothing else: no access to the web, to the rest of Jigward, to another Application or to any external system.
- No other Application can read its data, and each Application has a limit on how much it holds.
- An operation that changes rows runs on whoever called it, with no review first. The record of runs and the numbered changes to its tables are how a mistake is found and undone.
- Planned, not built: splitting changes so that a small one is published from the conversation and larger work is built as a Task that a reviewer checks before it goes live; Jigward choosing extra packages; and parts reused across a Context’s Applications.