Page Kinds

Say what a page IS, and stop filling in the same fields. You keep making pages of the same shape — every interview needs a source and a date, every recipe needs a time and a number of servings, every book needs an author and a rating. A kind holds that shape in one place. Make a page of that kind and the fields are already there. Change your mind next month, edit one page, and everything you have already made changes with it.

That last part is the whole point, and it is what makes a kind different from a template. A template hands over its text and is finished with you. A kind stays attached.

What people use them for

• Interviews. A Kind: Interview carrying Source, Date and Medium. Six months in you realise you should have been recording who gave consent — add Consent to the kind, and all forty interviews have it.
• A reference library. A Kind: Reference, one page per source, with the PDF on the page, your highlights on that PDF, and the notes that cite it linked both ways. Point a database view at it and you have a library that was never a separate app.
• Recipes. A Kind: Recipe with Serves, Time and Source — and a starter page that already has Ingredients and Method headings on it, so you begin writing instead of setting up.
• Meetings. A Kind: Meeting that opens as an outline, because that is how you take minutes, with Attendees and Decided waiting at the top.
• People. A Kind: Person whose pages all wear the same colour in the sidebar and the graph, so you can see at a glance who is in a cluster.

Your first kind, step by step

Ten minutes, and at the end you will have a shape that fills part of itself in. The example is a reading library. Swap Interview, Recipe or Person for Reference and every step is the same.

1. Make the kind. ⌘N, and call the page Kind: Reference. The name is the whole of it — a page called Kind: anything is one. There is nothing to switch on.
2. Open its properties. On that page, press the ＋ at the right-hand end of the strip under the title. The Properties panel opens beside it.
3. Add the fields every reference should carry. Press ＋ Add property, type Author, leave it as Text, press Create & add. Do the same for Year and Source. Leave them empty. A blank field on a kind means "every page of this carries this field, and each answers it for itself" — it is not an oversight, it is the point.
4. Add one that answers itself. ＋ Add property again. Change the first menu from Filled by hand to ✦ Filled by AI: a box appears headed What to ask of each page. Write Summarise this page in two sentences. — then name it Summary and press Create & add. The question comes first because it is the thing you actually have in mind; the name is what you file it under.
5. Use it. Open a page you already have, and in its Properties panel set This page is a to Reference. Author, Year, Source and Summary appear on it, empty and waiting. Nothing you wrote on the page is touched.
6. Let it answer. Press the ✦ beside Summary. The page is read and the answer arrives in the field, wearing a ✦ so you can always tell it apart from your own words. Do not like it? ✕ clears it, ↻ asks again, and typing over it makes it yours. (If the kind asks several questions, MojoPad offers to answer them all when you set the kind — and ✦ Fill 3 at the end of the strip does it any time afterwards.)

That is the whole loop. Every reference you make from now on arrives with those four fields, and the last of them fills itself when you ask it to.

Two things that catch people, both worth knowing early. If you already have properties you do not need new ones — click any property's name and the panel that renames it holds the instruction too. And on a kind's own page you are looking at every property the document defines, not only the ones this kind uses; the ✕ there asks whether you mean to take the field off this kind or delete it from the wiki entirely.

A library that arrives already made

If your sources live in a reference manager, you do not have to retype them. File ▸ Import References (BibTeX)… reads a .bib file — the BibTeX format that reference managers and most journal websites export — and makes one page per source, all of Kind: Reference, carrying their authors in the order credited, year, where they were published, keywords, and the citation key.

And their identifiers. A .bib file usually carries a DOI for a paper and an ISBN for a book, and often the address it can be read at — those arrive too, on Identifier and URL. A source that has both a DOI and an ISBN keeps both. The count at the end says how many of them came with one, because a field that arrives in silence is a field nobody knows to look for.

They are pages, not records. Drop the PDF on one, highlight it, pull quotes into notes that link both ways, find it later by meaning. That is the difference between a reference library and a reference list — and everything MojoPad does to a page, it now does to a source.

Import the same file twice and nothing is duplicated: anything already there is counted and skipped, and you are told how many.

Make one

The quickest way is not to know any of this. On any page, click the type control at the top — the one that says + Type until a page has one — and choose ✦ Make this page a kind…. Say what pages of this kind are (Interview, Reference, Recipe) and the page becomes one. Everything already on it stays exactly where it is, and every link pointing at it goes on working.

