Revamping my website this summer felt very autobiographical. It not only charted my shifts in focus over the years but also my growing comfort with web development. I still have a lot to learn, but I’ve definitely made some gains since college started.

In the beginning there was nothing…

I bought kevinzhai.com two days before Christmas 2010. I was a junior in high school at the time. I wanted to host my art portfolio in preparation for college applications, so my friend Edward recommended NearlyFreeSpeech. Edward’s really smart, so I took his advice and hosted there with a few dollars I had earned from designing business cards on Fiverr. I didn’t have much to put up, so I just fiddled with color schemes and tried to figure out how to make circles in CSS.

At that point, the main benefit of a domain name was custom subdomains on Tumblr, where I uploaded my art portfolio (I didn’t want to pay storage costs for all my big scanned images). According to my email records, I made a MySQL database too, but I can’t remember if I actually properly setup WordPress at the time.

Basic HTML

I started off sophomore year at Stanford with a class called Design Your Stanford. At the end of the quarter, we had to design personal websites to showcase what we had learned. The teachers recommended Wix, but I had recently downloaded Sublime Text and discovered Zurb Foundation, which I liked mainly because of the font (I didn’t know what responsive design was at the time). I felt like a god when I discovered the multi-cursor functionality and tag expansion shortcuts — never mind that I was copy-and-pasting my header onto every new HTML page I made. I was proud enough of my work to copy it over to the NearlyFreeSpeech servers using FileZilla.

WordPress

At the start of winter quarter junior year, I was applying for a design consulting group, so I decided it was once again time to revamp my website to serve as a portfolio. Given the amount of time I had until the application deadline and the fact that I was in Tahoe for dorm snow trip, I decided WordPress was the most efficient way to go. I had read that it powered 25% of all websites, and that many people couldn’t be wrong, right?

I found a decent theme, Googled how to setup WordPress through NearlyFreeSpeech, and started uploading my experiences in picture and text form. They were mostly graphic design and film projects, but I had also completed the Intro to HCI class last quarter and had come out with some awards.

Although uploading photos was effortless with the WordPress drag-and-drop interface, customization would be a hassle. I couldn’t figure out heads or tails of the nested directories of PHP code.

My WordPress site was relatively expensive since NearlyFreeSpeech charges daily for MySQL and PHP (I only had to pay for negligible storage costs of my static website).

More urgently, the admin login was often the victim to brute-force attacks that required me to reset permissions every couple of months.

Flat-file CMS

During winter break of junior year, I came across the website of Brian Moore^brian, and I really like the look of his website. It had big colorful thumbnails and related work easily accessible from any page. Looking through his colophon, I learned he used something called Stacey.

As I read the documentation, I grew more and more excited. It made sense and was so simple! Keeping templates separate from content so they could be re-used and modified across all pages was the kind of abstraction I was learning about in CS. One simple folder of Twig templates was way easier to parse than the maze of PHP in a WordPress free theme. I was able to modify the existing templates as I saw fit.

I worked on it for exactly a week, with most of the time spent figuring out how to get embedded videos to load with cached thumbnails rather than the actual video.

It was 13 MB, compared to my original WordPress site of 250 MB.

The creator of Stacey, Anthony Kolber, hadn’t updated the codebase since 2013, so while my own website was good enough, I decided to look into alternatives for future projects. The one I saw pop up most often was Grav, which I used to create the original Best Four Years website^bfy during the same time period and later in the year to revamp the Stanford Phi Psi website from its last update in 2002.

Static site

The summer after senior year, I saw Brian had updated his site again. He was now using Jekyll. And so began my dive into the rabbit hole of static site generators. Along the way, I also started to learn a bit about the current web dev landscape (Webpack, Browserify, Bower, etc) as well.

One immediate advantage was that I would be back to serving static files while Stacey still required a web server, which NearlyFreeSpeech charged for daily. I read about how static site generators were overkill, but after looking into Gulp and Grunt, I came across articles about how Gulp and Grunt were overkill. It was turtles all the way down.

In the end, I came across Harp. Yes, it was a static site generator, but I liked the way it separated metadata from content (Grav and Stacey use YAML, which mixes metadata with Markdown), how it automatically compiled pre-processors (Jade, Markdown, SASS, etc), and that I could design my website completely from scratch.

