jaanus.com, 2018 edition

September 11, 2018

I just published the new version of this site with design and content updates. Here are the “before” and “after” screenshots of the front page.

Content-wise, the biggest addition is that of the Works section. I always had an offline portfolio, and now the time has come to finally publish it, as is the standard for designers. It was an delightful history trip to go through the old projects, clean up the content, and add some notes in retrospect.

I took notes as I went through the making process, so here are some production remarks.

Motivation

Why have your site in the first place? Especially design and build it from scratch? It’s a fair question, given that there are many good services available that let you publish your blog or portfolio with zero effort and great design.

To me, it’s about two things: control, and making.

Control means that I own my content, and don’t need to depend on anybody else for permission or rules to publish anything. This is not to say there are no dependencies: there are many, in fact. I still need to use some web hosting and software to make the site, but I am free to design my own domain, URL-s, publishing policy and such.

Consider, for example, that last year Medium stopped offering custom domains. Domain and URL design are a big part of your online identity. If you publish on someone else’s site, you are at their mercy, and especially at the mercy of their business model. Business models can come and go. I don’t want to hop around between venture-capital-funded models. I want to be completely in control myself.

Making is the very act of actually designing, coding and publishing the site. I get to do quite little making these days as part of my work, which is a conscious choice, but I still like to make things, and especially on the web. Having fundamental web design craftsmanship remains a highly valuable skill, and what better way to maintain it than to keep your own site up-to-date with the latest and greatest. I thoroughly enjoyed designing, producing and testing the site, especially in 2018 where the state of the web platform and tools is pretty great and there’s no need for ugly hacks, at least on a simple site like this one.

I started to think about the remake many months ago, and did it over the past several weeks. I’d say it was about one week’s worth of work to do all of the design, code and content updates, spread out over many days in chunks of a few hours. I didn’t have much of planning process or roadmap initially, other than to have an image of what the site should roughly look and feel like. Towards the end, I did start to maintain checklists of things still to be done so I wouldn’t overlook anything.

Design and layout

The site has a simple structure, and the simple goal of bringing the content to the focus. So the goal of design was to bring out the content in the best possible light, mostly meaning maximum readability and accessibility.

Font and typography

The superstar of this site is Calendas Plus, the main font that I am using. I don’t remember when or how exactly I found it some years ago, but the more I used it on my old site, the more I started to like it. it just… speaks to me. And of me, I guess. I did briefly consider and test some alternatives, but not too seriously.

Calendas has beautiful features, like lush ligatures in italics, and interesting glyph design. Just look at how the U and S characters flow together here. And look at that J.

I considered readability and line length, playing around with font sizes, line heights and body width until I got to what you see here. I am sure that many designers would describe the desktop version as “too big” and “links have too much contrast” while other readers appreciate its readability.

Web fonts

I haven’t deeply looked much at web font technology recently (or any font technology, for that matter), but I did find there are some feature differences depending on whether you use the OTF version or convert it to web font. Here’s the same image as above rendered with web fonts.

Notice the missing ligature?

Since all browser that I care about seem to support OTF, I just went with the OTF version. The one outlier is Edge on Windows 10 that doesn’t display the ligatures correctly. Meh.

Mobile first, content first

It all started out on mobile. I did all of the design as “mobile first” and only later added the desktop layout. Well, I’d even say I did it all as “content first”—initially I edited all the content without any styling, then I made sure the layout and navigation works well on mobile, and lastly considered desktop.

Dark mode

A major difference from the Balzac Jekyll theme that I previously used is that there are no dark backgrounds anywhere now. Balzac has an inverted background for the footer. The reason for this is that Dark Mode is becoming first-class citizen in Mac OS X Mojave, and web developers will also be able to target Dark Mode with their CSS, which I fully intend to do once Mojave rolls out and the industry best practices around Dark Mode and web start to emerge.

I guess it will be a bit more than just inverting the colors—I expect there to also be less contrast, and maybe other adjustments. So while this site does not have Dark Mode right now, it’s compatible with it for the future. Maybe there will even be some automatic conversion done by Safari for simple sites, like Reader Mode? Interesting times ahead.

CSS and HTML

Jekyll has facilities for using SASS and other CSS preprocessors. I didn’t feel the need to use any of those and just wrote raw CSS. One reason to use preprocessors is to structure your CSS better so that deep selectors are more compact to write, but there are no deep selectors on this site—I just use CSS BEM. I remembered about BEM after I had written some initial styles already, and immediately switched to it, giving me a much cleaner way to navigate the styles and markup.

In the front-end site documentation, you’d usually write about CSS, HTML and JavaScript. I’m proud to say that other than Google Analytics, there is no JavaScript on this site. (And with Analytics getting increasingly blocked, e.g by Firefox these days, the value and validity of this kind of tracking is more questionable.) This might be fine and good, until you notice that in mobile layout, there is the top right hamburger menu that opens and closes a menu. How would that work without JavaScript?

The menu is an interesting trick I borrowed from Minima. The hamburger icon is actually a label for an invisible checkbox that tracks the state of the menu. Clicking the icon toggles the checkbox state, and CSS changes the appearance of the menu based on that state. Seems like a pretty neat trick: almost too much of a hack, and maybe against some purist dogma of how things “should” be , but quite practical, and lets me avoid any JavaScript.

The state of CSS is such these days that you can use standards-based solutions for things that required hardcoding or weird hacks in the past. Notice how in both header and footer items are distributed to the left and right, with varying space between them. There are no hard coded widths anywhere, nor floats or any other ugly solutions. This is easily done with CSS flexbox “space-between” justification that nicely spreads the items in a container.

I considered learning CSS Grid for this project too, but I have never done anything with grid, and it seemed like a bit of overhead for this time. In the desktop footer layout there is some double-flexbox (flex within flex) going on that would probably be cleaner with a grid, but this will be for another time.

Jekyll

I’ve found Jekyll to work well for my needs, so I continue to use it without too much of a change from the previous site version. The biggest change is that I extracted the theme into a separate gem, instead of keeping it within the site code. I have two sites with the same design: in addition to this one, also my Estonian-language site. Previously, all the layout and CSS was duplicated to both sites, which is exactly as dumb as it sounds. Now I can remove the duplicate assets from both sites and they just link to the gem theme.

I considered publishing the gem theme, but am not choosing to do it right now, largely because I don’t want to distribute the full Calendas font in this fashion. If you find the theme interesting and would like to use it, though, do let me know and let’s work something out.

The one workflow issue that I found with gem themes: if you edit any embedded assets, Jekyll can live-rebuild the site while the development server is running. If you edit the files of a gem theme, though, Jekyll doesn’t pick that up automatically, which means you’d have to manually trigger a rebuild, which is dumb. So during development, I ended up copying the assets over to the site, edit them, and after the session is done, copy them back into the theme for version control. Which is dumb. I wish there was a cleaner way to do this.

Let me know

Please do let me know if you spot any bugs with the new design. I did try to test the site extensively on the platforms that I care about (mostly meaning Apple computers and devices, and some Windows), but I’m sure there are bugs here and there.