What that command does, so nothing is hidden: a kind is an ordinary page with an ordinary name. Call a page Kind: Interview and it is one. (Same trick as Template: — no new machinery to learn, and the kind is a real page you can write on, link to and search.) The command simply writes that name for you, which matters because until you know the rule there is nothing on screen that says a page is about to become a kind — you can build a page of five properties and still be looking for where to declare it.

Either way, then:

• Give it the fields. A new kind starts with none — it is a blank form until you say what goes on it. Open the Properties palette and use its Add panel, which lists every property the document already defines as well as letting you make a new one; the ✕ beside a field removes it from the kind again. What the kind holds is exactly what its pages are offered, so the list on the kind's own page is the form. A value you type here is what its pages start with; leave one blank and it is simply a field they all have and each answers for itself.
• Give it a look, if you like. Set a Page Type on the kind and every page of that kind wears its colour and icon. Set the reading width and they all read at that width. Set a map's branch colours and backdrop and every map of that kind opens looking the same.
• Give it first words. Whatever you write on the kind's page becomes the starting text for new pages of it — headings you always use, a question you always ask, a table you always fill in.

Kind, or type?

They are two different things and the words do not help, so they now sit in one place. Click the type control at the top of any page and you get both, each headed by what it does:

• Kind — brings its properties with it. Point the page at a kind and it gains that kind's fields, its look, and any values the kind supplies. This is the one that changes what the page has.
• Type — a colour, to spot it in the list. A name and a colour, invented in two seconds, belonging to no page. This is the one that changes what the page looks like in the page list and the graph.

Most pages want only the colour. A page you will make forty of wants a kind. You can have both — and a kind can carry a type, so setting it once on the kind's page dresses every page of that kind and you never choose twice.

Use one

Press ⌘N, name the page, and choose the kind from the list — it sits beside your templates, marked stays attached. The new page arrives with the kind's fields, the kind's look, and the kind's first words already in it.

For a page you have already written, open the Properties palette and use the This page is a… menu at the top. Nothing you have written is touched; the page simply gains what the kind carries.

If that menu offers you nothing, you have not made a kind yet — it says so, and offers to make the first one there and then. A kind has to exist before a page can be one, and the menu is where people look for it, so that is where it is.

Fields that answer themselves

Some questions you would ask of every page, and never have time to. You have forty papers in a reference library. For each one you would like a two-sentence summary, the main ideas as separate points, and — before you cite it — the strongest argument against it. Nobody writes that forty times. So the question gets asked once, of the property, and every page can answer it.

Writing the question

In the Properties palette press ＋ Add property. Change the first menu from Filled by hand to ✦ Filled by AI and a box appears, headed What to ask of each page: write the instruction the way you would say it to a person who was about to read the page for you. Then give it a short name — Summary, Argument against — and press Create & add. Without a name nothing is made.

Four that earn their place immediately:

• “Summarise this page in two sentences.”
• “List the main ideas as separate points.” — set it to hold several answers, in order and each idea arrives as its own, not as one long line you have to unpick later.
• “What would a careful critic say against this?”
• “Summarise this page in Spanish.” — a second property with a different sentence in the box. There is no language setting, because there does not need to be one.

The type still means what it always meant, and it is worth choosing properly: a question answered with a date should be a date, and one answered with a word from a fixed list should be a select. Only text is unconstrained. A model handed a type it cannot satisfy is told so, and you are told it could not fit rather than given something that nearly does.

A select needs its options before it can answer — click the property's name in the Properties palette and type them in. A select with nothing to choose from can never be filled.

Getting an answer

A ✦ appears beside that field on any page that carries it — the page you made it on, and every page of a kind that names it. Press it and the page is read.

It reads the first part of a page — roughly a thousand words — not the whole of a long one. For a long source, ask the question of the page holding your notes rather than of the full text. (This is not the palette's ✦ Fill with AI, which guesses at everything once and forgets it did. This one asks its own question and remembers the answer was the model's.)

The answer comes from the model this document uses — by default the one running on your own Mac, so the page never leaves it. If you have turned on bring-your-own-model for this wiki it goes there instead, and the mark on the answer says which model wrote it. See Local AI.

