cesnimda
6.7 KiB
6.7 KiB
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):
hreflangpairs 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.