http://benchmarkwatcher.online/
https://github.com/alikatgh/benchmarkwatcher
This project started as a negative space exercise.
I wanted to build a UI that displays historical benchmark observations clearly — and then deliberately not add everything people expect once numbers are on a screen.
No predictions. No signals. No recommendations. No interpretive language.
Just recorded values, changes, and timestamps — presented as reference material.
BenchmarkWatcher is an open-source web interface for displaying commodity benchmark observations.
It focuses on:
- clarity of displayed data
- neutral terminology
- consistent visual encoding
- accessibility and keyboard navigation
Every label, ba…
http://benchmarkwatcher.online/
https://github.com/alikatgh/benchmarkwatcher
This project started as a negative space exercise.
I wanted to build a UI that displays historical benchmark observations clearly — and then deliberately not add everything people expect once numbers are on a screen.
No predictions. No signals. No recommendations. No interpretive language.
Just recorded values, changes, and timestamps — presented as reference material.
BenchmarkWatcher is an open-source web interface for displaying commodity benchmark observations.
It focuses on:
- clarity of displayed data
- neutral terminology
- consistent visual encoding
- accessibility and keyboard navigation
Every label, badge, and tooltip is written to describe what is shown, not what it means.
Early on, I wrote explicit UI vocabulary rules for myself.
Certain words never appear in the interface — not because they’re inaccurate, but because they imply interpretation:
- no predictive language
- no evaluative language
- no advisory framing
This wasn’t about legal defensiveness.
It was about honesty.
If a UI presents historical observations, it shouldn’t quietly suggest conclusions.
Throughout development, I consciously declined features that would have pushed the UI into analysis:
- trend labeling
- performance comparisons
- alerts or signals
- directional advice
- interpretive summaries
Each one would have been easy to add. Each one would have changed what the tool is.
From a technical perspective, the project emphasizes:
- strict separation between data and presentation
- client-side state stored with explicit defaults
- accessibility-first modal and control design
- theme consistency without runtime surprises
The hardest part wasn’t writing code. It was keeping the scope intact.
This is useful if you want:
- a clean reference display
- neutral historical context
- a UI that doesn’t editorialize
It is not designed for:
- decision-making workflows
- forecasting
- comparative evaluation
I’m sharing this primarily for feedback from people who care about:
- UI semantics
- wording discipline
- scope control in open-source projects
If that resonates, I’d appreciate a look or a comment.