Jekyll

I’ve been asked a few times about (Jekyll) [https://jekyllrb.com/], what’s good about it and why I ended up using it for my portfolio and blog.

I could begin to explain the history behind Wordpress and other blog engines and make claims why they suck. The truth is, I choose Jekyll because its supported by Github Pages, the markup and fact pages uses Markdown was attractive and it seemed like a good challenge.

Github Support

Every GitHub Page is run through Jekyll and most read me’s you see in the repo’s are also rendering readme.txt or readme.md files from markdown into HTML pages. Though my portfolio isn’t running on GitHub pages, it’s probably the best place to set up a lean, git powered website in a matter of minutes.

Site Structure

Jekyll is a static, database-less file system consisting of posts, includes, layouts (templates). The whole thing sits un-rendered and a build commmand essentially converts markdown pages, includes, etc into a fully flushed out HTML/CSS/JS site.

The basic structure consists of:

.
├── _config.yml
├── _drafts
|   ├── begin-with-the-crazy-ideas.textile
|   └── on-simplicity-in-technology.markdown
├── _includes
|   ├── footer.html
|   └── header.html
├── _layouts
|   ├── default.html
|   └── post.html
├── _posts
|   ├── 2007-10-29-client-name.md
|   └── 2009-04-26-client-name.md
├── _data
|   └── members.yml
├── _site
├── .jekyll-metadata
└── index.html
Liquid

Liquid is the templating engine that powers Jekyll posts. Shopify and Squarespace all run on the same liquid templating langauge so despite being a designer, I figured learning the langauge would allow me to develop or speak towards the constraints around each platform, whenever a client project arose. Learning Jekyll’s liquid langauage has helped me develop SquareSpace sites dramatically. I’ll post an article on my SS workflow later.

.
├── _posts
|   ├── 2007-10-29-client-name.md
.

In each of my portfolio posts, I define a number of variables that define colors, title, client name, type of work and a host of others.

---

featured: true
type: mobile application
publish: true
layout: project

categories: mobile

cid: "whisk"
client: Whisk iPhone App
title: "Whisk"
role: "Product Design"

homeimage: hero.png
projectHero: hero.png
backgroundColor: "rgba(238, 235, 218, 1)"
accentColor: "rgba(220, 88, 69, 1)"
txtColor: "rgba(105, 144, 60, 1)"
---

My layouts and includes files display variables accordingly. For example, my header.html include consists of html markup and liquid variables to display titles, colors, descriptions, etc.

{% if page.title %}
	<div class="content--wide" style="color: {{page.txtColor}}">
		<article>
			<h1>{{ page.title }}</h1>
			{% if page.description %}
				<h4 class="description">{{ page.description }}</h4>
			{% endif %}
		</article>
 {% endif %}		
 ...
Looping

To display all posts, variables or other contents, I loop through the site.posts on my index.html with a snippet of code:

{% for post in site.posts %}
        {% if post.featured == true and post.type != "blog" %}
        ...

This block of code is a for loop, essentially telling the Jekyll build task to loop through posts contained in the site.postsfolder. The if segment assures featured posts and displayed and only projects, not blog articles. This could easily be done with Jekyll categories.

Gulp, bower and build tasks

My development is managed with Gulp, bower and a number of custom tasks that allow me to quickly run gulp commands from the command line to perform various actions. I’ll write more about this later.

If you have any questions, feel free to ask in the comments.

Mr. Amit Patel, 2016