Feature_03 — Interface Systems
Legacy software, rewritten.This time as calm.
- Role
- Frontend Architecture
- Stack
- React · JavaScript · Tailwind CSS · REST APIs
- Elsewhere
- Repository ↗Live ↗
Most academic software is a database with an apology attached. This is an attempt at the opposite.
A full academic management portal built against the usability failures of legacy university software — modular components, clean data surfaces, and workflows that survive a bad network.
01
Premise
Premise
Students do not read dashboards; they scan them for one number. The portal is structured around that fact — grades, attendance, and schedules are surfaced at a glance, with detail available only on intent.
02
Method
Method
Modular React components consume REST APIs behind client-side routing and local state. Every view is a composition of the same small set of primitives, which is why it stays coherent as it grows.
03
Result
Result
A responsive interface tuned for usability and performance across devices, with CRUD workflows for student records that stay legible under load.
“Most academic software is a database with an apology attached. This one is an interface.”
Architecture
The topology, read top to bottom.
Fig. 03a — topology
Engineering Decisions
3 entries01
One number, scanned in a second
Students do not read dashboards; they check a single figure and leave. Attendance, CGPA and schedule sit at the top of the hierarchy, and everything else waits to be asked for.
02
A small vocabulary of primitives
Every view composes the same handful of components. The interface stays coherent as the feature set grows because nothing new has to be invented to add a screen.
03
Survive a bad network
Local state holds the last known good view, so a dropped connection degrades the page rather than erasing it.
Challenges
What resisted.
Inherited data shapes
The upstream records were designed for storage, not reading. A thin adaptation layer translates them into the shapes the interface actually wants.
Density on small screens
Academic data is inherently tabular. Tables were replaced with stacked record cards below the fold width, preserving scanability without horizontal scroll.
Trade-offs
Client-side routing
Against — Server-rendered pagesInstant navigation between frequently revisited views mattered more than first-paint purity.
Fewer visible fields
Against — Complete disclosureEverything remains reachable. Almost nothing is shown by default.
0
Core workflows
0%
Responsive
0
Year built
Timeline
Audit
Catalogue of the usability failures in the incumbent system.
Primitives
Component vocabulary, spacing scale, data surfaces.
Workflows
CRUD for student records, attendance and grades.
Hardening
Responsive passes and performance tuning across devices.
Gallery
1<Surface density="calm">2 <Metric label="Attendance" value={attendance} />3 <Metric label="CGPA" value={cgpa} />4</Surface>
Fig. 03a — the surface, not the schema
1const { data, error } = useRecords(studentId);2if (error) return <LastKnownGood cache={cache} />;3return <RecordTable rows={data} />;
Fig. 03b — degradation, not erasure
Fig. 03c — signal field
Results
Three workflows
Records, attendance and results unified under one interaction model.
Fully responsive
Legible from a phone in a corridor to a desktop in an office.
Shipped
Deployed and in use, built against real institutional constraints.