Published on <a href="https://blog.prototypr.io/using-jekyll-for-rapid-prototyping-31d5419b8d94?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Lucas Lemonnier <img alt="" src="https://cdn-images-1.medium.com/max/1024/1*BeqbOR7zUVIFD7Qk-yFrpw.png">
As a front-end designer, I increasingly find myself working on UI/UX projects and design systems (styleguides). There is no debating the fact that the toolset, frameworks, and configuration for front-end projects have gotten pretty complex: Gulp, Webpack, transpilers, PostCSS, CMS, Servers… the list goes on and changes frequently.
Some or all of these will be necessary for building out a validated project, but during the design/experimental stage I really like to keep things lean. Straightforward HTML/CSS/JS allows me to just dig in and spend my time designing and coding up demos, rather than wrestling with build tools.
<h3>Minimal needs for rapid prototyping:</h3>
This lean dev environment should still provide me with a few tools to maximize timelines and client budgets. While I may add features specific to certain projects, there are 5 must-haves for every project to make me productive:
<ol>
<li>Templating system</li>
<li>Accessing and storing data</li>
<li>Variables</li>
<li>CSS preprocessing</li>
<li>LiveReload and AutoPrefixing</li>
</ol>
TL;DR: If you’re curious about why I consider these so important, I’ll break them down next. Otherwise, go try out the <a href="https://github.com/luclemo/jekyll-starter">starter project</a> I created.
<h4>1. Templating system</h4>
This allows me to keep my code <a href="https://en.wikipedia.org/wiki/Don%27t_repeat_yourself">dry</a>. For example I might have a user settings menu which gets called into different views or even multiple times within a single view. A templating system allows us to create a partial (e.g., user-nav.html) which we can then include into different templates.
Partial (user-nav.html):
<pre>&lt;nav class=”user-nav”&gt;&lt;!-- ... --&gt;&lt;/nav&gt;</pre>
View (logged-in.html):
<pre>&lt;html&gt; &lt;head&gt;&lt;!-- ... --&gt;&lt;/head&gt;</pre>
<pre>&lt;body&gt; &lt;header class="main-header"&gt; &lt;nav class="main-nav"&gt;&lt;!-- ... --&gt;&lt;/nav&gt;</pre>
<pre>Liquid error: This liquid context does not allow includes.</pre>
<pre>&lt;/header&gt;</pre>
<pre>&lt;!-- ... --&gt;</pre>
<pre>&lt;footer&gt;</pre>
<pre>Liquid error: This liquid context does not allow includes.</pre>
<pre>&lt;/footer&gt;</pre>
<pre>&lt;/body&gt; &lt;/html&gt;</pre>
Final output:
<pre>&lt;html&gt; &lt;head&gt;&lt;!-- ... --&gt;&lt;/head&gt;</pre>
<pre>&lt;body&gt; &lt;header class="main-header"&gt; &lt;nav class="main-nav"&gt;&lt;!-- ... --&gt;&lt;/nav&gt; &lt;nav class="user-nav"&gt;&lt;!-- ... --&gt;&lt;/nav&gt; &lt;/header&gt;</pre>
<pre>&lt;!-- ... --&gt;</pre>
<pre>&lt;footer&gt;</pre>
<pre>&lt;nav class="user-nav"&gt;&lt;!-- ... --&gt;&lt;/nav&gt; &lt;/footer&gt;</pre>
<pre>&lt;/body&gt; &lt;/html&gt;</pre>
If you’ve ever built a WordPress theme with template-parts or used SASS partials, this concept should be familiar.
<h4>2. Accessing and storing data</h4>
I need a way to populate templates with real or dummy content using basic control flow statements (if, if else, and for loops). Example use case: a project calls for an FAQ. Rather than hard code that entire list, I can pull from a file which stores all the info in some form of structured key/value pairs:
<pre>faq: - question: "What is life?" answer: "😳" - question: "Creamy or chunky peanut butter?" answer: "Chunky!" # and so on...</pre>
From there I can use some engine to loop through it:
<pre>&lt;ul class="faq"&gt; &lt;/ul&gt;</pre>
Output:
<pre>&lt;ul class="faq"&gt; &lt;li class="faq__question"&gt;What is life?&lt;/li&gt; &lt;li class="faq__answer"&gt;😳&lt;/li&gt; &lt;li class="faq__question"&gt;Creamy or chunky peanut butter?&lt;/li&gt; &lt;li class="faq__answer"&gt;Chunky!&lt;/li&gt; &lt;!-- and so on... --&gt; &lt;/ul&gt;</pre>
This keeps our source files nice and tidy. If I need to make some changes to the markup, I’m doing it on a single instance rather than on 32 line items.
It also makes it accessible for anyone remotely computer-savvy to update content without touching a line of html and without the need for a full CMS.
<h4>3. Variables</h4>
In order to make quick project-wide changes or to include dynamic content, variables are a must. For example I could define a social url in one file:
<pre>socialUrl: "<a href="https://twitter.com/username">https://twitter.com/username</a>"</pre>
And call it locally in another:
<pre>&lt;p&gt;Find us on &lt;a href=""&gt;twitter&lt;/a&gt;!&lt;/p&gt;</pre>
We can also user variables for dynamic content such as timestamps etc.
<h4>4. CSS preprocessing</h4>
I love writing CSS. Still, the idea of going without variables, mixins, and nesting on larger projects is inconceivable to me.
Before you devsplain that I could <a href="http://postcss.org/">PostCSS</a> all the things: yes, thank-you. But remember I want to keep my tooling to a bare minimum and I want to use tools/syntax familiar to any team I may be handing off to. For now and for my purposes, SASS is a sure bet.
<h4>5. LiveReload and AutoPrefixing</h4>
If you haven’t heard of it before, livereload allows you to work more quickly by reloading your browser automagically every time you make &amp; save a change to your files. No more cmd/ctrl + R all day long. It&#8217;s a huge productivity boost.
And while browsers are moving in the direction of dropping prefixing, it is still very much a reality to ensure cutting-edge CSS doesn’t break from one browser to the next. That’s all fine, I just want it to happen under the hood.
<h3>Jekyll the the rescue!</h3>
If like me, you kept hearing about <a href="https://gist.github.com/jekyllrb.com">jekyll</a> strictly as a static blog generator, it’s actually way more powerful than that. It is a deceivingly simple file processor/smoosher built on Ruby and it ticks nearly all of the above boxes without any tooling:
<ol>
<li>Templating system ✅</li>
<li>Accessing and storing data ✅</li>
<li>Variables ✅</li>
<li>CSS preprocessing ✅</li>
<li>LiveReload and AutoPrefixing ❌</li>
</ol>
That last requirement is non-negotiable for my workflow, so I did some googling around and created a little starter project which does include livereload and autoprefixing.
You can <a href="https://github.com/luclemo/jekyll-starter">find it here</a> and take it for a spin.
<a href="https://github.com/luclemo/jekyll-starter"><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*vX4RvOe2nH147BASN8U55g.png"></a>
<h4>ps: Jekyll + Github = 😍</h4>
Jekyll is the very engine which powers github pages. This last point is definitely a bonus feature since most projects are developed in github repos anyway. Publishing a jekyll prototype to GH pages is literally one click away in the repo’s settings panel. From there, making changes locally and pushing live is literally just a commit away.
<h3>Dude, you could do all that with Pug &amp; Stylus!</h3>
Indeed, I love <a href="https://pugjs.org/api/getting-started.html">Pug</a> and <a href="http://stylus-lang.com/">Stylus</a> as a templating combo. However, there are a few issues with it:
<ol>
<li>The biggest show-stopper: there aren’t many teams around who use the duo which can make it awkward and costly when the time comes to handover code for production.</li>
<li>It requires handcrafting tooling for each project (using gulp or equiv.) which is exactly what so many front-end designers struggle with.</li>
</ol>
<h3>But why a starter project?</h3>
As I started exploring Jekyll for my specific purposes, I found a few things to be annoying with out-of-the-box jekyll:
<h4>Too much…</h4>
Starting a new jekyll project using the default jekyll new my-project always spits out a blog-style starter theme which is way too bloated both in terms of style and content.
<h4>Too little…</h4>
Starting a project using the more stripped down jekyll new my-project &#8211;blank doesn&#8217;t even give me a config file.
In both cases no LiveReload or AutoPrefixing.
It’s a work in progress and I will likely tweak things here and there, but if you’re a front-end designer looking for an efficient workflow without the tooling overhead, you might find this ticks a lot of your boxes as well ✌️
<h3>Useful Resources</h3>
If you’re totally new to jekyll, it might take you a couple of hours to get up to speed with the directory structure, understanding front-matter and using liquid (the templating language). However, the docs are very good and there is a large community behind it.
Honestly, it’s not too tough to get going by poking around the files and seeing what happens — it’s not heavy-duty programming. Either way, I’d say the initial investment is well worth it.
Here are a few links that helped me wrap my mind around it all:
<ul>
<li><a href="https://jekyllrb.com/docs/installation/">Installing jekyll</a></li>
<li><a href="https://shopify.github.io/liquid/">Liquid Templating Language</a></li>
<li><a href="http://jekyllrb.com/tutorials/navigation/">Creating navigation</a></li>
<li><a href="http://jekyllrb.com/tutorials/convert-site-to-jekyll/">Convert an HTML site to Jekyll</a></li>
<li><a href="https://youtu.be/8zSHG6XU_xY">Building Living Style Guides with Jekyll</a></li>
</ul>
Good luck and let me know if you hit any snags or see ways to improve this starter project!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=31d5419b8d94" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/using-jekyll-for-rapid-prototyping-31d5419b8d94">Using Jekyll for rapid prototyping</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Using Jekyll for rapid prototyping

Top Stories