Stating each product's status as it is
One NCJK product is released and three are in development. How the Work page states status the same way for each, without promising what does not exist.
Context
The four NCJK products are not at the same stage. Ritubon is released. Gloword, CollectionEve and GOIGOT are in development, and CollectionEve is being rebuilt from the ground up. A product page is tempting to write in the language of a finished product: a list of platforms, a launch-style button, an address for each one.
Earlier versions of the Work page also described each product in its own way, so the same kind of fact sat in a different place, or under a different name, from one product to the next.
Decision
- Two words for status. A product is either Released or In development. Version numbers and internal phase names stay out of the status, because they mean something to us and nothing to a visitor.
- One set of facts, in one order. Every product shows Status first, then Platforms, on the Work page and on its own page alike. Both come from a single data file, so the two places cannot disagree.
- Platforms are what works today. A platform is listed only after checking the product itself. Ritubon is listed as a web app that can be installed (PWA) because it serves an installable web app manifest and registers a service worker. A product in development lists only the platform its development version runs on.
- Plans are labelled as plans. Next steps sit in a separate list marked as a next step, never next to what is supported.
- No link until it can be used. A product that is not public has no button. It says so in one sentence instead.
- One way in. Each usable product has a single “Open” link. Its address is no longer repeated as a separate fact.
- A rebuild is not a version bump. CollectionEve is shown as “In development”, with platforms “to be announced”. Nothing from the earlier version is carried over as if it still applied.
Evidence
- The Work page and the four product pages read their status, platforms and plans from the same source (
products.tsin the site’s code), checked against each product when it was last changed. - After every deploy, an automated check compares each live page with the build, including its links to the products, so what visitors see is what was reviewed.
Reflection
Stating status honestly makes some pages look quieter than a launch page would, and we think that is right: a visitor can trust what is there.
The limit is that status changes in the real world, not in the code. When a product moves to a new stage, the data file has to be updated by hand. The automated checks confirm that the pages match the build, not that the build still matches each product.