The Sparkly One
Update 2.0 of my site brings about a huge number of visual upgrades to the site, overhauls the site traversal menu (turning it into menus) and sets the groundwork for both Update 3.0 and Update 4.0.
This post covers the changes I’ve made, and serves to inform anyone following along now or in the future curious about how exactly I made this site, and also as a log of sorts for myself.
Better and Brighter
The first version of my website was a bare-bones MVP, a narrow slice of the original vision I had for it. My previous projects, have taught me, over and over again, that a narrow bare-bones version that provides the core functionality of my project is absolutely crucial if the project has to have even the slightest chance of completion. The smaller the team, or in my case, a solo project, the more vital this rule becomes.
Some of my earliest projects remain uncompleted to this day because I tried to do too many things in V1, and the project collapsed in on itself.
So, V1 of this website was focused on looking decently presentable, but more importantly to properly set up two things:
-
The CI pipeline, so that its easier to maintain and add features to the code that are bug-free and maintainable, and so that posts and articles written in the future can be easily added to the site in the most streamlined way possible.
-
The “skeleton” of the project. For example, the project and blog post cards didn’t have to look nice yet, but the position they occupied, the “slot” in the structure they filled, had to be properly coded in, hopefully set in stone too.
This is so that when the time came to replace them with actually good looking versions, or even updated versions of the good looking cards far into the future, they could be slotted in easily, and without disrupting the rest of the code
And with V2, I’ve done just that.
The Changes
With version 2, there’s been quite a few changes, and nearly all of them are visual.
I’ve always been fascinated with elegant, minimal design, and subtle animations and design, so that’s the look I’ve been trying to go for.
The main landing page now has a beautiful particle simulation in the background, one that’s been optimized too – pausing when it is scrolled out of view – even though I was planning to optimize components later on in V4, as this was easy enough, and the performance hit without the optimization was really too much to ignore.
The simulation was itself also quite easy to incorporate, as JS had a beautiful and open source (but not actively maintained) library that provided this functionality.
I’ve also changed the color theme of the sight from a mix of blue , yellow and red to a more monochrome white and black, which looks a lot more subtle and elegant in my opinion.
The project and blog post cards have also been completely replaced, with beautiful cards with hover effects and other animations. These easily took the most time, both because the CSS was quite complex to get right, that too on a multitude of screen sizes, and as there was really too many options on what I could choose to do and how I could choose to implement it, and any one I picked made me feel I was missing out on the other equally beautiful but uniquely expressed version.
The layout of the cards (both the project and blog variety) are also both fully responsive, tested (via simulated browsers) on every viewport size starting from 320 x 568 (The iPhone SE, smallest device I could find) to 3840 x 2160 (4K resolution, usually found on the largest/most pixel dense monitors around).
Again, responsiveness is something I did not want to work on just yet, instead saving it for V4, but it felt like a crime, spending so much time on getting the cards just right, but not working hard enough to allow mobile users to experience them in all their monochromatic glory.
I also completely changed the pre-loader that displays whenever a page on the site is loading, from a GIF file to a pure CSS animated globe that, in my opinion looks absolutely mesmerizing (and is absolutely needed too, distracting visitors from the comparatively slow loading times of the unoptimized HTML, CSS and JS)
Hugo automatically counteracts this to some extent, minifying the files and I believe also algorithmically optimizing some of it, but there’s only so much it can do when a page loads 6 JS libraries and 4 CSS libraries, half of which aren’t even needed (Horrific, I know, but actually not easily fixable, since the header and footers of the pages are global templates used by all the pages. It’s not a hard problem to fix, but a tedious one for sure, and as such, reserved for V4).
The menu system for traversing the site also got an overhaul, with the menu actually being split into two separate ones, one for smaller screens and one for larger ones. The large screen menu remained for the most part the same, with minor tweaks, while the small one was completely new, and I have to say looks absolutely great, reinforcing the traits I want my website to imbue: subtle but elegant and clean design with animations reinforcing that aesthetic.
The typography also received a major boost in this update, going from being nonexistent to semi-decent. I must confess I was never a very artistic person, so I just experiment and see what looks and feels good, and try to emulate designs that make me take a step back and look at again, and so far that’s been going well. The typography is still nothing to write home about, but I’ve been reading up on design and typography principles I plan to improve the typography further in subsequent updates.
The text sizing is also fully responsive now, on all viewports from the iPhone SE to 4K , actually feels pleasant to read, and has headings with consistent and predictable sizing, coupled with good looking icons instead of the bland dots for lists.
Typography is something I’ve come to admire a lot, and I plan to overhaul the page templates that are used by posts on the site in future updates too, to make reading articles on my site a more pleasant experience, especially on a larger number of platforms.
While optimization was not even close to being a priority in this update, I did lay some of the groundwork for it. Not a single component added in this update used Bootstrap defined CSS, and quite a few old ones that did were either removed or modified to no longer be dependent on it.
This was so that, in the future, I could cut off Bootstrap as a dependency for my site all-together, which would massively decrease the total size of the libraries I had to load for each page, and go a long way in reducing the data-payload that had to be transferred for the site to load, reducing load times.
The CI pipeline also came in useful this time around, as I had accidentally messed with the config files while doing all these changes, and as such, when I pushed my site to the production branch, it failed 7 of the 8 tests (some custom, others prebuilt) I had for the site.
Now that was a site to behold, akin to the mesmerizing nature of watching a Jenga tower come falling down, but actually funny too, as I was safe in the knowledge that there was an undo button and multiple backups, and the code hadn’t actually made it to production.
Other then just the day to day minor frustrations that naturally come with coding and random bugs popping up, this update went by rather smoothly actually, with no significant hiccups, unexpected timesinks or even extremely tough problems, things I suspect are result of the intensive planning I did before starting this project ( After both of my first two projects grew too much to ever allow me to complete them, for the most part due to a lack of proper planning and having a vision for what I wanted to achieve in each incremental update, I was not going to let it happen a third time ).
Automation
While mostly unrelated to this particular update, this is the first project where I really integrated CI into the workflow, and it has already saved more headaches than it itself was to set up.
As such, I’m planning on including the Argentum to its Aurum, and incorporating CD into the workflow too, which, if I set up correctly, will automate a lot of the boring repetitive tasks associated with actually getting these articles from the Word like environment where I’m currently writing them ( Forestry.io if you’re interested ) out onto the site itself.
This currently takes several commands I type in manually in an IDE, followed by a script that automates the rest of it, so the entire process is actually quite lengthy, and would solve me a lot of time and headaches in the long run if automated.
And if I am going through all the trouble of automating it, I plan to make it fully autonomous, running automatically, say, every day at 12am or 12pm, and getting the changes and sending them in to the production GitHub repository, of course, sending and merging nothing if there are no changes.
A bit of googling shows that this is highly plausible (and completely free) through some mixture of GitHub Actions and Cron, or just GitHub Actions itself, so I plan to do that in the final stages of V4, perhaps earlier, or maybe even bundle up all of these QOL changes into a V5 and do it that way.
Speaking of….
The Plan
As I touched on a bit near the beginning and in the last section, I plan to have 4 main updates for the site, with Update 3.0 focusing on the last of the visual aspects of the site, some large-scale animations and refining the components added in this update, and Update 4.0 being all about optimization, responsiveness and speed, getting the site to look good and load fast on a large number of devices.
Sprinkled in-between (or maybe through a smaller Update 5.0 at the end of it all) I plan to create a fully autonomous pipeline that periodically takes these posts and articles that I’m writing and does all the commits and merges necessary to get them live onto the site, a tedious and error prone series of tasks I currently do by hand.
The End
Well, that’s pretty much every thing I changed or added in this update, along with most of what I plan to change or add in the coming updates.
Software is an incremental thing, and to treat it any other way means setting yourself up for a lot of headaches in the future at the very least, or a massive time sink with nothing to show for it at the very worst.
If you’re building a software project, I implore you, take it slow, and plan.
Thank you for reading this article, and have a wonderful day!