New Website Requirements

Once something is shipped it's easy to forget all the planning and prior work that led up to a release. My previous post introduced my new portfolio, and this post will run-through the functional and technical requirements I defined pre-build.

Why? Requirements shape decisions – and decisions shape code. Documenting requirements often buried at code level lifts them to a more consumable format. This is something I recommend doing to help our future selves and colleagues when maintaining a codebase you intend to contribute to long-term.

So, in no particular order:

Preserve URLs #

Existing pages should be available at the same URL. Why? Cool URIs don't change.

Friction free publishing #

The predecessor to this site was rife with manual tasks to the point where publishing a new blog post felt closer to coding than writing. Now 11ty does the heavy lifting.

Work without JavaScript #

A strange requirement for someone who predominantly writes JavaScript for a living. However its all about using the right tools for the job. A personal blog shouldn't fall down when JavaScript is disabled.

Accessibility first #

A firm believer in an inclusive web the new site needed to be accessible. It even has its own accessibility page, and I eagerly anticipate revealing its semantic HTML in my first CSS naked day!

Online résumé #

For years my résumés were buried in Google Drive suffixed with "_v14" or "_final", and formatting/ styling them in a word processor was painful. Now online my résumé is easy to find, version controlled for free, in a format I'm comfortable with, and shares the same visual identity with my site via CSS. It's also accessible!

Outsource formatting #

In a similar vein to friction free publishing I wanted friction free development. Prettier formats the code so that I can focus on more important things.

Categorize posts #

I plan on blogging frequently this year and tagging blog posts makes navigating through content easier for me and readers.

Dynamic pagination #

Previously the read next/ previous pagination was coded by hand for each blog post. Automating this was a MUST.

Light/ Dark theme #

It would be rude to ignore a users prefers-color-scheme request.

Utility CSS classes #

For years I was hesitant about utility CSS classes, however their rise in popularity (notably tailwind) is hard to pass over.

Rebuilding the site was the perfect opportunity to sample the utility class based approach. I didn't commit fully and opted for a hybrid between utility and semantic CSS classes, which worked surprisingly well.

Graceful degradation #

Simply put the new site needed to consider unhappy paths such as: how does an image failing to load impact the UI, or what fallbacks redeem an unsupported CSS feature.

Lightweight #

Admittedly the MVP only tackled low hanging fruit in regards to performance. Despite not setting a hard performance budget I was mindful of asset sizes (preloading/lazy-loading where possible), and keeping CSS lean enough to inline in the <head/>.