What Shipbuilder is

Shipbuilder exists for one reason: to get grip on shipbuilding projects.

A ship is the most complicated thing most people will ever help build or repair. Thousands of drawings, specifications, certificates and reports; a yard, an owner, a classification society and a row of subcontractors, each with their own numbering, their own opinion and their own copy of the truth; and a schedule in which the question which revision are we building from has to be answered correctly, every day, by people who were not in the meeting.

Shipbuilder answers that kind of question by making the project data-driven: every drawing, every revision, every space on board, every comment that came back is a record with its own identity, connected to the records it belongs with. The connections are the point. A drawing that shows a compartment, a comment that answers a revision, a transmittal that sent three drawings to class — those links are entered once and then read from every angle.

How it helps you

One place, one truth. The register is the register. A revision is either current or it is not, and the whole yard reads the same answer.
Nothing gets lost in the mail. A comment that came back from class is a record against the revision it is about — not a sentence in somebody’s inbox. Who said it, when, and what was decided are all there.
Where does this belong? A drawing knows which cost code, which spaces, which equipment. Turn it round: a space knows every drawing it appears in, and every inspection report filed against it.
What is waiting for me? The dashboard shows what you raised and nobody has settled yet. The transmittal list shows what went out and has not come back.
What happened here? Every change is kept, with who made it and when. The history of a record is part of the record.

A flexible model that enforces correctness

Underneath the screens is a data model: the kinds of thing a workspace can hold, the relationships they may have, and the rules — a document has at most one actual revision, a space sits in one deck area, a comment belongs to the thing it was raised on.

The model is flexible, in that a workspace is configured for the work it does: a document-control workspace is built around documents, revisions, transmittals and comments, and a project workspace around systems, cables and requirements. It is strict, in that it refuses what makes no sense — a second actual revision, a comment attached to nothing, a value outside the list the field allows. That strictness is where the grip comes from: you cannot accidentally create the ambiguity that costs a week later on.

The next page, The data model, draws the document-control model. It is worth ten minutes, because every screen in the application is a view of that model — and once you can see the model behind a screen, you can read any screen.

The interface: organised, role-based views

Shipbuilder’s screens are not forms. They are views onto the connected data, arranged for the person using them:

an overview page lists every record of one kind — every document, every transmittal, every space — as a grid you can sort, filter and search;
a detail page shows one record: first what it is connected to, then its own properties;
tabs on either page are prepared views of the same records, not different data;
a portal is a whole menu arranged for one role. A document-control workspace has a Main portal for the yard and a Client portal for the owner: the same records, a shorter menu, read-only where the owner should only read.

The same grid, the same detail page and the same handful of gestures repeat everywhere. Learn them once — The screen, Grids — and every menu item is familiar.

Data quality, by construction

In the end Shipbuilder is about data, and it earns its keep by giving the project’s data five properties that a shared folder of PDFs never has:


Completeness	the fields that matter are filled, and the model says which ones matter
Traceability	who entered or changed it, when, and against which revision — kept, not overwritten
Consistency	one document type list, one cost code tree, one list of people; the same thing is called the same thing everywhere
Understanding	a screen shows the connections, so a reader sees why a record is there and what it belongs to
Actuality	which revision is current is one value in one place, and every view that shows it reads that value

None of the five is free. Traceability is why a record is retired rather than deleted; consistency is why you pick a person from a list instead of typing a name; actuality is why making a revision current is a value you set rather than a file you overwrite. When the application makes you do something the long way, it is usually defending one of these.