Pressing ✦ is the yes, so the answer lands. There is no second confirmation: you asked the question, and the answer arrives in the field wearing its ✦. If you do not want it, ✗ takes it away; if you want a different one, ↻ asks again; and typing your own words over it makes it yours and ends the model's claim for good.

What makes that safe is that neither thing this button offers can land on words you wrote. The ✦ only appears where nothing has answered yet, and the ↻ only where the answer was the model's — the moment you edit a value by hand its mark is cleared, so it is never called out of date and never offers to be asked again. Nothing here can overwrite your writing.

A page of questions, in one press

✦ Fill 3 sits at the end of the properties strip whenever a page has questions nobody has answered, and the number is how many. Press it and they are asked one at a time, so you can watch it go and stop it if you want to. It is only ever the empty ones: a field you filled in yourself, and a field already answered, are both left exactly as they are. When there is nothing left to ask, the button is not there.

And when you give a page a kind, it offers. A kind that asks three questions of its pages says so the moment you point a page at it — naming them, and waiting. It is one press instead of three, and it is still a press: nothing is ever asked of a model because a page happened to open, or save, or be imported.

Every source, already thought about

This is the reason it is worth the trouble. Put those properties on a kind and they belong to everything of that kind. A Kind: Reference carrying Summary, Main ideas and Argument against means every source you have ever filed is a page that has already been read once.

A property you already have can be given an instruction too, which is worth knowing if you set your fields up before this existed: click its name in the Properties palette and the panel that renames it holds the instruction as well. Until any property has one, the palette says so with a line you can press.

From the kind's own page, click a property's name to open it — the same panel that renames it holds its instruction — and choose ✦ Fill on the pages of this kind…. It shows you the question it is about to ask, how many pages that is, that each one is a separate request, and how many it will skip — locked pages, and pages that are files rather than pages — and then waits. A library of two hundred sources is two hundred requests, and you should be told that before it starts rather than notice afterwards. Pages that already have an answer are left alone; a batch is for the empty ones.

This is the one place there is no answer-by-answer review — the confirmation is the review, and nobody reads two hundred values one at a time. Every value it writes wears its ✦, so the whole batch stays findable afterwards, and any one of them stops being the model's the moment you type over it.

The ✦ on the kind's own page is a different thing: it fills the kind itself, and that single answer is then shown by all of its pages. To give each page an answer of its own, use Fill on the pages of this kind… instead.

Whose answer it is, and why the mark matters

A value the model wrote wears a ✦. Hover it and it says which model wrote it and when.

The mark is doing real work, and it is worth a paragraph. Some of these questions read your page back to you — a summary is made of what the page already says. Others produce something that was never on the page at all:

Both land in a field that looks equally like a fact. In a document you will still be reading in ten years, the difference between what you concluded and what a machine suggested should be on the page, not in your memory of which button you pressed. That is the whole of it.

Type over it, on the page or in the palette, and it is yours. The mark goes, and that value is never asked about, refreshed or marked again — the same rule a page already has over its kind. Which also means the honest way to keep a machine's answer is to read it and rewrite it in your own words: do that, and it stops being the machine's.

Asking again, and when the page moves on

↻ sits beside every answer the model wrote, whether or not anything has changed. An answer you simply do not like is reason enough to ask for another, and you should not have to delete the first one to be offered a second. Press it and the model is asked again; the answer there is replaced by the new one.

Out of date is a different thing, and it says so. A summary written from an earlier draft is not so much wrong as stale, and being told which is the whole difference. When you have edited the part of the page it read — or changed the instruction, which makes every answer it ever gave out of date at once — the ✦ fades, and the ↻ beside it changes what it says from ask again to the page has moved on.

It never re-asks on its own. That would spend time and, if you use a model that charges, money you did not agree to spend; and it would overwrite an answer you might have been relying on, at a moment you were not looking.

What it will not do

• A locked page is never read — not even while you have it open in front of you. Its words stay out of every prompt for as long as it is encrypted, so a filled property on one has nothing to work from and says so. A batch across a kind skips locked pages and tells you how many it skipped.
• A page that IS a file is not filled. An imported PDF or ePub has no property strip of its own; keep the fields on a page that holds your notes about the source.
• Nothing fills itself. Not when a page is opened, not when it is saved, not when it is given a kind, not on import. Every value comes from a press — yours.
• An instruction is not a conversation. It belongs to the property and asks the same thing of every page. When you want to ask one page something particular, that is what Ask is for.

