# INFORMATION_ARCHITECTURE.md

## 1. Site map

```
/                        Home (EN default)
/no                      Hjem (Bokmål)
│
├── /projects            Projects index (teaser cards)          /no/prosjekter
│   ├── /projects/jobtrack        Case study: JobTrack          /no/prosjekter/jobtrack
│   ├── /projects/inboxintel      Case study: InboxIntel        /no/prosjekter/inboxintel
│   └── /projects/homelab         Capability page: Self-hosted  /no/prosjekter/hjemmelab
│                                  infrastructure lab
├── /experience          Experience & timeline                  /no/erfaring
├── /about               About + photo + languages + interests  /no/om-meg
├── /contact             Contact (form + direct channels)       /no/kontakt
└── /cv                  CV hub (EN/NO download, web-readable   /no/cv
                          version, ATS note)
404                       Styled, bilingual, links home
```

**Depth rule:** nothing is more than 2 levels deep. Home teases everything; dedicated pages carry depth. This replaces the current one-pager because case studies need URLs of their own (shareable by recruiters into ATS/Slack, individually indexable per language).

**Home remains a narrative one-page scroll** (hero → proof → skills → featured projects → experience summary → about teaser → contact CTA) so the P1 fast lane never requires navigation. Deep pages serve P2/P4.

## 2. Navigation model

**Header (persistent, all pages):**
```
[CB monogram]   Projects   Experience   About   Contact   |   [EN/NO]  [☾/☀]  [Download CV ▾]
```
- Monogram → home. 4 nav items max — recruiters don't explore menus.
- `Download CV ▾` is a split-button: primary action downloads the CV matching current locale; the chevron reveals the other language. Persistent = criterion "CV in ≤1 interaction from any scroll position".
- Header is sticky, shrinks on scroll (see SCROLL_EXPERIENCE.md); backdrop blurs over content.
- Mobile: monogram + CV button + hamburger (full-screen overlay panel, large tap targets, language + theme controls inside the panel top).

**Footer (all pages):** e-mail, LinkedIn, git.cesnimda.uk, CV both languages, language switch repeat, "Built by me — [how this site works]" link (small meta-page or case-study footnote; a deliberate P2 hook).

**Local navigation inside case studies:** right-side "On this page" mini-TOC (desktop ≥1200px only): Problem · Architecture · Decisions · Security · Outcome · Next.

## 3. Homepage section order & rationale

| # | Section | Serves | First-fact placement |
|---|---|---|---|
| 1 | **Hero** — name, role line, 2-line summary, location/permit/availability chips, CTAs (View projects / Download CV), portrait | P1 P3 | Everything from RECRUITER §2.1 |
| 2 | **Proof strip** — 4 compact stat/fact tiles: `8+ yrs experience` · `UK public sector` · `.NET / React / Docker` · `Based in Tønsberg, NO` | P1 | Reinforces scan pass |
| 3 | **Skills matrix** — 3 columns (Development / DevOps & Infrastructure / Practices), grouped chips with context lines, no percentage bars | P1 P2 | Keyword match |
| 4 | **Featured projects** — 2 large case-study cards (JobTrack, InboxIntel) + 1 slim homelab card; each: screenshot, 1-line problem, stack chips, "Read case study →" | P2 P4 | Deep-lane entry |
| 5 | **Experience** — compact vertical timeline (System Developer 2015–2023 emphasised; earlier roles collapsed one-liners) | P1 P3 | Employment verification |
| 6 | **About teaser** — photo, 3 sentences, language levels, "More about me →" | P3 | Human trust |
| 7 | **Contact CTA band** — "Looking for a systems developer in Norway?" + e-mail button + form link | all | Conversion |

## 4. Case study page template (both projects share it)

```
1. Header: project mark + name, one-line value prop, status chip (Active / In development),
   stack chips, links (live demo if applicable · repository)
2. Hero screenshot (framed browser mock, themed)
3. TL;DR box — 4 bullets: What / Why / Stack / My role   ← the only part P1 reads
4. Problem & context
5. Architecture — diagram first, then short prose (frontend / API / data / workers / integrations)
6. Key decisions & trade-offs — 3–5 numbered decisions, each: choice, alternative, why
7. Security & production notes — auth, secrets, encryption-at-rest, backups, CI
8. Screenshots gallery — 3–5 annotated captures
9. What I'd improve next — honest, specific
10. Footer nav: ← other project | All projects
```

Content per project sourced from `website_details.md` (JobTrack) and InboxIntel README/docs — see CONTENT_STRATEGY.md §4.

## 5. Bilingual architecture (conceptual)

- **URL strategy:** path-prefix locales. English at root (`/projects/jobtrack`), Norwegian under `/no/` with **localised slugs** (`/no/prosjekter/jobtrack`). Rationale: root-EN keeps existing inbound links and international reach; `/no/` prefix is the conventional, SEO-clean pattern; localised slugs signal genuine Norwegian content.
- **Language switch behaviour:** switches to the *same page* in the other language (per-page mapping table), never to the other homepage. Preference remembered for return visits; first visit may show a one-time, dismissible "Denne siden finnes på norsk" hint if the browser prefers Norwegian — never an auto-redirect (recruiters share links across languages; links must stay stable).
- **Parity rule:** every page exists in both languages; content is *equivalent, not identical* (CONTENT_STRATEGY §5). If a page ever ships EN-first, the NO version shows a short native-Norwegian summary + "full versjon på engelsk" link — never machine output, never a broken switch.
- **SEO (conceptual):** `hreflang` pairs on every page + `x-default` → EN; per-language titles/descriptions/OpenGraph; per-language sitemap entries; canonical per locale (no cross-language canonicals — the versions are alternates, not duplicates).

## 6. Content model (design-level, informs Phase 2 data model)

```
Profile        name, roleLine ×2 lang, summary ×2, chips (location, permit,
               availability, languages), photo variants, links
SkillGroup     title ×2, ordered skills[] {name, contextLine ×2 (optional)}
Project        slug ×2, name, valueProp ×2, status, stack[], links[],
               tldr ×2, sections[] ×2 (problem/architecture/decisions/
               security/next), media[] {image, alt ×2, caption ×2}, diagram
ExperienceItem employer, role ×2, period, location, summary ×2,
               highlights[] ×2, emphasis (featured | compact)
Page meta      title ×2, description ×2, ogImage per lang
```
Every user-visible string exists per-language by construction — this is the "avoid duplication issues" answer: one structural source, two content channels, no forked page trees.