Building a Portfolio with Jekyll

My attempt to take the plunge and finally code my own portfolio


Getting Started

A little over a year ago, I randomly registered the domain name freshpepper.co. Plenty of people host their portfolios or freelance work under funky pen names, and I figured I could be one of them. Since my friends are always giving me sass about the absurd amount of pepper I put on my food, I decided to put my quirk to use.

Of course, an entire year went by and I didn’t actually do anything with the domain. Frustrated by finnicky CMS options like WordPress and Squarespace, I knew I wanted to try coding my portfolio myself. When my renewal email arrived, I finally got my act together and started to build.

Yup, it really was that easy.

Based on recommendations from a couple of friends, I chose to build with Jekyll, a super easy static site generator. With just four commands on the command line, I installed Jekyll and had the skeleton of my site running locally. Then, completely sold by the beautiful landing pages of ThoughtBot’s framework kit Bourbon, Neat, and Bitters, I installed the set to handle the vendor prefixes, grid system and scaffolding of my site.

See? Pretty!

The Actual Development

I built desktop-first and everything went pretty smoothly as I moved all my old content over to the new design. As someone with a very limited development background, I was excited to find out how easily Jekyll automated certain tasks I was dreading, like manually building my homepage grid or making the “next/previous” project arrows actually link to the next or previous project. I was also super impressed by the power of front matter, which I used to populate the homepage grid items with titles, tags and thumbnails. From there, building out the individual pages was really quick because I’d already created the skeleton of the files for the homepage.

The homepage grid, automatically populated by a “for” statement with Jekyll.

Where I Got “Fancy”

Since practicing my development skills was the whole point of this project, I challenged myself to go a little further than my original static design. Once all the pieces were more or less in place, I began experimenting with the CSS to add some transitions on hover. For the homepage project thumbnails, I added a zoom and color overlay effect. For the footer, I designed a little pepper stamp and gave it some spin with a rotation transformation. For the next/previous arrows on project pages, I changed the fill and added a label that slides out from the side of the screen.

The pepper stamp in the footer changes fill and spins on hover.

Though I knew that Jekyll could populate the links to make the next/previous arrows function appropriately, I anticipated some difficulty (and maybe some hacky “display: none” CSS) in keeping the “previous” arrow off the first post and the “next” arrow off the last post. The concepts of “if” and “else” were familiar to me from my half-hearted attempts to learn JavaScript, but I’d never gotten far enough to understand how they might be implemented in an actual project. As it turned out, Jekyll’s “if” statement let me easily check for the existence of a previous page and only then display the previous arrow.

My next task was creating a sticky header that would stick everywhere but the hero section on the homepage. I absolutely positioned it with CSS and then used jQuery on the homepage to make it fade in after the visitor reaches a scroll depth greater than the hero’s height.

Coding the hero followed, and I had to learn a bunch of new tricks to nail down the effect I was after. I wanted the container to fill the viewport, so I set its height to 100vh. Then I wanted to make the homepage grid scroll up and over without the hero moving, so I set its position to fixed and gave it a z-index of 2. Since the viewport’s height and width can obviously vary, I used flexbox to make sure the hero graphic is always horizontally and vertically centered.

The hero section.

Full disclosure: My site also includes some jQuery that keeps the arrows vertically centered to the content section once the visitor scrolls past it to the footer. To achieve this, I highly recommend acquiring a developer as a roommate.


Where It All Went Wrong

When the desktop view of my site was finished, I was feeling pretty good about jumping into mobile because I’d it set it all up using Neat’s grid system. Neat uses a mixin called omega to remove an element’s gutter margin, so I put it on every third child in my project posts on the homepage to create the three column grid. Unfortunately, the generated nth-child selector can’t be properly overwritten when switching the number of columns, so it became problematic as I tried to make a two column grid for tablet widths and a one column grid for mobile. At this point, I went and calculated my grid and column widths manually, though I later realized I could have just kept the mixin out of the original declarations and only used it within a media query for large screen sizes.

The Mobile Menu

Finally, only one task remained: making the navigation mobile-friendly. I added the word “Menu” to a new unordered list in the header and set it to “display: none” by default. At the appropriate breakpoint, I hid the regular unordered list and swapped it for my new one, adding a “slideToggle” function with jQuery to get the regular navigation list items to display on click.

Room for improvement

What’s supposed to happen.

As a finishing touch, I decided to have the hero graphic fade in with Daniel Eden’s animate.css, but unfortunately, it doesn’t always work. I know it’s because the animation has completed by the time the page actually loads, but all my attempts at page speed optimization, setTimeout and document ready functions have failed. If you have a suggestion for how to fix this, or any other improvements I might make, please let me know!


One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.