It was good enough.

Design Philosophy

I focused on making a website that was easy to maintain and took up the least amount of space to keep hosting costs down.^cost This was also motivated by my desire to reduce the amount of file renaming and directory shuffling when porting content over from my Stacey build.

I didn’t have much choice with the Markdown content — they had to be copied over or rewritten. But, I realized the photo galleries and project thumbnails could be pulled programmatically from their sources on Flickr. Similarly, video-based projects could use the YouTube and Vimeo APIs to generate their thumbnails. This way, I didn’t need to manually download a corresponding thumbnail photo for every single project. By pulling directly from the source, the thumbnails would automatically update if I added a new photo to an album or uploaded a new video. Plus, I could now control photo resolution to speed up downloads if a user was accessing my site through mobile.

I also ended up switching from NearlyFreeSpeech to Surge because it hosts static sites for free, has an easy-to-use CLI that does the uploading for me^upload, and automatically generates clean URLs (it’s the little things). Surge also touts its CDN and caching techniques, but given how fast and simple static sites already are, these are just nerdy cherries on top.

In terms of grid layout, I stuck with the tried-and-true rule of thirds from the Stacey build. For the project pages, the left third holds breadcrumb navigation and text content while the remaining two thirds holds the main media content. I’ve been thinking about using a different layout for projects with longer text content because it’s currently confined to the narrow left column, which isn’t great for readability.

My Stacey site was based off one of the provided templates, which wasn’t mobile-friendly. I had hacked together a quasi-mobile version by changing up some of the default CSS, but it wasn’t great. With my Harp build, I had the opportunity to develop for mobile first using include-media.

Like I said before, one of my goals for the website was to minimize space used. While my Stacey build was 13 MB, my final Harp configuration slashed my website down to 4 MB total.

Drawbacks

The main tradeoff for hands-off thumbnail maintenance is that non-local thumbnails are slower to render since they have to make API calls to different servers. It’s a price I’m currently willing to pay for less hassle when I add new projects or inevitably decide to port my website again.

Another thing I’m still not totally satisfied with is the category-centered design I kept from the Stacey build. My tags are broad enough to fulfill my current needs, and because I have total control now, I’m able to crosslist projects that I feel should show up in more than one. However, if you’re browsing the art category and click Star Stuff, you’ll end up in film because the Markdown for the project is stored in the film folder. For a related reason, using the “next” and “prev” buttons in the art category would skip over Star Stuff altogether. It’s not a perfect solution, but it’s good enough for now.

Surge is great, but it doesn’t keep track of which files have been changed since the previous upload so it uploads and propagates every single file and directory even if I just need to correct a typo in a blog post.

Finally, one of the (debatable) downsides of a static site is that there’s no easy way to host comments. I’m possessive, so I want to control and own the comments myself rather than through Disqus. Overall though, I’m not too worried about it since most blogs don’t benefit from a comments sections anyway (the ones I see usually just take up space with a forlorn encouragement to become the first poster). If I find I’m getting a lot of demand for comments, I’ll figure something out. But, as I learned when starting my podcast, it’s a waste of time to build features before I get user feedback.

The Takeaway

The historic trend for my my website redesign is that it gets geekier and takes up less space. Maybe next year I’ll decide to dive into making my site with npm scripts or Gulp.^ghost

My website has always been a deeply personal project. Yes, it’s there so I can share my projects with the world (and maybe employers), but it’s foremost an autobiographical catalog of projects that have shaped who I am. Moreso than any social media account, www.kevinzhai.com is my identity online. It only seems right that I also design the vessel it resides in.

This blogging thing is new to me as well. I’ve written daily in a journal for over a decade now, but it’s different from writing these public posts. My journal writing is usually a first draft and a retelling of a day for my eyes only. These posts are ostensibly for an outside audience, and I want you to learn something, or at least enjoy reading what I’ve written.

I sometimes feel a pang of narcissism when I’m revamping my website. Do I really need to do this? Who even cares? Even if the content itself is inconsequential, the process of discovery and learning on my own terms has been rewarding. And that’s good enough.