How we built our website

How we built our website

After several months of work we’ve released the new version of our website softaware.at. We decided to set up the relaunch project just as a modern software project: based on agile principles and development tools. One consequence: we didn’t wait for the 100 percent solution until we went online: as soon as the new version was valuable and better than the old version, we let it go.

Minimum viable product

We’re a software development company. When creating complex software products it makes sense to define the minimum viable product (Wikipedia): Which features are absolutely necessary to go online? How do we get user feedback as soon as possible? How good is “good enough”? We decided to build our new website just like a software product: go online as soon as the new product is valuable and better than the old one. And provide features like additional content categories or an english version step by step.

Do we need a Content Management System (CMS)?

Usually websites are built using a Content Management System (CMS). Don’t know why, but I never got familiar with one of them. Although I see the advantages of WYSIWYG-editors (What You See Is What You Get) and design templates, I find it quite hard to achieve the last 20 percent of perfection/individualism. How to backup? Do I have to update to every single version of the CMS to avoid security issues? How to insert sourcecode sections that can easily be copied?

The alternative? Writing an ASP.NET application? Writing pure HTML and CSS? To cut the long story short: We don’t use a CMS for our website. We essentially rely on two components: a design template and a static site generator.

Design template

Designing and creating modern, animated, responsive websites is not an easy task. We are building web applications with a very unique design for some of our customers, but for our website we decided to buy a ready-to-use design template from the web. After trying out a few we chose the Porto - Responsive HTML5 Template. At the cost of 17 $ you get well-designed HTML pages and CSS styles, controls like carousels or progress bars, animations and much more. It really was a good starting point for our website design and saved a lot of time.

Static site generator: Jekyll

So how to write content? Should we create static HTML files or should we create a web application with a content database? We chose Jekyll instead. Jekyll is a static site generator: it transforms content files with optional code fragments (like if, for, include) to static HTML files. One of the available content formats is Markdown - a simple language to format text.

Let’s take a look what’s necessary to create this blog post:

The content.

The blog post is written in a Markdown file. At the top some metadata information is present: things that would normally be written to a database can be added very easily to this section. We want to specify the author of the blog post? Just add it as a meta information.

The actual content can be formatted using Markdown, so bold/italic text or headlines are specified easily. Everyone in our company was able to write Markdown within an hour.

---
title: How we built our website
image: /blog/images/2017-02-28-how-we-built-our-website.jpg
category: codeaware
date: 2017-02-28
author: Roman Schacherl
lang: en
---

After several months of work we've released the new version of our website softaware.at. Because we were completely finished? No, just because the new version was valuable and better than the old version. This post shows how we built out website based on agile principles and software development tools.
<!–more–>

Minimum viable product

The layout

In Jekyll you can write layout templates that consist out of HTML code mixed with place holders (for the content) and simple control flow statements. Below you see a part of the blog post template. It depends on another template called default (for the menu bar and the HTML headers). We assign two variables to retrieve additional author and category information and use place holders like the {% raw %} {{ page.title }} {% endraw %} statement.

The creation of those templates was quite fast by copying fragments out of the Porto design template.

---
layout: default
---
{% raw %}
{% assign author = site.pages | where: "user-name", page.author | first  %}
{% assign c = site.data.blog-categories | where: "category", page.category | first %}

<section class="page-header">
<div class="container">
<div class="row">
<div class="col-md-12">
<ul class="breadcrumb">
<li><a href="/index.html">Home</a></li>
<li class="active">Blog</li>
</ul>
</div>
</div>
<div class="row">
<div class="col-md-12">
<h1>{{ page.title }}</h1>
</div>
</div>
</div>
</section>
{% endraw %}

Generating HTML.

Having those two files, Jekyll can be executed to bring layout and content together and generate static HTML files.

<section class="page-header">
    <div class="container">
        <div class="row">
            <div class="col-md-12">
                <ul class="breadcrumb">
                    <li><a href="http:///www.softaware.at/index.html">Home</a></li>
                    <li class="active">Blog</li>
                </ul>
            </div>
        </div>
        <div class="row">
            <div class="col-md-12">
                <h1>How we built our website</h1>
            </div>
        </div>
    </div>
</section>

Tooling

For our website we use the same tools that we use for software development: Visual Studio Code for writing files, GitHub for version control, TeamCity for the automated Jekyll build after each change and Azure to host the website. It just makes perfect sense to use this environment: writing a new blog post in the dev branch, creating a pull request, merging to master branch and automatically triggering the build server to update the public website.

Conclusio

I’m really happy with our new website. I think it’s worth reading and we’ve found a good balance between marketing and content. And I’m really happy with the way that we’ve chosen to create it. Looking forward to the next releases: an agile project is never feature complete.