Web Philosophy

The MishMash website is not only the centre's communication channel — it is a research and teaching project in itself. As the channel strategy puts it, developing the site on an open platform "gives people in the network the opportunity to take part in developing the solution." This page explains the ideas behind how the site is built. For the practical guides, see Adaptive Content, Student Development, and Site Architecture.

One source of truth — pull, don't retype

Facts should live in one authoritative place and be pulled into the website, not copied by hand. Hand-copied information drifts out of date; linked information stays correct.

Current sources:

Source	What we pull	How
NVA (Norwegian National Research Archive)	Publications/results, person data, projects, affiliations	Nightly sync (scripts/enrich_directory_from_nva.py, scripts/sync_results_from_nva.py)
ORCID	Person identifiers and works when NVA is missing	scripts/fill_missing_nva_orcid.py
Wikipedia	Institution summaries	scripts/sync_institution_wikipedia.py
Partner RSS/web	Partner news and events	scripts/fetch_rss_to_events.py, scripts/fetch_partner_ai_events.py

Where this is heading — Wikidata and Wikimedia:

The same philosophy points towards the linked-data ecosystem. Planned directions (good student projects — see Student Development):

• Wikidata identifiers for people, institutions, and projects (urls.wikidata alongside urls.nva/urls.orcid), so entities on mishmash.no are unambiguously linked to the global knowledge graph. Done for people (matched exactly via ORCID) and institutions (via Wikipedia) — scripts/sync_wikidata.py.
• Pulling facts from Wikidata (institution data, logos, coordinates) instead of scraping or hand-maintaining them.
• Wikimedia Commons as the preferred home for openly licensed images (portraits, event photos), embedded rather than duplicated.
• Contributing back: as a publicly funded centre, MishMash should enrich the commons it draws from — e.g. ensuring researchers and partner institutions have correct Wikidata entries.

The rule of thumb for any new content type: find the authoritative source, link to it, sync from it — and if no authoritative open source exists, consider making our data citable and reusable so it can become one.

One text, many readers — adaptive content and stretchtext

Research communication usually forces a choice: write for peers or write for the public. The MishMash site instead experiments with adaptive content: the same page carries several parallel versions of its content, and the reader chooses a reading level. This builds on Ted Nelson's 1967 idea of stretchtext — text that the reader can stretch: unfolding more detail in place, or contracting it away.

Two mechanisms, both live on the about page:

• Reading levels — whole sections written at three complexity levels (simple, standard, advanced), switched with a control at the top of the page and remembered across pages. The levels describe the text, not the reader — roles are deliberately kept out of the ladder.
• Stretchtext — inline terms that unfold an explanation in place. Definitions are shared with the site-wide glossary, so the in-text explanations and the glossary never drift apart.

Principles behind the design:

1. The reader chooses. We do not guess, profile, or track readers. The plain-language version is the default; everything else is opt-in. This sidesteps the ethical problems of "personalised" content while keeping the benefits.
2. Progressive disclosure, one URL. All variants live on the same page at the same address — nothing is hidden behind separate "for kids" ghettos, and links always work regardless of the reader's level.
3. Degrade gracefully. Without JavaScript, the default variant and all stretchtext content is shown. Search engines and the site search see all variants.
4. Honest about cost. Every adaptive page multiplies writing and maintenance effort by the number of variants. The experiment is evaluated accordingly — see the communication strategy.

The reading levels, and how they map to tone, typical readers, and channels, are defined in the communication strategy; the technical authoring guide is Adaptive Content.

Transparent, experimental use of AI

The site is actively developed with AI — drafting reading-level variants, writing code and automation, machine translation. This is deliberate and declared: machine translation is marked on the pages concerned, AI-assisted development is visible in the public commit history, and the communication strategy states the practice. Human editors review everything before publication and remain responsible for it. For a centre that studies creative uses of AI, building its own channel this way is itself an experiment to create, explore, and reflect on.

An open, hackable site

• Static site, plain text. Jekyll + Markdown + YAML in a public GitHub repository. No database, no CMS accounts — a pull request is the editorial interface, and the whole site can be rebuilt from source by anyone.
• Student co-development. Students build alternative frontends (UI themes switched with scripts/ui) and backend automation (Python sync scripts) — see Student Development. The production site is protected by CI checks, not by restricting who can try things.
• Two languages. English is the default; key sections are mirrored in Norwegian under /no/…, in line with the Norwegian Language Act. Machine translation is used where noted.
• Accessibility. Quality checks include HTML validation and pa11y accessibility scans; adaptive content must remain accessible (keyboard-operable switcher and stretchtext, sensible no-JS fallbacks).

Why GitHub, and not a CMS?

The obvious choices for a Norwegian research centre would have been Vortex (the CMS used across Norwegian universities) or WordPress. Choosing a plain-text site in a public GitHub repository instead is partly practical — but for a centre working on AI, it is also a conceptual statement.

The practical case:

• Version control and review. Every change is a commit; every substantial change can be a reviewed pull request; CI checks links, HTML, accessibility, and directory consistency before anything reaches mishmash.no.
• Automation-friendly. The nightly NVA/ORCID/Wikidata syncs, tag normalisation, and validation all operate on plain files. Against a CMS, each of these would be a fragile integration against someone else's API and permission model.
• No accounts, no lock-in. Contributors need a GitHub account, not an institution-specific CMS role. For a consortium spanning many institutions, Vortex would tie the centre's channel to one host institution's system; WordPress would add a database, plugins, and a patching treadmill.
• Nothing to run. GitHub Pages serves static files; there is no server to maintain, break into, or migrate.

The conceptual case — why this matters for an AI centre:

1. Content as data. Markdown and YAML are as machine-readable as they are human-readable. The whole site is a corpus that scripts and AI systems can operate on directly — that is what makes the adaptive content, the chat knowledge base, and the sync pipelines possible. A CMS hides content behind a database and an editing UI; here, the content is the database.
2. Provenance you can verify. In an age of generated content, being able to prove who (or what) wrote every line matters. The git history is a complete, public audit trail of human and AI contributions — the AI colophon is only possible because of it. No CMS provides that.
3. Reproducibility. Anyone can rebuild the entire site from source. That is the same open-research value the centre applies to its science, applied to its own communication.
4. A platform for human–machine co-creation. Pull requests put human editors, student developers, and AI assistance under one review process. The website can thereby be what the channel strategy calls "a development project in itself" — a running experiment in exactly the kind of human–machine collaboration MishMash studies.

The honest trade-off: the entry barrier is higher than a CMS editing box. The mitigations are this wiki, the student guides, the automation that removes most routine editing — and, transparently, AI assistance for the rest.

The experiments, in one list

Experiment	Status	Where
Adaptive reading levels	Live on the about page (EN + NO)	Adaptive Content
Stretchtext + shared glossary	Live on the about page (EN + NO)	Adaptive Content
AI-assisted site development (transparent)	Ongoing — declared on the AI colophon	this page
Student UI themes	Infrastructure in place (themes/, scripts/ui)	Student Development
NVA/ORCID/Wikipedia sync	In production, nightly	Directory, Scripts and Automation
Wikidata/Wikimedia integration	First step live: QIDs resolved for people (via ORCID) and institutions (via Wikipedia), facts pulled to _data/wikidata_institutions.yml	this page, Directory
Chat interface over site content	Prototype (site/chat/)	Scripts and Automation

Coordination happens through the MishMash website project.