One thing worth knowing if you share documents: instructions travel with the wiki, because they are part of what a property is. A document somebody sends you may arrive carrying theirs. They do nothing until pressed, and the batch says which property it is about to run and on how many pages — open the property to read the instruction itself first.

“These eleven are already the same”

You will usually have been keeping a form by hand long before you think to make a kind — writing interviews for five months, putting a source and a date on each because it seemed sensible at the time. So MojoPad notices instead of waiting.

Open the Properties palette and, when a set of pages already matches, it says so: 4 pages are already the same shape. Each of them answers Source and Date — and nothing else. It names them, so you can check the claim by opening one. Call them something…, give it a name, and all of them are that kind from then on.

Nothing you wrote changes. Every page keeps every answer it gave; setting a page's kind back to none undoes the whole thing. What you gain is that they are now a group — you can view them together, and you have one place to change them all.

If every one of them gives the same answer to something — three recipes that all name the same book — you are asked one further question, on its own, with the count in it: should the kind say it instead? Say yes and that answer moves onto the kind and off the pages. They go on showing it exactly as before, but from one place. This is the only part that changes what your pages store, which is why it is asked separately and never assumed.

Whose answer is whose

Look down the property strip and you can tell at a glance:

• A value you set on this page is drawn normally, with a ✕ to remove it.
• A value the kind gives it is drawn lighter, and the kind's name sits beside it. Click that name to go to the kind. Type over the value and it becomes this page's own.
• Once a page has an answer of its own, the ✕ becomes a ↩ — go back to what my kind says. That is how you undo a one-off without deleting the field.

A page always wins. Whatever the kind says, what the page says for itself is what you get — including saying nothing. Clear a field on the page and it stays cleared; the kind does not talk over an answer you have already given.

What is worth seeing

Once a kind carries more than a few properties, its pages show all of them, and the two that matter are lost among the ten that are merely true. On the kind's page, each property has a small mark beside it, and it has three states rather than two:

• ◍ — nobody has picked anything out, so every property shows. This is how every kind starts, and most kinds never need to leave it.
• ◉ — picked out. Pages of this kind show this one at the top of themselves.
• ○ — not picked out, while something else is. Folded on the page rather than removed from it.

Picking the first one changes the rest. The moment you pick out Source, every other property on that kind moves from ◍ to ○ — that is what picking means, and it is worth knowing before you do it. Turn the last one back off and they all show again.

Nothing is hidden — it is folded. Whatever was not picked out appears as a quiet ＋2 more at the end of the strip, which opens it in place. So a page with twelve properties reads as the two that matter, and the other ten are one click away on the page itself, never somewhere you have to go looking. Hover that ＋ and it names what is folded, which kind picked, and where to change what it picks — so a fold you did not expect is never a mystery you have to hunt down.

A kind that chooses nothing shows everything. Nothing in MojoPad picks on your behalf: importing a bibliography builds a Kind: Reference for you and leaves every one of its fields on show, because a default that folds away a field you have just imported is the app having an opinion about your work before you have had one.

Changing a kind, later

This is the reason to use kinds at all, so it is worth knowing exactly what happens. Standing on a kind's page, every property tells you what changing it would reach, before you touch it — changes 12 pages, or changes 9 of 12 — 3 answer for themselves. The second number is the one that surprises people: pages that gave their own answer keep it, which is usually what you wanted and occasionally is why an edit “did not work”.

Nothing was ever copied onto your pages, which is what makes this possible. A page of a kind stores only the fact that it is one; every value is asked for fresh each time the page is read. Delete the kind and its pages keep whatever they answered for themselves and quietly lose the rest — nothing breaks, and nothing is left behind pretending to be yours.

What a kind does not decide

Two things are settled once, when the page is made, and then left alone: the first words on it and how it opens (as a map, an outline, or ordinary prose). Everything else stays live.

The reason is worth a sentence, because it is a promise about your work: if the starting text were live, editing a kind would rewrite prose you had written on every page of it. And a page's view is not decoration — a map's contents are positions and colours and bends, an outline's are rows. A kind that could reinterpret a page's contents from a distance is a kind that could throw away a map you spent an afternoon arranging. So it does not.

