Onlinedesktop.software · The workspace shell for school operations
School operations work is several things at once: a roster beside a schedule beside the thing you are writing. Today that is six browser tabs, and a browser tab is a poor window manager. Onlinedesktop.software is a windowed shell over the school modules your district actually has — real windows you can place side by side, a dock, saved workspaces, and a launcher built from your own module entitlements. The engine is built and committed, with tests. It is also gated off by default, and this page says so in the same breath, because you should hear both halves from us rather than discover the second one later.
Engine built · default-off · module access enforced server-side
The desktop — what makes this different from a menu of links
Most products that call themselves a workspace are a page of tiles that navigate you away from the page of tiles. You click a thing, the thing replaces everything else, and to see two things at once you open another browser tab and start arranging windows with your operating system instead. The arrangement is not part of the product, so the product cannot remember it.
The engine here owns window state directly. A window can be opened, moved, resized, focused, pinned to a dock and closed, and the dock shows what is currently open so a buried window is recoverable without hunting. Dragging a window is resolved by a snap resolver that decides where it lands against the edges of the canvas and against the windows already placed, so two windows go side by side deliberately rather than approximately. Above that sit three layout engines: a large-canvas atlas arrangement for spreading work out, a single-focus beam arrangement for concentrating on one thing without losing the rest, and a tiled mosaic. A workspace is a saved arrangement, so the layout survives the end of the day.
None of that is a description of an intention. Each of those pieces is a module in the codebase with its own committed test file, and the rendered shell is additionally pinned by accessibility tests that run an automated ruleset against the desktop and against the workspace controls — which is the part usually skipped, and the part a district is required to care about.
The state today — said plainly, before you ask
The windowed desktop is off by default. On a normal sign-in today a person lands in the console, not the desktop; the window manager opens only for a session that has been explicitly opted in, by a build setting, a per-browser setting, or a query parameter on the link.
There are exactly three ways a session gets the desktop today: the build is configured with the shell enabled, the browser carries a stored per-user setting turning it on, or the link that opened the page carries a query parameter asking for it. With none of those present, the check returns false, and the workspace route renders an honest card that describes the shell as experimental instead of opening it. The check is deliberately safe in the two places this kind of flag usually breaks: when there is no browser at all, because the page is being rendered on the server, and in private-browsing mode, where reading a stored setting can throw rather than return nothing.
We are telling you this on the front page, in the same size type as the capability, for a specific reason. A shell that is gated off is a normal and correct stage for an additive engine — it means the console and every existing route keep working untouched while the new surface is proven. What is not correct is describing the desktop as though a person signing in this afternoon would land in it. They would land in the console. If your evaluation depends on the desktop being the default experience for every member of staff, that is the thing to put on the table in the first conversation, and it is a deployment decision rather than a build.
The rest of what is here is off by decision rather than by stage. This product takes no payment: there is no checkout, no price is committed on this page, and no billing rail is attached to the desktop. It provisions no mailbox and sends no mail from the product. No artificial-intelligence engine is attached to this surface, so nothing in the shell suggests, drafts, summarises or ranks. And it is not a remote computer: nothing is streamed to you, no installed application runs inside it, and there is no general file store of arbitrary documents.
How it works
Each stage is described as it stands today, including the one where the shell is switched on for a small group rather than for everybody at once.
We open the windowed desktop against a demonstration tenant with the session opt-in set, so the first thing you see is the real engine — windows, snapping, the dock, workspaces — and not a video of one. You also see it with the opt-in off, which is the default state, so the honest baseline is part of the same sitting rather than a footnote afterwards.
The desktop is a shell over the modules a school has. So the real conversation is which modules are in scope, because that is what determines what the launcher contains. Each module key is granted explicitly, and the grant is what the API checks on every request.
The launcher groups tiles into spaces. A front-office desktop and a technology-director desktop are different groupings of the same entitled set, and that grouping is configuration rather than a build. This is the step where the desktop stops being generic.
Because the flag is per-session and per-browser as well as per-build, a district can put the desktop in front of a small group of willing staff without changing anything for everyone else, and without a second deployment. The console keeps working for everyone who has not opted in.
What is built
Engine built · gated off by default
The engine is a committed part of the codebase, not a mock-up: a window-manager provider that owns window state, a dock that lists what is open and lets a window be pinned, workspace controls, and a snap resolver that decides where a dragged window lands against the edges and against the windows already placed. Three layout engines sit behind it — a large-canvas atlas arrangement, a single-focus beam arrangement, and a tiled mosaic — so a workspace can be laid out the way the work actually looks, rather than one fixed split. Each of those pieces carries its own committed test file, and the desktop and the workspace controls are additionally pinned by accessibility tests that run the axe ruleset against the rendered shell. The engine is built. It is also gated: see the next card, which is the same sentence from the other side.
Latch real · default false on the serving path
The shell is additive on purpose. The existing console and every existing route work unchanged, and the windowed desktop lights up only when an opt-in is present for that session: a build-time environment setting, a per-browser setting stored locally, or a query parameter on the URL. With none of those, the check returns false and the workspace route shows an honest card describing the shell as experimental rather than opening it. The check is written to be safe when there is no browser at all (server-side rendering) and safe in private-browsing mode, where reading local storage can throw. This is why the page can describe a desktop without overclaiming one: the same function that renders the desktop is the function that refuses it, and today it refuses by default.
Built · derived from module nav
The command-center launcher renders one application tile per module navigation item, and a space bar filters the grid down to a single group or shows all of them. The tabs and the grid are computed from the same source, so the filter and the tiles cannot drift apart and show a space that contains nothing. The desktop home page composes that grid inside its own panel. What appears on the launcher is not a hard-coded product menu: it is derived from the module navigation the signed-in person is entitled to, which is why two districts with different module sets see two different desktops without anyone maintaining a per-district menu by hand.
Server-enforced · per-tenant module keys
The module entitlement spine is enforced in the API, on the route, not in the shell. Every gated module route carries a module requirement, and that requirement is checked against what the tenant is actually entitled to before the route does any work. The module keys are explicit named values — the library, clubs, food service, multi-tiered support, volunteer scheduling, the activity feed, achievement badges, and roster import each have their own key — so an entitlement is a specific named thing that can be granted or withheld, not a role guess. This matters more for a desktop than for an ordinary application: a desktop is a surface whose entire job is to show you everything you have. If the shell were the thing deciding, then hiding a tile would be the whole security model, and hiding a tile is not a security model. The shell shows what the server already authorised.
Built · contrast tested
The look of the shell is produced by a skin engine with its own token set rather than by hand-written styles scattered through the components, and there are committed tests over the skin pack, over the default window-manager tokens, over dock tokens, and specifically over console contrast — a readability floor that is checked rather than eyeballed. There is also a declared extension seam with its own test, so a surface can be registered into the shell without editing the window manager itself. For a district that means the desktop can carry a school’s own presentation without a fork, and the contrast of what results is a test rather than an opinion.
Honest-off · money, mail, AI, remote-VM
This product does not take payment. There is no checkout on this site, no price is committed here, and no billing rail is attached to the desktop. This product provisions no mailbox and sends no mail; the only way to reach us from this page is an ordinary email you send yourself, to a person. No artificial intelligence engine is provisioned for this surface, so the desktop makes no suggestion, writes no draft, and ranks nothing — there is no assistant in it. And the desktop is not a remote computer: it does not stream a virtual machine, it does not run installed desktop applications, and it holds no general file system of arbitrary documents. It is a windowed shell over the school modules the tenant is entitled to, which is a narrower and more useful thing.
Who it is for — and what the first week actually contains
The person this is for is the one who already runs several school systems side by side and has built a personal workaround out of browser tabs, bookmarks and a second monitor. Concretely: a district technology director evaluating whether the workspace can replace that workaround; a school business office that moves between a roster, a schedule and a record all day; and the operations staff who are the actual daily users and whose opinion decides whether a shell survives.
The first week is deliberately small, because the honest state makes a large first week dishonest. Day one is a working session against a demonstration tenant with the opt-in switched on, so the engine is seen rather than described, followed immediately by the same tenant with the opt-in off so the default is not a surprise later. The second sitting is the module set: which module keys are in scope, since that is exactly what the launcher will contain and it is the only thing that makes the desktop yours rather than generic. The third is grouping those tiles into spaces that match how the work is actually divided in your buildings.
What you have at the end of that week is a shell you have seen in both states, a written module scope, and a decision about which small group of willing staff opts in first — which the per-browser setting makes possible without a second deployment and without changing anything for anyone who has not opted in. What you do not have at the end of that week is an invoice, because there is no checkout here.
The objections we actually get
“A desktop in a browser is a gimmick.” It is, when it is a skin. The test of whether it is a gimmick is whether the arrangement is real and whether it survives: can two windows genuinely sit side by side, does a dock recover a buried window, does the layout persist as a workspace, and is snapping resolved deliberately rather than approximately. Those are the pieces that exist here, each with its own test. If after seeing it you conclude the arrangement is not worth the shell for your staff, that is a reasonable conclusion and the console is not going anywhere — it is the default path.
“It is off by default, so it is not really a product.” That is the fairest objection on this list. The answer is that additive gating is how you ship a shell without risking every existing route, and the flag is per-session, so the gap between off and on is a deployment decision rather than a rewrite. But we are not going to argue you out of the objection: if you need the desktop as the default experience for all staff before you would consider this, say so early and we will tell you plainly where that stands rather than manage you toward a yes.
“Our staff are on old hardware and Chromebooks.” This is why it is not a remote desktop. Nothing is streamed and no virtual machine runs for you somewhere else, so there is no video pipe to keep fed and no session to lose when the network stutters. The windows are drawn by the browser that is already open. That is a real constraint we designed around, not a feature we are claiming after the fact.
“A shell that shows everything is a security problem.” It would be, if the shell were what decides. It is not. Module access is enforced on the API route against the tenant’s entitlement before the route does any work, and the module keys are explicit named values rather than a role guess. The launcher renders what the server already authorised. A tile that is not drawn is never the reason a person cannot reach a module — which is the property you should demand of any workspace product, including this one, and should test rather than accept.
The data this touches, and how minors’ data is gated
The shell holds no store of its own. Every window renders a record the server already authorised for that signed-in adult, under the module entitlement described above, and closing the window ends the matter. This is a deliberate architectural choice rather than a policy sentence: a desktop that accumulated its own local mirror of student records would be a second place for that data to live and a second place for it to leak, and the arrangement a workspace saves is a layout — which windows were open and where they sat — not the contents of those windows.
Student and family data is consent-gated, owned by the school rather than by us, and is never sold, never shared with outside companies, and never made public. Minors’ records are reachable only through the same entitlement checks as every other module surface, so the desktop cannot widen access — the most it can ever do is display, side by side, two things the same person was already permitted to open one at a time.
Where this sits in the family
Onlinedesktop.software is the workspace member of a family with a clear division of labour: the office and productivity suite at companysuite.software, the product factory at inabox.software, and the distribution side of the family — the plugin marketplace at plugins.network and the preset and template marketplace at preset.network.
The relationship is structural rather than decorative: a shell is only worth having if there is something to put in it, and a marketplace is only worth having if there is somewhere for what it distributes to run. That is why the extension seam and the surface registry matter more here than a feature list would suggest — they are the join between the two halves of the family. The school platform those modules belong to is at homeroom.software, and the developer and integration layer is at schoolapi.software.
Pricing state, in the present tense
This site takes no payment. There is no checkout, no plan table, no per-seat figure and no quote generator, and nothing on this page constitutes a price commitment. That is a deliberate position rather than an omission: the cost of a workspace depends almost entirely on which modules are in scope, and a number published before that scope exists would be a number we would have to walk back.
So pricing is a conversation, and it starts with the module set, because that is the part that genuinely differs between two districts of the same size. If you want a figure to take into a budget meeting, say that at the start of the first conversation and we will work the scope in that order rather than making you wait for it.
The next concrete step
The next step is a single working session, about an hour: we open the windowed desktop with the session opt-in on, so you see the real engine — placing windows, snapping them, the dock, saving a workspace, switching layout engines — and then we open the same tenant with the opt-in off, which is the default, so you have seen the honest baseline in the same sitting. Bring the two or three module surfaces your staff actually use side by side and we will arrange those, rather than a demonstration chosen to flatter the product.
There is nothing to sign, no account is created by talking to us, and no payment is taken. If it is not right for your district, we would rather establish that in the hour.
To arrange it: email [email protected].
FAQ
The window-manager engine is built and committed, with tests: window state, the dock, workspace controls, a snap resolver, three layout engines, a skin engine, and accessibility tests over the rendered shell. What is not true is that it is on. It is gated off by default and opens for an opted-in session. Those two sentences are both accurate and we will not tell you only the first one.
Because a lot of school operations work is genuinely several things at once — a roster beside a schedule beside the thing you are writing. That work is currently done in six browser tabs, and browser tabs are a poor window manager: you cannot put two of them side by side without leaving the product, and you lose the arrangement every time you close the browser. A workspace keeps the arrangement.
No, and this is the important answer. The API decides. Every gated module route carries a module requirement that is checked against the tenant’s entitlement before the route does anything. The launcher renders what the person is entitled to; it does not grant it. A tile that is not drawn is not the reason a person cannot reach a module.
No. Nothing is streamed, no operating system is being run for you elsewhere, and no installed desktop application runs inside it. It is a windowed shell over school modules, drawn by the browser itself. That is why it is fast on the hardware schools actually have.
The shell displays what the server already authorised for that signed-in adult and holds no separate store of its own. Minors’ data is consent-gated and owned by the school, never sold and never made public. A window is a viewport onto an authorised record, not a copy of it.
No price is committed on this page and there is no checkout here. Pricing is a conversation, and the conversation starts with which modules are in scope, because that is the part that differs between districts.
Yes. The opt-in check reads local storage inside a guard, so a browser that refuses the read falls through to the default rather than throwing. The same check is safe when there is no browser at all, which is what allows the page to be rendered on the server.
There is a declared extension seam with a committed test, and a surface registry, so a surface can be registered into the shell without modifying the window manager itself. That is the supported route, and it is the one we would use ourselves.