The word live is cheap. Keeping it true is maintenance.
A project page can look finished long before the project is. A green dot, polished screenshot, or confident button can quietly turn a concept into a launch. The interface may never say something false in a complete sentence. It can still create the wrong conclusion.
I have been treating status language on this site as a product contract rather than a badge library. Shipped, preview, prototype, concept, archived, stale, and unavailable describe different conditions. They also create different expectations for the person clicking next.
A capability answers, “What can this thing do?”
A status answers, “What state is it in right now?”
Those are easy to collapse. A repository may contain a working route, but that does not prove the custom domain serves it. A prototype may perform a real interaction without using a production data source. A tool may convert supported files while an experimental format remains outside the dependable path.
The useful copy keeps both dimensions visible:
- what exists;
- what is connected;
- what remains experimental;
- what the visitor can actually open or download; and
- when that description was last reviewed.
This is why the Work pages distinguish the shipped DepoAudio utility from CasePrompts, whose free tools are live while its Workbench is still planned, even though both belong under DepoStack. The hierarchy explains ownership. The status explains readiness.
“In preview” can be accurate today and stale next month. Without a review date, the reader cannot tell whether the label is current or merely forgotten.
The site keeps volatile project and Lab status in typed data with a corresponding statusAsOf date. Public pages render the date beside the label. Tests make sure it is a real calendar date and not a future claim.
That does not automate judgment. It makes the judgment inspectable.
A release still needs someone to decide that preview has become shipped. The system can prevent the label from being scattered across six templates and a machine-readable file. It cannot decide that a product is ready because the build passed.
Status is not limited to projects.
The Park Field Guide separates observed, modeled, and unavailable crowd evidence. A fresh wait observation is not a forecast. A low-confidence model is not a current reading. A provider failure is not an empty park.
The contact form has a related problem. A provider can return an opaque response after a request leaves the browser. In that state, “failed” may be too certain, but “sent” may be worse. The interface needs language for an unknown delivery outcome and a fallback that does not encourage someone to send the same message repeatedly.
These states are less cheerful than a universal success checkmark. They are more useful.
A status treatment can use color, but the word has to survive without it.
Green does not inherently mean shipped. Amber does not explain stale. A pulsing dot cannot tell a screen-reader user whether data is loading or current, and it can make a static state look more urgent than it is.
The pattern I want is straightforward:
- Name the state in text.
- Give the relevant date or freshness window.
- Explain the consequence when it changes the next action.
- Provide a fallback when one exists.
- Use color and motion only as supporting cues.
That sequence works in a project card, an API response, a park planner, and a form error. The presentation can change. The contract remains recognizable.
A label is most useful when it helps someone decide what to do.
- Shipped: open the product, download it, or view the source.
- Preview: inspect what is available and expect the scope to change.
- Prototype: try the demonstrated interaction without assuming production support.
- Stale: use the last known information cautiously or refresh it.
- Unavailable: continue with the parts that still work or use the stated fallback.
If every state leads to the same vague “Learn more” button, the badge is doing decoration, not product work.
Specific actions also keep the terminal layer from becoming a translation exercise. The site can have personality in a kicker or readout while the button still says what will happen.
There is pressure to make a portfolio look complete. “Building in public” can become a coat of paint over unfinished work just as easily as polished marketing can.
I would rather call a preview a preview, put a date beside it, and change the label when the evidence changes. That may be less dramatic than a launch badge. It is also how the rest of the site stays believable.