Overview
ARCH // GLITCH CORE is a working bilingual manual and portfolio case study for one real desktop. My role covered UX/UI design, information architecture, visual and content design, and front-end implementation. It is not a redesign concept detached from production: the static site builds from the same repository as its audit and parsers.
Context
A highly customised Linux desktop gains efficiency through composition, but that composition distributes knowledge across Hyprland, Caelestia, GTK, terminal, desktop files, runtime state, and scripts. The project began as personal infrastructure: make the system understandable without flattening its complexity.
Problem
- Behaviour was fragmented across active and inactive config files.
- 101 keybindings exceeded reliable recall.
- Static notes could drift from runtime state.
- The visible interface did not expose its technical source.
- Unsafe commands could look equivalent to read-only inspection.
Users and use cases
The verified user is the system owner. No interviews or external usability study were conducted. Core uses are finding a shortcut during work, tracing UI behaviour to a file, diagnosing a failed component, preparing an update, and communicating the project in English or Slovenian.
Constraints
No system configuration could be changed. Sensitive identifiers had to be redacted before project storage. The site had to remain static, work at documentation depth, preserve no-JavaScript access, and stay on Astro 5 / Starlight 0.36.
Information architecture
Content strategy
English is the primary portfolio language; Slovenian retains the system owner's native operating context. Commands, paths, and technical identifiers are invariant. Labels and explanations are translated at equal depth. Evidence labels stay in English as a compact system vocabulary.
Interaction design
Recognise the task
Enter through project narrative, search, or a manual chapter.
Narrow the evidence
Filter a shortcut or follow a direct UI-to-config map.
Inspect safely
Read command intent and expected output before copying.
Verify and recover
Confirm the outcome and retain a rollback path.
Visual design
The portfolio uses an asymmetric editorial grid, expressive headings, and quiet reading surfaces. Shared tokens govern colour, spacing, cards, and controls. Existing collage imagery provides atmosphere; the manual keeps its own restrained project theme.
Accessibility decisions
Body contrast exceeds WCAG AA against the core background. Focus-visible rings use lime and sufficient offset. Controls meet practical touch sizes, content remains readable without JavaScript, diagrams include textual alternatives, and motion is disabled through `prefers-reduced-motion`.
Technical implementation
Astro renders custom portfolio routes while Starlight owns the manual shell, local navigation, table of contents, breadcrumbs, pagination, and Pagefind UI. Both locales consume one redacted JSON shortcut dataset. CSS and small progressive-enhancement scripts avoid a client framework.
Safety and privacy
Collection is read-only. Raw command output exists only under a temporary directory, then redaction removes home paths, network addresses, UUIDs, serials, hostnames, and secret-like values. Browser profiles, credentials, keyrings, and private history remain outside scope.
Outcome
The implemented result contains two portfolio languages, paired case-study and design-system routes, 34 manual translations, one shared 101-binding explorer, contextual language switching, and a static build. These are implementation facts—not claimed usability metrics.
Limitations
There was no external user research or measured task benchmark. Runtime Hyprland access was unavailable during the original isolated audit, so active configuration is the binding source. Automated screenshots depend on locally available browser tooling.
Next iteration
Planned work—not completed evidence—includes task-based usability sessions, measured search success, automatic translation parity checks at heading level, and optional visual regression snapshots in CI.