Problems and progress
Studio has three ways of telling you something happened, and which one it uses depends on what you have to do about it:
| What you see | How long it lasts | What it's for |
|---|---|---|
| A toast | A few seconds | Something worked, or something you can undo |
| A Problem | Until it's fixed | Something that needs you |
| An inline error | As long as the bad value | A value you just typed that Studio can't accept |
Toasts
Everything Studio reports is also spoken. A screen reader is told about every notification the moment it is posted: errors interrupt whatever is being read, and everything else waits for a pause. That matters most for failures, which live in Problems instead of a passing toast: before this, a failure was shown in a panel and announced nowhere, so a reader who was not looking at that panel had no way to know anything had gone wrong. The message is prefixed with where it came from, since a listener has none of the visual grouping the panel's own column provides.
A toast is one line in the bottom-right corner of the window: an icon, the message, and a × to send it away early. It never covers the canvas and never takes the keyboard, so you can keep working while it's up.
It retires itself. A success or an informational note rests for about four seconds; a warning gets about eight, because it's the one you're most likely to have looked away from. At most four are on screen at once. The oldest steps aside to make room for a new one.
Some toasts carry a button, and the button is a real Studio command: it wears that command's own name, and if the command isn't available right now the button is disabled with a tooltip saying what it needs.
Toasts are for outcomes you don't have to act on. Anything you do have to act on becomes a Problem instead, so it can't disappear while you're looking somewhere else.
Problems
A Problem is something that must be fixed, kept on a list until it is. Failed saves, validation errors, a render that didn't work and a push that was refused all land here with the file they came from.
A command that refuses also lands here, whichever surface you ran it from: a menu row, a keyboard shortcut, a palette entry, a status bar item or a Retry button on another Problem. The row names the command and what it needed, and it is grouped under the surface that ran it ( Keyboard , Palette , Command Bar , Problems ), so a shortcut that does nothing is a row you can read rather than a key that went quiet.
Open the list two ways, both showing the same rows:
The ⚠ n count in the status bar, whenever it is above zero. Click it and the list opens on the problem.
The Problems tab of the Bottom dock ( ⌘J / Ctrl+J ).
The count only appears when there is something to count, so an empty project says nothing about problems at all.
Each row gives you:
an icon and color for how bad it is;
the message;
the file it came from , as a button that opens it;
a detail you can unfold, when there's captured output behind the message (a validator's report, a command's log);
a recovery button when there's something to run, either a Retry or a Fix , again labeled with the command's own name. A Problem with nothing to run shows no button at all;
a × that dismisses that row alone.
Rows are grouped under where they came from ( Save , Source Control , Canvas , Assistant ) in the order they arrived, so a new Problem never shuffles the ones you're reading. Something that keeps failing replaces its own row instead of stacking up sixty copies of itself. Clear n at the top of the list empties it.
Problems belong to the project you have open. Closing the project clears them, so a failure never follows you into a different repository.
Checks over your own content
Some Problems are about the document rather than about Studio. Saving a file checks its
popovers
and files what it finds under
Popover
: a panel whose base style sets
display
, which cancels the browser's own hiding and lays the panel out on every page;
popovertarget
on an element that cannot invoke one; a target naming no popover; an exit animation that will be cut short.
Where the fix is mechanical the row carries a
Fix
button that performs it in one step you can undo with one press: moving
display
into
:popover-open
, removing attributes that do nothing where they are, writing
popover="auto"
. Where it is not, the row is a sentence with no button, because a button that does not do what it says is worse than none. Which panel a control should point at is your decision, not something Studio can guess.
You can run the same check on demand: press
⌘K
and choose
Check Popovers
.
Check Accessibility
is its neighbour and files under
Accessibility
instead, with the WCAG criterion behind each finding; the rules it applies are listed on the
Accessibility
page, and
jx validate
applies the same ones. Both are also tools of the
AI assistant
: ask it to check the open page and it runs the same command, reads back the rows it filed, and can fix what it finds in the same request.
Losing the backend
The desktop app talks to a small local server for everything that touches your files. If that connection drops, whether the machine slept or a long job tied the server up, a Problem appears saying so, and Studio reconnects on its own. Once it does, the Problem is retired and a toast says you're back.
It matters that it says anything at all. There was a stretch where a lost connection was completely silent: file operations neither succeeded nor failed, so a button like Open Project simply did nothing, with no error anywhere and no way back except restarting the app. Editing in an already-open document keeps working while the connection is down; anything that reads or writes a file will fail until it returns, and now it fails visibly.
The Bottom dock
⌘J / Ctrl+J opens a dock across the bottom of the working area. It sits under the canvas and the panes only , so opening it never narrows the Navigator or the Inspector, and it starts out closed, because an empty list shouldn't spend a fifth of your canvas saying nothing. The × at the right of its tab strip closes it again.
Its tab strip is Problems and Activity , with Logic between them whenever a formula or a function is open.
Logic
Logic
holds the two editors that compute values: the
formula workspace
for a structured
$expression
, and the
function editor
for a JavaScript body. Open either one, from the Data panel or from an event binding in the Inspector's Logic tab, and the dock reveals itself on this tab.
Being a dock tab rather than a full-screen surface is the whole point: the page stays on the stage while you author its logic , so the value you are computing and the element that shows it are on screen together. The rest follows from that:
The tab is there while something is open in it and leaves the strip when you close it . Close , in the editor's own header, is the only thing that clears it. Collapsing the dock, switching to Problems and coming back, or leaving the document and returning all keep your place.
The target belongs to the document , so each open document has its own: switch documents and Logic goes with them.
The dock reveals itself once per thing you open . Close the dock over an open formula and it stays closed until you open another.
There is no Diff tab here. Reviewing a change is a Diff editor on a document at full pane size, and its change count and stepper are drawn over the comparison itself. Two panes can be comparing two different files, which a single dock tab could not show. See Source control .
Activity
Activity is where a long operation lives while it runs: an install, a clone, a publish, an import. Each one is a row showing:
what it is, who's running it, and how long it's taken;
a status line of what it's doing right now;
its steps , in order, each ticked off as it completes;
its log , the same output the operation printed, behind a Show log disclosure;
Cancel , when the operation can honestly be stopped. An operation that can't be stopped doesn't offer a button that pretends otherwise.
The tab also carries the Deploy checklist above the run log. A deploy is a long operation with a log, so it belongs with the others, and the checklist is readable before anything has started because its job is to say what is missing first .
A finished operation stays on the list , with its log, so "what did that import actually do?" is a question you can answer long after the run ends. Clear n finished tidies them away; anything still running is kept.
When an operation fails, the row records the failure and raises a Problem carrying the log , so the account of what went wrong outlives the operation and can carry a Retry.
What still blocks
Almost nothing does. The one operation that puts a dialog in front of the whole app is installing dependencies , and even there you're not trapped:
Run in the background hands the app back and keeps the install running in Activity, where you can watch it. Pressing Escape does the same thing: it stops the blocking, not the work.
Cancel stops it, when it's stoppable.
Either way the operation leaves an Activity entry behind, so dismissing the dialog never throws away the record.
Errors at the field
When you type a value Studio won't accept, the reason appears directly under that control , in red, and stays there as long as the value does. You never have to look somewhere else in the window to find out what was wrong with something you typed here.
Checked when you commit, not while you type. A field waits until you leave it or press Enter before it objects, so nothing goes red in the middle of a word.
A form you haven't touched shows nothing. Opening a panel never paints its empty required fields red.
A repeat is counted. Refuse the same value twice and a small ×2 joins the message, so "it just said no again" is distinguishable from "that message is still there from last time".
Some forms hold the old value while you fix the new one; others apply what you type and report afterward. Whichever it is, the message is at the field.
If a panel is showing a yellow New changes strip, that's Studio waiting: something changed elsewhere while your cursor was in one of that panel's fields, and it would rather let you finish your sentence than rewrite the box under your hands. Click out of the field and the panel catches up.
What the status bar does instead
The status bar along the bottom carries ambient state only , three fields in scope order: your project, then the document, then the selection. It's the project name and branch, how many people are editing alongside you, and the jump bar : a breadcrumb trail from the open file down to the element you have selected. Every item is clickable and runs a command: the peer count opens what's happening in this document, the problem count opens the list, and a crumb selects its element.
The selection field carries what a trail can't state: 3 selected when more than one element is picked, or the style rule the Style panel is editing. The trail names the primary element, the one the Inspector and the block action bar are pointed at, and the count is what stops it reading as though it described everything you have selected.
No message ever flashes past down there. Outcomes go to toasts and Problems, which are readable for as long as you need and can be acted on; the status bar answers "where am I and what state is this in?", which stays true until something changes it.
Related
The workspace : every region of the Studio window
Keyboard shortcuts : the full generated list
Dependencies and imports : the one operation that still blocks
Source control : where a failed commit or push sends you back to
packages/studio/src/surfaces/panel-problems.json
packages/studio/src/surfaces/panel-problems.ts
packages/studio/src/surfaces/panel-activity.json
packages/studio/src/surfaces/panel-activity.ts
packages/studio/src/surfaces/panel-deploy-checklist.ts
Suite