I wanted this site to feel like mine.
There are plenty of clean portfolio templates available, but I could not see myself in them. Something Something Cyber needed a bit more character. It also needed to reflect some of the technology I grew up with.
I kept coming back to the original Xbox startup sequence and the Xbox 360 dashboard. Both could make something as ordinary as opening a menu feel important. The dark backgrounds, green light and slightly dramatic system messages stuck with me.
That gave me the direction for the site.
I was not interested in recreating an Xbox dashboard exactly. The idea was to capture some of the atmosphere and build a design around my own content.
The site is built with React, TypeScript and the Next.js App Router, with Vite and Vinext forming part of the development setup. It is deployed through Vercel. That is the plumbing. Most of what gives the site its identity is ordinary CSS.
Setting the rules
I started by defining the colours, spacing, fonts and animation timings as CSS variables.
:root {
--color-bg-canvas: #021007;
--color-surface: rgba(6, 30, 13, .75);
--color-text: #b9dcae;
--color-text-muted: #6fa568;
--color-accent: #d3ff7a;
--color-accent-strong: #8aff3c;
--duration-fast: 140ms;
--duration-normal: 220ms;
--duration-slow: 420ms;
--glow-soft: 0 0 24px rgba(120, 255, 70, .18);
}Doing this early saved me from picking a new shade of green every time I added something. It also gave each colour a job. Muted text, surfaces, borders and active controls remain consistent across the site.
Three typefaces are used.
Chakra Petch covers most of the readable text. Michroma is used for headings and some of the larger interface labels. Share Tech Mono handles metadata, system messages and status information.
The font files are stored in the project and served with the site. I did not want the browser making another external request for fonts, and keeping them locally makes their behaviour easier to control.
Making the green orbs
The orbs on the homepage are built entirely in CSS. There are no image files, 3D objects or canvas effects behind them.
The base is a circular element with a radial gradient:
.orb {
border-radius: 50%;
background:
radial-gradient(
circle at 36% 30%,
#f2ffb0 0%,
#b8ff54 24%,
#63d926 50%,
#1e7a14 74%,
#0a3a0c 100%
);
box-shadow:
0 0 40px 6px rgba(140, 255, 70, .35),
inset 0 0 30px rgba(225, 255, 150, .5);
}The centre of the gradient sits slightly above and to the left. That creates the highlight and gives the circle some depth.
Several shades take the colour from a pale yellow-green centre to a dark green edge. The inset shadow adds some light inside the shape, while the outer shadow creates the glow around it.
Hovering over an orb increases the brightness, adds a drop shadow and makes it slightly larger. The scale change is deliberately small. Earlier versions moved more and felt a bit cheap.
Each orb has a thin ring sitting just outside it. The ring rotates when the control is hovered over or receives keyboard focus.
.orb-button:hover .orb-ring,
.orb-button:focus-visible .orb-ring {
animation: spin 20s linear infinite;
}The animation takes 20 seconds to complete a rotation. It should be something you notice after looking at the page for a moment, rather than the first thing competing for your attention.
Building the background
The background uses several CSS layers.
Large radial gradients create faint areas of green light. A darker gradient underneath fills the rest of the page. There is also a vignette around the edges, created with a pseudo-element.
The grid is made from three repeating linear gradients. Two are diagonal and one is horizontal. They are all set to a low opacity.
I also added scanlines:
.scanlines {
position: absolute;
inset: 0;
pointer-events: none;
opacity: .38;
background:
repeating-linear-gradient(
0deg,
rgba(0, 0, 0, .16) 0 1px,
transparent 1px 3px
);
}The scanline layer covers the page, so pointer-events: none is important. Without it, an invisible decorative element could interfere with the controls below.
A lot of the final appearance comes from keeping these effects fairly quiet. Increasing the opacity of the grid or scanlines quickly makes the page difficult to look at.
The boot sequence
The homepage opens with a short boot sequence. It shows the SSC orb followed by a few system messages before revealing the navigation.
It remains on screen for 2.8 seconds unless the visitor dismisses it with a click or key press.
The sequence uses three states:
type BootState = 'active' | 'exiting' | 'complete';I added the exit state after the first version felt too abrupt. The boot screen was being removed as soon as its timer finished, so the homepage appeared underneath it with no real transition.
It now fades out over 650 milliseconds. The content blurs slightly and scales down while the homepage comes into view.
Clicks, keyboard input and the automatic timer all use the same function to close the sequence. Keeping that behaviour in one place made it much easier to avoid odd differences between the three ways of dismissing it.
The optional system hum
The sound button on the homepage does not play a recorded audio file. The hum is generated in the browser with the Web Audio API.
It uses two oscillators. One produces a 52 Hz sawtooth wave and the other produces a 104.5 Hz sine wave. Both pass through a low-pass filter.
low.type = 'sawtooth';
low.frequency.value = 52;
high.type = 'sine';
high.frequency.value = 104.5;
filter.type = 'lowpass';
filter.frequency.value = 220;The gain only rises to 0.018, so the result stays in the background. It fades in and out instead of stopping suddenly.
Sound is off by default. The audio context is only created after the visitor presses the button, which also keeps it in line with browser restrictions around automatic audio.
This feature is entirely decorative. Turning it off has no effect on the rest of the site.
Taking the design beyond the homepage
The homepage has the strongest Xbox influence, but I wanted the rest of the site to feel connected to it.
Blog posts are listed as transmissions. Each entry has a log number, category, reading time and status. Posts which have not been published yet appear as queued signals.
The article page uses the same visual language in a quieter way. Publication details are shown in a small readout. Code examples are presented as field notes, while important points use a bordered callout.
There is also a sticky reading progress bar. It tracks the percentage of the article read and identifies the current section. Opening it shows the article outline, with links to each heading.
The progress calculation runs inside requestAnimationFrame while the page is being scrolled. This prevents the scroll handler from attempting to update the interface more often than the browser can draw it.
Content is currently stored in a TypeScript file as structured blocks:
export type TransmissionBlock =
| { type: 'paragraph'; text: string }
| { type: 'heading'; id: string; text: string }
| { type: 'list'; items: string[] }
| { type: 'code'; label: string; code: string }
| { type: 'callout'; label: string; text: string };The article renderer works through those blocks and selects the relevant HTML for each one. It is a small setup, but it gives every post the same structure without needing a database or content management system yet.
What came from Xbox
The colour is the most obvious influence. Green is used for the light source, selected controls and status information.
The floating navigation also came from the way older console interfaces treated menu items as objects within a larger space. On the homepage, the three sections sit at different positions and connect to the top of the screen with thin lines.
The boot sequence, controller-style prompt and system messages continue that theme.
I created the SSC orb, transmission archive and field-log article layout for this site. The implementation does not use Xbox code or assets. I took the parts of the visual language I remembered and worked them into something that suited the content.
Making it work on smaller screens
The desktop homepage uses absolute positioning to spread the orbs across the screen. That stopped working as soon as the viewport became narrow.
On mobile, the orb area changes to a grid. The controls are smaller and alternate between the left and right sides. The header and footer text also return to the normal page flow so they do not overlap the navigation.
There is another layout for screens which are wide but short. This covers landscape phones and small browser windows where a desktop arrangement technically fits across the screen but runs out of vertical space.
The article readout begins with four columns. It drops to two columns and then one as the available width decreases. A decorative rail beside the article is removed on smaller screens to give the text more room.
Accessibility and motion
An interface with this many visual effects can become unpleasant quickly, so the site responds to the visitor’s reduced-motion setting.
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: .01ms !important;
animation-iteration-count: 1 !important;
transition-duration: .01ms !important;
}
.cursor {
opacity: 1;
}
}Links and buttons have visible focus styles. Decorative grids, scanlines and rings are hidden from assistive technology. The main controls use standard links and buttons so their behaviour is familiar to the browser.
Some accessibility work remains.
The arrow keys currently change which homepage orb looks selected, but they do not move browser focus. Pressing Enter after using the arrows therefore does not always activate the orb a visitor would expect.
The boot sequence also runs every time the homepage is mounted. I would like to remember that it has already played during the current session. It still needs better isolation from the page underneath while it is active.
Those are problems I would rather document than pretend are finished.
What I would change
I would build the keyboard behaviour earlier. Visual selection and browser focus ended up being handled separately, which has left a gap in how the homepage navigation works.
I would also test short screens sooner. Width receives most of the attention during responsive testing, but the original homepage design relied heavily on the available height.
The repeated interface elements could be split into reusable React components as the site grows. The status indicators, angled controls and system readouts currently share CSS, although some of their markup remains inside individual pages.
What comes next
The site currently has the homepage, transmission archive, article reader and a custom error page. Project Lab and Profile are still under construction.
The next round of work will focus on those sections, keyboard navigation and some automated tests for the important routes and interactions.
I am happy with the character of the site. It feels familiar without being a direct copy, and there is enough flexibility in the design to support normal blog content.
There will probably be more green, though.