The Saga Continues

The last time I wrote about rebuilding AthensNoise.Rocks, the site was still very much in the middle of becoming something else.

Not a completely different website, because that was never really the point. The idea was to take what had accumulated over the years, clean up the structure, make the publishing side easier to work with, and give the whole thing a more consistent visual and technical language without sanding off what made AthensNoise what it was.

A lot of that work is now done.

That does not mean the site is “finished.” I am becoming increasingly suspicious of that word when it comes to personal websites anyway.

What it means is that most of the old material has now been moved into the new publishing system, the basic design language has settled down, and I am spending much less time rebuilding entire sections and much more time finding small inconsistencies, testing things on actual devices, and asking whether new ideas are worth the complexity they introduce.

That feels like progress.

The migration is basically over

Articles, reviews, album streams and the various bits of editorial material that had accumulated in different forms are now using the same general Hugo-based system or the Athensnoise Publishing System as I have chosen to name it.

That sounds mundane, but it changes the character of maintaining the site considerably.

Instead of every old page being its own little archaeological site, I can increasingly think in terms of reusable layouts, categories, shortcodes and CSS components.

One change can affect an entire family of pages instead of requiring me to revisit twenty individual documents.

This is one of the things I have gradually come to appreciate about Hugo.

At first its templates can look like punctuation soup.

After seeing the same constructs enough times, though, they stop being mysterious. You start recognizing what a range is doing, where Hugo is looking for a template, why a project-level layout overrides one from the theme, and which piece of front matter is responsible for a page appearing somewhere unexpected.

I am not claiming to have become a Hugo wizard.

It has simply become less foreign. That matters.

The design is becoming a system

League Gothic handles the big display work. Barlow Condensed deals with navigation and structural headings. IBM Plex Mono handles metadata and the more technical bits of the interface, while Libre Franklin does most of the ordinary reading.

More importantly, those choices are no longer just font selections.

They have started becoming a hierarchy.

A headline looks like a headline because it belongs to a particular layer of the site. Metadata looks like metadata. Navigation feels separate from editorial text. The player belongs to the same website without pretending to be an article.

There has also been the usual CSS archaeology.

One of the consequences of gradually rebuilding a site instead of throwing everything away is discovering all the places where an older rule is quietly fighting a newer one.

• Sometimes the fix is a new rule.

• Sometimes the fix is deleting one.

More often than I expected, the second option is better.

I have also been moving things that began as one-off presentation tricks toward reusable site-wide patterns. Image lightboxes, blockquotes, publishing layouts and category presentation are good examples.

A style that works for one article is useful.

A style that works naturally across the publishing system is infrastructure.

Categories, tags and fewer special cases

Categories are becoming less like accidental Hugo-generated indexes and more like actual sections of the publication.

Press releases now have their own place, and I have been working toward using the same general category presentation rather than maintaining a pile of slightly different templates that all solve nearly the same problem.

Tags are heading in the same direction.

This is one of those areas where the design and the code turn out to be the same problem.

If categories, tags and archives all represent ways of browsing the publication, they should feel related visually. If they can also share the same underlying template logic, that is even better.

Every special case removed is one less thing I have to remember six months from now.

The radio is part of the site, not an iframe bolted onto it

It pulls its information from the existing AzuraCast station, displays current track metadata and artwork, handles playback, and exposes listening history without sending the visitor off to a completely separate interface.

There has been a lot of device testing around it, particularly on mobile.

Desktop browsers are very forgiving places to convince yourself that a media interface works.

Phones are less polite.

Buttons disappear. Browser audio behaviour changes. Layout assumptions stop being assumptions and become bugs.

So the player has had another round of adjustments based on actually using the thing rather than staring at it in Firefox’s responsive-design mode.

That distinction has become increasingly important during this redesign.

A browser simulator is useful.

Picking up a phone and discovering that the obvious play button is not, in fact, obvious is more useful.

IRC survived too

This remains one of my favourite slightly ridiculous parts of the project.

There are infinitely more fashionable ways to bolt “community” onto a website in 2026, but a simple IRC client fits AthensNoise better than most of them.

It is small, comprehensible and does one thing.

That has become a recurring criterion for features on the site.

Not everything needs to become a platform.

Sometimes a chat window can just be a chat window.

The temptation to keep adding things

