Floraria: one plant, one continuous scene, and two data lanes that never mix
Published:
Floraria: one plant, one continuous scene, and two data lanes that never mix
Floraria 0.06.000 is deployed. The first two versions of this botanical instrument were a studio of separate views, and I judged both below the bar; the third is a single continuous scene. Aim at any part of the plant and scroll in, or pinch on a phone, and the enclosing structures open: the whole plant, an organ, a tissue, a cell, a compartment, with three floral constructions and four connected pathways revealing geometry, qualitative processes and sourced context as the level changes.
The data comes in two lanes that are labelled everywhere, in the interface and in every export. Five Smithsonian CC0 bloom specimens, each at two delivery fidelities (five biological examples, not ten), show outer surfaces and establish nothing about the inside. Two authored educational component models, a general flower and an orchid, carry named structures, assembly and explosion, isolation and explanatory views; they are diagrams, not segmented scans. Twelve guided investigations connect inspection, morphology, comparisons and the documented evidence.
Normalized framing is not a shared physical scale. Lifecycles and morphology explain concepts; they do not predict growth or identify plants. No internal organ, tissue segmentation or measurement is claimed from a museum scan.
Every earlier release stays reachable, each recorded with its exact commit, release identifier and the Quality and Pages runs that verified it: Node 22 and 24 source, production build, exact-artifact Chromium, custom-domain and publication gates.
160 frontend and 56 Python tests, a 31-scenario browser suite of 126 checks, phone-pointer navigation at 390 by 844. It follows a curated spatial atlas archetype rather than the six-page science shell, and the record says so. Apache-2.0 code; the museum data keeps its recorded source rights; no adoption or learning outcome is claimed.