Introduction
As most designers can easily tell you, having a portfolio or personal website is of key importance when building up a carreer. Showcasing your work on a personal webpage is much more appealling to both hiring professionals as well as interviewing peers, than just sharing a link to dribble filled with generic template images from photoshop mockups.
What most designers won’t tell you is: keeping your site constantly updated can be a massive chore, and a task that most of us tend to procrastinate for endless weeks (if not months).
From early years as a designer I have learned this the hard way: my portfolio website attempts ranged from static layouts, crudely built on Macromedia’s Fireworks using slices and direct links, to building animation-filled pages with Flash and actionscript 2 (oh the days of keyframe animations…), onto shifting to simple html pages with javascript animated portions, and finally ending up using Wordpress as CMS / Frontend tool for ease of publishing new content and maintaining a coherent frontend.
And this was good progress. I finally had found a platform that enabled me the right balance of customisation/automated tasks/editing interface. But somehow this still wasn’t the right tech stack for me.
So, what’s wrong with Wordpress?
The answer is quite simple: absolutely nothing! Wordpress is a great CMS and works like a charm for most people that want to build their personal pages (wether it’s a Blog, Porfolio, Intro or CV page), and companies aiming to build their corporate website or e-commerce shop. (hell! I’ve once built an online pricing table with user roles and capabilities using Wordpress!)
But the versatility and popularity of Wordpress also make for the argument that compelled me to look for alternatives: it’s quite often targeted for hacks and cumbersome to maintain.
Being the most popular choice on the internet for building and delivering websites, Wordpress is very commonly aimed by attackers looking to exploit its vulnerabilities to try and make a quick buck over the information gathered.
Add to that the plethora of third-party plugins (both free and paid), that need constant updates and further development from others, and you have yourself a nice bundle of dependencies to rely upon.
While that would never affect my personal use case, since I had no payment methods or other sensitive information stored on my website, the mere fact of knowing that the tool I was using was almost constantly under fire, led me to think that I might need to explore other options. After all, I really didn’t need all the versatility and structure that came with it, and cutting costs on hosting and consumed time updating the platform were also good arguments.
Maybe it was time to take a simpler approach, a cleaner one.
Why choose Hugo then?
Having read a bit about Jamstack and the rise of SSG’s (Static Site Generators) it made perfect sense for me to onboard this futuristic old approach. I don’t have too many edits per year that require a more sophisticated CMS interface, nor do I need the complexity and requirements a Wordpress installation implies (Apache+php+SQL database+Hosting space)
I have also realised that having to focus on the platform and its constraints was distracting me from creating valuable content and focusing on design, rather than technicalities.
So, I made the decision to start looking more into my own workflow and creative routine and started to look for a combination of tools that would adapt to it and allowed me to optimise my time better.
I have been using Obsidian to take notes and write across my phone + computer, with synced markdown documents, so the logical approach would be one that allowed me to use the content already formatted and in readable form as markdown for my articles and projects.
Hugo made perfect sense for me, for a number of factors:
- It’s lightweight;
- It can leverage on content formatted in markdown to generate static sites;
- The generated files can be hosted on almost any provider, and don’t require any specific server-heavy tech stack;
The goals
As I was preparing to trigger this change, I wanted to keep the focus on 3 main aspects:
Versioning: essential even for designers
I wanted to follow a git versioning approach for my website. Even though there aren’t any plans for additional contributors to work on my website, I wanted to make sure I kept every change organised, documented, and reversible in case of any issue.Reduce hosting costs
At the time, using Wordpress as my main CMS I had a recurring cost of server hosting + domain name, for an installation that I was barely taking advantage of. I wanted to see if it was possible to reduce that and simplify the hosting itself.Simplify the process of publishing content
As I have mentioned previously, I was looking to find a workflow that would integrate on my creative work and would not make a burden out of content publishing/writting.
Installing Hugo, theming, and testing
After reading the initial documentation and testing a few installations on my local machine, I have found that I could simply create a repository on GitLab and use their Pages feature to build and deploy my website.
While it was also possible to choose other tools for deployment, I preferred to follow the simplest and unified approach of having everything managed on a single GitlLab repository, from which I would also deploy my website.
To get started, I have created a simple repo and installed Hugo locally. After looking for a theme to get me started I have found out the awesome Blowfish theme and decided it was more than capable of handling everything I needed for my site, while allowing me to focus on the content.
After defining a content structure and making some customisations and tweaks to styling, I have started adding files directly in markdown, to test the flow and if it would adapt well to my creative routine.
The Blowfish theme has already a vast and complete documentation, which helps a lot in this part of the process, mainly for those who are beginners to Hugo like me. So have this in mind: whenever you choose to start using Hugo on your site take in consideration that choosing a theme that is well documented and built makes a huge difference.
Leveraging GitLab to build and deploy
GitLab already has a template base for repositories that use Hugo+Pages to trigger a build whenever there is a deploy to Master. When creating my repository, I have also tested with their template to understand how I could generate the necessary yaml file.
From here, I’ve tried to keep a coherent logic for deployment and new content production. New content would be added on separate branches. I would also create separate branches for theme updates and customisations. Whenever new content is uploaded onto a new branch it is then reviewed, and only then, if everything checks out to be ok, it is then placed in queue for merging onto the master and trigger a new version.
Final thoughts
While this likely won’t be my final version of a portfolio website I’m proud of the end result and the learning process as a whole. It is a more organised workflow than what I previously had in place, works and runs pretty well, and it allows me to focus on content creation that is naturally aligned with my creative process.
Tech is always evolving, and naturally, new ways of building and deploying content will be created. As someone who likes and appreciates web development I’ll always keen to learn more and give different approaches a go, for the next iteration on my professional journey (or portfolio, in this case).
