ZAYEED preview
Home / Managing

Running the test, not just writing it

A quiz tool stops at the question. An assessment system has to answer five more questions: who signed this question off, what is this paper a specification of, who is sitting it and on what terms, who marked it and did the second marker agree, and where the pass mark came from. All five live in the engine, so every shell has them — including the phone.

A question bank with a workflow

A question is not a row that exists or does not. It is a draft somebody wrote, a review somebody asked for, a set of verdicts from named reviewers, and an approval. Zayeed models that directly.

A paper built to a specification

The strongest thing a serious awarding body asks for is not a bigger bank. It is a guarantee that every sitting covers the syllabus in the same proportions. A blueprint is that guarantee, written as rows anybody can read aloud.

A register, groups, and access arrangements

Who is entered, in which group, on what terms — and the variations granted to individuals, each with the reason it was granted.

Human marking, double marking, moderation

Everything the automatic marker declined to decide arrives in one pile, under one policy that travels inside the .mcq file.

Where the pass mark came from

Most assessment sets a pass mark by tradition — sixty per cent, because it has always been sixty per cent. That is fine for a class test and indefensible for anything that decides a career.

Sections, with their own clocks and their own doors

A real paper is rarely one undifferentiated list of questions. It has a listening section that runs for ten minutes and then stops; a reading section you may work through in any order; a recall section you cannot go back into once you have left it. A set becomes a section as soon as it carries one of three rules — and a paper whose sets carry none of them behaves exactly as it always did.

The same pack, played in front of a room

Not every assessment is a sitting. Sometimes the paper is a warm-up in a lecture theatre, a check for understanding in period four, or a show of hands at a conference — and for that, the friction of accounts and installs is the whole problem. A pack you already own can be opened as a live room: the host gets a six-character code, everyone else joins from the phone already in their hand.

The one part that needs a server — which can be your own laptop. A live room is a relay between screens, and there is nothing to relay with no network. That relay can be the machine at the front of the room: one command, phones joining over the local network, and nothing crossing the router. Rooms are held in memory and never written to the database either way, so restarting the relay ends every room in progress — deliberate for a poll about salaries, and worth knowing before a keynote. Which one to run.

All of it, on every shell

These are controllers in the shared core, not screens in one app. The web build, the Windows and Linux desktop and the Android build each render the same review queue, blueprint table, register, marking pile and standard-setting panel, against the same local database — offline, and with the same refusals in the same words.

Why the phone too. Reviewers read questions between lessons, examiners mark where they are, and half of any standard-setting panel will use a phone whatever the software intended. A management feature that only exists on a laptop is a management feature half the team does not use.

Write one question. Mark it four ways.

Install the desktop build, open the browser app, or scan into the Android shell. They are the same library, the same marks and the same rules — with or without a network.