Showing the work as plain steps

TL;DR:

• When DuckyHelper works in your apps, it shows each step in plain English.

• You do not see raw tool names, only what it did and where.

• A finished job shows how long it took and what it did. This is early access.

If an assistant is going to act in your apps, you should be able to see what it is doing. The question is how to show it. We chose plain-English steps, and this post explains why. The agent work it describes is in early access.

Watching it work

When you hand DuckyHelper a job, there is a stretch of time in which it works and you wait or do something else. During that stretch you may want to know it is on track. Showing nothing is unnerving, and showing everything is overwhelming.

We aimed at the middle. A short header says it is working, along with how long it has been going. Under it, a list of steps grows as it goes. The one in progress shimmers, and the finished ones get a check.

Steps you can read

Each step is a short sentence about what happened, in the words you would use yourself. "Opened the invoices page." "Filled in the totals." "Wrote a reply and waited for your OK." Next to it is a small mark for the site or app it happened in.

What you will not see are raw tool names, the kind of labels a program uses internally, such as a function name joined to an app name. They mean something to the people who built them and nothing to anyone else. A step that says what it did is more honest than one that says what it called.

Why plain language matters

A log written for developers shows that work happened. A log written for you shows what the work was. When you are deciding whether to trust a job, the second is what you need. It lets you check that it did the thing you asked in the place you meant, without learning any new vocabulary.

It also helps when something goes wrong. A plain step that says what it was doing when it stopped is far easier to act on than an error code.

What a finished job shows

When the job is done, the steps fold away into a single line, in the form "Worked for 7s", and you can open it to see the detail. Below it is the result, written out: what changed, in which app. If the job reached a send or a payment along the way, it stopped there and asked you first.

The ring on the edge of your screen turns green at the same time, so you can tell without looking at the window that it has finished.

The same calm as the rest

This follows the approach of the rest of DuckyHelper. No status dots and no spinners: a shimmer on the live line is all the motion there is. The point is to keep you informed without asking for your attention.

An example

Say you ask DuckyHelper to find last month's invoices and put the total in a sheet. The steps might read: "Opened the billing page." "Found last month's invoices." "Added up the amounts." "Wrote the total in your sheet." Each has a small mark for the page or app it happened in.

You can read that in a few seconds and know what happened. Compare it with a list of internal call names, which would tell you almost nothing unless you were the one who wrote the program.

Why we keep it short

A long, detailed log feels thorough but is rarely read. A short one is read. We keep the steps to what you would say if someone asked, "what did you do?" and fold the rest away. If you need more detail, you can open the folded line.

This also keeps the screen calm. The steps are there when you want them and out of the way when you do not.

What this means for you

You can leave a job running and come back to a short, readable account of it. If you want to know what it did, read the steps. If you only want the result, read the last line. To see how it decides where to work, read working beside you, and for jobs that repeat, read running jobs on a schedule.