alternatyves
Illustration. Design. Art Direction. Story Development.
· 5 min read

Portfolio relaunch

15th June 2019

Old is New

OK, so here is the 2019 version of alternatyves.com, a portfolio site built with Jekyll and TACHYONS.

Since the start, alternatyves always had a playful and experimental side.

alternatyvesoutc.com1 launched in 2008 on Indexhibit. Back then it was the latest cool thing to build artsy portfolios. The site design colors, fonts, and layout changed all the time. It was as much a place for showcasing work than it was a space for learning. A little bit of CSS first, bits of HTML, then some underlying PHP, then frameworks like Foundation.

It looked like this:

Screenshot, 2012

Exit WordPress

After a while, I migrated the site to self-hosted WordPress. The migration coincided with losing interest for that kind of experiments. At that point, I also had a hard time focusing on illustration because I was working in a lot of different styles. No matter what you do, people like to put things into categories and they will do so with your work too. The truth is, my work was somewhat difficult to showcase in a cohesive way. There were too many styles: storyboards, sketches, graphic design, cartoon, editorial, traditional illustration, collages… My portfolio ended up split into two sites. The first, showcasing illustration/design, would remain here. All the storyboards and pre-production work would find a new home at https://film-storyboards.com. That made sense. The storyboarding site launched in 2010 and is running on WordPress since then.

But maintaining alternatyves.com on WordPress was a pain so it ended up unattended for a long time. I like WordPress, but it was not the right choice and never felt right for this portfolio.

The theme itself, Hi-Response received no updates for a long time. While some of its features were great (grid, galleries, modularity) it also made WordPress harder to use as a content management system. The theme added clutter to the already cluttered interface for instance. It also used a completely different logic than the “native” WordPress logic. It got to the point where you ask why use WordPress at all if you are going to differ from its core functions that much? After writing my own theme for the storyboard site, it also wasn’t clear if the learning curve involved would lead somewhere new with WP.

Site builders

For some time Cargo Collective was a popular choice among illustrators and designers.

Squarespace set another standard for design/photography/illustration portfolios, solving the maintenance issues of WordPress.

Adobe is also present with Behance. Format, ArtStation, and many others are doing the same (SiteSpace).

Site builders are great, they let you get your work out there fast. Site builders are also new and shiny before their inevitable demise. When that happens, one of the issues you can have is the portability of the content. All in all, they also didn’t feel like the right choice for this project. These solutions somehow give you too much to chose from but lack flexibility in their inner work. And that’s the point: a personal portfolio should work for you. Building it yourself may or may not reflect your work in a more original way, but at least it gives you more control over how it works.

Also, a portfolio is somehow compact, but having a website is also about archiving things that do not always are at the forefront on display. I find value in less prominent works sometimes. So you can have the quick tour or get lost in the maze.

It’s again an opportunity to learn some of the more recent web development technologies. It never hurts from a design point of view, even if you don’t have to be a specialist about every single new framework out there.

Frameworks all fade away at some point, but learning how to design yourself gives you more flexibility.

Enters Jekyll

I used Jekyll for a side project, and it’s great. The idea behind Jekyll is that it turns your files into a static HTML site. You keep a copy of an entire site on your computer that you can mirror with git2 for any host to serve online. Jekyll rebuilds the site with each change. I found it much more logical than WordPress and easier as a starting point to build a simple website.

Tachyons

Tachyonsis a CSS toolkit based on using components. It saves a lot of time tweaking and re-writing CSS. Yes! 👍🏼[^1].

The new theme is loosely based on JKL + TACHYONS.

Gulp

Gulp automates a couple of tasks during development, mainly resizing images, files compression, and browser reloading.

Responsive images

Obviously, images are the most important assets for an illustration site. A static site is reasonably fast, but images can slow down things.

Serving responsive images is a must today, but this is a time-consuming task and not something Jekyll handles from the get-go. Jekyll Picture Tags does this well, however, you need to write custom calls for images in Liquid that look like this:

{::nomarkdown}<a href="/img/sky.jpg"><picture data-volume="11" class=".full .tc"><source sizes="(max-width: 480px) 100vw, (max-width: 1920px) 100vw, 960px" srcset="/img/sky-240-0fb558.webp 240w, /img/sky-480-0fb558.webp 480w, /img/sky-960-0fb558.webp 960w, /img/sky-1920-0fb558.webp 1920w" type="image/webp"><source sizes="(max-width: 480px) 100vw, (max-width: 1920px) 100vw, 960px" srcset="/img/sky-240-0fb558.jpg 240w, /img/sky-480-0fb558.jpg 480w, /img/sky-960-0fb558.jpg 960w, /img/sky-1920-0fb558.jpg 1920w" type="image/jpeg"><img class="gallery" src="/img/sky-960-0fb558.jpg" alt="Screenshot, 2012 night sky"></picture></a>{:/nomarkdown}

Keeping pictures markup in Markdown

There is a number of ways to call images in Jekyll: you can do it by writing HTML, Liquid or Markdown.

<img src="/img/sky.jpg">
<figure>
	<a href="/img/sky"><img src="/img/sky.jpg"></a>
	<figcaption>Night sky</figcaption>
</figure>

all will render as

Screenshot, 2012 night sky sky

Screenshot, 2012 night sky sky night sky

Depending on what you need each of this method is valid.

Markdown doesn’t render captions so you could add:

<figcaption>Night sky</figcaption>

or just write plain HTML

A short Ruby plugin helps to keep this even shorter as:

Galleries

To conclude, which technology is behind a site doesn’t matter—except when it does. It doesn’t matter for the end user, as long as it doesn’t get in the way. And that’s the point. For now, the site is easier to update by dropping images in a folder and using text files. Running it on a local server with a couple of commands before publishing is not that hard to do. Of course, there are downsides too. Using a word processor instead of a nice user interface is not one of them. Yet there are still things to improve, i.e. the way Jekyll handles images. This new configuration also has dependencies, like plugins and so on. Galleries need to be hard coded instead of drag and dropping images, there is room for improvement there. But it is a new start. And it means I can experiment again with my portfolio in the coming months.

Use and contribute to this theme

While this site’s repo with all images assets and a bunch of experiments is not public, the theme’s code will be available here on GitHub soon.

  1. alternatyves.com ancestor site 

  2. git is a distributed version control system, it enables people to write and publish files and revert any change made to the code at any given time. 

Next post chevronRight icon

Soon