You start imagining everything else it could do.

I have spent plenty of time researching those possibilities: alternative publishing interfaces, additional radio stations, richer music metadata, Bandcamp integration, event sources, different player behaviour and various other experiments.

Some of these will probably happen.

Some probably will not.

I am becoming more comfortable with that.

One idea I keep returning to is using the radio to help listeners find and support the bands they are listening too, particularly through Bandcamp.

That still makes sense to me.

Adding another API, another database and another external dependency purely because it is technically possible makes considerably less sense.

If I can reuse information the site already has, that is attractive.

If a feature requires another system that needs monitoring, credentials, updates and debugging, it needs to justify itself.

That sounds obvious written down.

It is surprisingly easy to forget while building things.

Sometimes the bug isn’t yours

The shortcode was simple enough: take the video ID and render the appropriate 9:16 embed.

It worked.

Except for the particular Short I actually wanted to use.

So naturally I started changing things.

Different embed URLs. Different markup. Testing on the local development server. Checking whether Shorts behaved differently from ordinary videos.

Eventually another random Short worked perfectly with exactly the same code.

At that point the useful conclusion was not “debug harder.”

The useful conclusion was that the external platform was refusing to embed that particular video.

My code was finished.

That is an oddly useful development lesson.

Knowing when something is outside your system is part of understanding your system.

And knowing when to stop spending time on it is probably even more useful.

Why Hugo is still here

It was in my Linux distribution’s repository. And I could see the source.

I still think those were good reasons.

There is something about repeatedly being exposed to software that gradually makes it less intimidating.

Templates that once looked cryptic become familiar. Directory structures start making sense. You remember that changing something under layouts/ can override the theme. You start recognizing which problem belongs to Hugo, which belongs to CSS, which belongs to JavaScript and which belongs to the external service you are talking to.

It reminds me a little of learning an instrument.

Someone showing you the basics helps enormously, but you still have to spend time around the instrument.

You have to want to pick it up.

You make terrible noises. You repeat things. Eventually movements that once required concentration become automatic.

I think free software encourages that kind of learning particularly well.

• The source is there.

• The README is there.

• The configuration is there.

Sometimes the documentation is excellent.

Sometimes the documentation appears to have been written at three in the morning by somebody who assumed you already knew everything.

Either way, the machinery is visible.

And visibility makes curiosity possible.

Where the site is now

That is probably the best indication of where the project currently stands.

The giant migration phase is largely behind me.

Now I am testing, simplifying, correcting inconsistencies and pushing the underlying structure a little further when there is a good reason to.

There are still things I want to build.

There are also things I have researched and deliberately decided not to build yet.

I increasingly consider both of those outcomes productive.

AthensNoise.Rocks was never supposed to become a feature checklist.

It is a radio station, an archive, a publication and a place on the web that I can actually understand and operate myself.

The objective is not to add everything.

The objective is to make the things that belong there work well.

And then keep playing with it.

Take away’s from this redesign

Infrastructure | Boring is a feature !

• Hugo static output wherever practical.
• Project-level overrides rather than modifying the Mainroad theme.
• Apache as the dependable web layer.
• rsync deployment and straightforward backups.
• Small incremental changes that are easy to test and revert.
• Careful AzuraCast upgrades because operational history matters.

The preferred architecture is deliberately understandable:

Hugo, Apache, rsync, plain files and small scripts where possible.

Practice Restraint: What to deliberately avoid

What you choose to implement may increase complexity to the project. Choosing not to buy into the latest trend may save you headaches two years from now.

Worth doing

• Use existing metadata in smarter ways.
• Automate repetitive bookkeeping.
• Promote bands through verified links.
• Keep useful data in inspectable files.
• Build reusable Hugo patterns.
• Connect radio, archive and editorial work where the relationship is real.

Not just because it can be done, it should

• No new API simply because one exists.
• No database where JSON/plain files are sufficient.
• No automatic artist matching treated as authoritative.
• No social-media post for every song.
• No IRC metadata firehose.
• No duplicate 12 GB media library for a second station.
• No forcing every research experiment into production.

If I could put an overarching philosophy on this, it would be “Minimize stack complexity, so you can touch grass.”
Basically the K.I.S.S principle - Keep It Simple Stupid. 😵

Now go break and create stuff you rascals!!