Kinds of kinds

A kind can itself be of a kind. Make Kind: Interview a kind of Kind: Source and interviews get everything sources have, plus their own. The nearest answer wins, so Interview can override anything Source says. Useful when several shapes share a core — sources, references, clippings — and you would rather describe the core once. You are never made to do this; two levels is plenty for most documents.

The same kind in more than one document

Three things people do with this. A researcher keeps a wiki per project and wants the same Kind: Paper — the same fields, the same names — in every one of them, rather than rebuilding it each time a project starts. Two people working together agree on the shape a source record should have, and one of them sends it to the other so their notes stay comparable. You start a new document and would rather begin with the shapes you have already worked out than from nothing.

A kind travels as a file. File ▸ Export Document ▸ Kinds… writes every kind in the open document into a single .mojokinds file, and File ▸ Import ▸ Import Kinds… takes such a file into whichever document you have open. It is small and it goes in an email.

What is in it: the kinds themselves — their fields, which of those fields they promote, what each one is for, and any kind-of-a-kind relationship between them — together with the name and type of every field they use. What is not: the pages of those kinds, and none of your answers. Exporting Kind: Paper does not export your papers.

Importing one you already have

If a kind of that name is already in the document, MojoPad asks once — Overwrite or Keep mine — and applies your answer to all of them. There is no field-by-field report, because overwriting is safer than it sounds:

• The writing on the kind’s own page stays. Whatever you wrote there explaining what a Paper is in your document is not replaced.
• Every answer your pages have already given stays. If the arriving definition does not have a field yours had, the pages that answered it keep their answers — the row stops being offered, it is not erased. Add the field back and every answer is still there.

Field names merge by name. If the arriving kind asks for a Year and this document already has a Year, its pages are pointed at yours — you do not end up with two fields called Year in every table and every filter. Where a name is new, the field is added, and MojoPad tells you how many of each when the import finishes.

Secrets stay behind; the rest travels

• A locked kind is not exported. Nothing encrypted is read out of the document to write into a file — the export says how many were left out rather than passing over them quietly. Unlock one in place if you want it to travel.
• A field answered by one of your servers carries the server's NAME, and nothing else. The name is configuration; the address, the command and the key are secrets, and those live in your preferences on your own Mac and never go near a document. So a kind can say ask Bookends without saying where Bookends is or how to sign in to it.
• On the way in, the name is matched against your own servers. Have one by that name and the field reconnects itself — which is what makes this work between your own documents, where the server is already set up. Have no such server and the instruction arrives without the connection, said plainly, and you can connect it yourself. A file may say which of your servers to ask and may never invent one, so nothing arriving from outside can point MojoPad at something you did not set up.

Nothing is tracked, on purpose

A kind you import belongs to the document it lands in. Nothing records where it came from or where else it lives, and nothing goes looking. Change a kind and the copies in other documents do not change with it — export again, import again, and you decide which documents get it. That is one more step than a system that syncs by itself, and in exchange every document stays whole: send one to a colleague and it opens complete on their Mac, with nothing missing and nothing to install.

Where they live

Make a page called Kind: Something and it is filed in a Kinds folder in the sidebar, made the first time one is needed. If you already keep your kinds in a folder, that one is used instead of a second appearing beside it. It is a convenience only — a kind is a kind because of its name, so moving it out of the folder changes nothing, and every kind is exported wherever it sits.

Kinds and locked pages

A kind that is encrypted supplies nothing while it is locked. Its pages fall back to their own answers, it is not offered in the menus, and none of what it holds appears on them — which is the point of locking it. Unlock it and everything returns, because nothing was ever copied out of it. See Encryption and Privacy.

Kinds or templates?

Both answer “what am I making?” and they sit side by side at ⌘N. The difference is what happens afterwards:

• A template is a stamp. It copies its text and its field values onto the new page and the relationship ends there. Editing the template later changes nothing you already made. Right for a shape you want as a starting point and then diverge from freely.
• A kind is a declaration. It copies nothing; the page stores only that it is one, and keeps asking. Editing the kind later changes every page of it. Right for a shape you want to stay true across a collection.

You can use both: a kind for what the pages are, and a template for a particular way of starting one.