Chris Kaminski • Blog

Building My Site: Design

Thu, 12 Nov 2015 00:09:09 +0000

When I decided to update my site, I wasn’t looking for a job — my current employer is a great company to work for. But having lived through the dot-bomb crash, the closing of two employers, the subprime crisis, and seemingly annual layoffs when I worked for Yahoo! I know that things can change quickly, and wanted to get my portfolio up to date. Just in case.

Faced with the task of redesigning a website that hadn’t been touched in a decade, I approach it as I would client work: gather the requirements, determine the process necessary, do the research, formulate the design principles, and execute a design.

Requirements

The goal of the redesign was to have up-to-date materials ready if I suddenly found myself needing to apply for a new job. So the functional requirements of the site were simple: make it easy to find and skim my CV and portfolio on the web, and allow users to download them for printing, filing, or emailing. It also needed to be easy to update the site so I could keep it current.

Non-functional requirements were equally simple. The design needed to present a contemporary, professional image that wouldn’t date quickly and would reflect my qualities as a designer: analytical and research-heavy with traditional graphic design training and a strong background in web technology.

Finally, to help potential employers remember me I wanted the site to operate with an identity system which included business cards and the PDF and print versions of my CV and portfolio. So the design had to translate well to other media and contexts.

Process

With such simple functional requirements, a full-on design process with user flows and personas and the like is overkill. Similarly, the content of the site would be dead simple: portfolio, CV. That’s it. No need for a site map or concept model.

The process would also be simple: background research, high-level content design and layout, then refine the visual design.

Research

With the basic requirements established, I began my research. First was a literature review of articles and the like on UX portfolios. Next, I did a competitive analysis of sites from other UX designers and agencies. Finally, I spoke with friends and colleagues who have hired UX designers.

The strongest theme that emerged from the research was that a UX portfolio needs to show process and thinking, not just outputs. That requires a ‘case study’ approach, with a balance between text and images: the images should illustrate text descriptions of my thinking, and the text should explain the context and function of the designs in the images.

Contrary to my expectations (and my own experience when hiring), many employers do look at portfolios on mobile phones. So the design not only had to be responsive, but had to work on slow network connections or if JavaScript failed to load.

As well, hiring managers I spoke to said that their biggest problem when hiring is sifting through the large number of applicants. When they first review a portfolio or CV quickly they look as much for reasons to discard an applicant as for reasons to contact them. So unlike a visual design portfolio, where showing your style is important, for UX it’s more important not to make a bad impression than it is to ‘wow’ the visitor.

It also was clear I needed to do more than just show my work. I needed to show how I think and communicate about design, and that I do so outside of the strict confines of client work. The easiest way to do that would be to include a simple blog.

Principles

The insight from my research, together with my requirements, yielded a set of design principles:

Content over UI: follow a Beatrice Warde ‘Crystal Goblet’ approach, aiming to enhance the experience of the content rather than the UI being the experience itself.
Be fast and responsive: avoid heavy script libraries and images, except where they are absolutely necessary (e.g. to illustrate my projects in the portfolio), and ensure the site works a wide range of hardware and software.
Make it modern: make judicious use of modern web techniques such as web fonts and CSS transitions to add some richness and demonstrate that I keep up to date with technology.
Keep it simple: avoid complex layouts and bespoke pages so that when I update the site I can focus on creating the content, not copyfitting or production.
Stay true to the web: the site is a collection of documents, not an app, so it should employ traditional web conventions like underlined inline links and visited link styles.
Emphasise typography: even on image-heavy portfolio pages there will be plenty of text, so pay attention to typographic details like curly quotes, letter spacing, and hanging bullets.

Solution

I started with a CV layout that I’d been honing for some years: name and contact details at the upper right where they’re visible when thumbing through a stack of pages, blank space below for notes, generous left margin for stapling or sticking in a folder. With the main navigation inserted to the left it also worked well for the web at desktop/large tablet sizes, leaving a nice clear column, sized relative to the text to keep an optimal line length for reading. Using position: fixed; on the header and navigation allowed me to keep my name and contact and download links always handy.

In narrower viewports, I prioritised keeping the content column at an optimal width so images would remain as large as possible. That meant moving first the header, then the navigation to the top. When the navigation moves up, the header switches sides so the top line reads across: ‘Chris Kaminski: Blog, CV, Portfolio’. In very narrow widths, the navigation drops to the bottom to avoid excessive scrolling

Did want to demonstrate visual design background, so good typography. Also an old-school web person, so wanted it to be of the web: responsive design, underlined links, visited link styles.

Finally, I wanted the mood to be cool and modern to reflect the fact I work with digital products, and take a analytical, research-heavy approach to design.

typography

Wanted to use a single font family: in line with minimalist philosophy, not so much to download. Also, most of the best pairings are with serif fonts, but serif fonts tend to have a warmer, more classical mood than I desired.

Because I wanted to restrict myself to a single family, the font had to work in print as well as on the web. I also wanted a variety of weights so it wouldn’t get too monotonous.

FF DIN https://www.fontshop.com/families/ff-din DIN Next http://www.linotype.com/517415/DINNext-family.html

I’ve always had a soft spot for DIN, despite the fact it’s something of a design cliché. In fact, I initially wanted to use FF DIN, an update of the classic DIN font by Albert-Jean Pool, for this website (and my CV, business cards, etc.) but just couldn’t justify the licensing costs for personal use. I also looked at DIN Next by Akira Kobayashi, but wasn’t fond of the way rendered as a web font, particularly the bolder weights.

So I looked at alternatives. News Gothic offers a vertical emphasis somewhat similar to DIN, but only comes in a limited number of weights. I looked at Roboto and it’s predecessor Droid Sans, but they’re frankenfonts, and in any event too closely associated with the Android platform — I’m not a Google product. I’d used Helvetica Neu for previous versions of my CV, but it just felt too ‘upscale design studio’ for the website. I also tried Futura, which I’ve always admired, but for body copy…no. It would need a second face, and I’d already ruled that out.

Then Paul D. Hunt used it as inspiration for Adobe Source Sans.

Source Sans doesn’t have vertical emphasis of DIN or News Gothic, and carries a bit more warmth than either. But it does have

colours

white: respectful of environment & potential employers (doesn’t waste printer ink); black prints text clearly regardless of printer (grey may suffer from halftoning/blurry edges); red prints OK on monochrome, adds a bit of colour/interest on colour and stands out against both the white BG and the black text.

layout

on CV, name & contact details in upper right as when stapled, paper-clipped, put in folder people using left-to-right languages fasten on left & riffle right edge

on web, no riffling but wanted to balance navigation, traditionally on left; smaller widths, logo on right: tablet view has nav on top, reads badly with logo on right; on mobile, nav on bottom but right-aligned logo is unbalanced

Width defined by max comfortable line length for 16px text, margins and spacing also defined by text size.

The Movie Blurb Dialogue

Fri, 14 Aug 2015 00:00:00 +0100

‘Astonishing…breathtaking!’

— Ralph Stuffyshirt, The Daily Bungle

Consider the movie blurb: a fragment of text splashed across an ad for a mediocre film. It gives the impression of clarity without actually offering any. What is ‘astonishing’? The quality of the special effects? The director’s incompetence? The blurb lacks the context you need to understand it.

So too with Apple’s iCloud Password dialogue.

This dialogue popped up as the result of a bug in OS X. Putting aside the annoyance of the bug, this dialogue still has a problem: it lacks context. Why do I need to enter my password? More importantly, which app is asking for my password? The movie blurb at least states the source. The dialogue does not, nor is it a sheet attached to an application window. And it just interrupted my work at random, not in response to anything I did. There is know way of knowing which app spawned it or why.

That’s a problem. Just as the movie blurb tries to convince you to spend your money on a crappy film, this dialogue could be asking me to give my iCloud password to a malware author. Training users to enter their password whenever asked makes them likelier targets for phishing attacks. That’s crossing-the-streams level Bad.

There’s a better way.

Adding the name of the source application to the dialogue won’t cut it, as the dialogue would still be easy to spoof. Launching the app isn’t the answer either: doing so without the user’s permission interrupts their work for something that doesn’t necessarily need immediate attention. Enter the notification banner.

Notification banners let the user know something is amiss without interrupting their work. This banner also tells the user it’s OS X that needs my iCloud password. And if I click on ‘Enter’, the banner can give me proof:

Moving the password request to a sheet attached to the iCloud preference pane gives reassures me that it is, in fact, OS X asking for their password and not some dodgy application or website.

Like unwanted cameos in movies, software bugs happen. But software shouldn’t subject us to the movie blurb treatment when they do. Always give the user as much context as you can, regardless of the situation.

Y! Security

Tue, 11 Aug 2015 08:29:06 +0100

Whenever I travel out of the UK, the first time I connect to the internet with one of my gadgets I get an email from Yahoo! stating they detected a sign-in attempt from an unrecognised device in {name of the country I’m in}, and asking me to sign in with the device I ‘usually use’.

Huh? I just signed in with a laptop/phone I use every day. What gives?

Usability and security aren’t comfortable bedfellows. Indeed, the point of security is to make a device or system unusable to most users. Where the two fields meet, the result is often awkward. Yahoo’s ‘unrecognised sign-in’ process is a classic example.

Disclosure/disclaimer: I worked at Yahoo! for 5 years. I still know people there. I am not second-guessing their decisions, as I don’t know the technical, legal, and economic constraints they are balancing. Rather, I am highlighting the difficulty of balancing security and usability in a mobile, multi-device world.

Presumably, Yahoo! is using some combination of a software identifier (such as a cookie) and some form of geolocation to determine whether you’ve signed in from that device before. It’s a security feature, designed to detect when a sign-in attempt is being made by someone other than the account owner: if the sign-in comes from a country other than the one the account holder is usually in, it gets flagged as a possible hack attempt. But the email isn’t clear. They mention ‘keeping your account safe’, but don’t explain what they think is happening and why.

Google sends a similar email when you add your Google account to a new device, but they are much clearer about what is happening and why:

Why are we sending this? We take security very seriously and we want to keep you in the loop on important actions in your account.

We were unable to determine whether you have used this browser or device with your account before. This can happen when you sign in for the first time on a new computer, phone or browser, when you use your browser’s incognito or private browsing mode or clear your cookies or when somebody else is accessing your account.

They also don’t require any action if the sign-in attempt was legitimate. Yahoo! asks you to sign in with your ‘usual device’. But which usual device? Phone? Laptop? Work laptop? I sign in from all three daily. More, I’m out of country. What if I don’t have my ‘usual device’? Will my account be locked? Will I still get email?

Some years back, Yahoo! used to ask you to sign in to your Yahoo! account via the web, so I tried signing in to my Yahoo! Mail account via the web. I got another email much more like the Google email, telling me I’m all set if the unrecognised sign-in attempt was from me.

Building My Site: Server Side Code

Wed, 24 Jun 2015 00:00:00 +0100

In my first post, I explained how I’m using Jekyll, Git, and bash aliases to publish this site. I chose this setup because it keeps the server-side of things simple: there’s no database, and no code executing when a page is served. Just some markdown files which get mushed together with templates to produce static HTML files.

For the most part, the site follows that simple formula. But there are a few instances where I need a bit more control over formatting, or a bit of logic to avoid maintaining links by hand. Enter the YAML serialisation format and the Liquid template language.

Most of this site is pretty vanilla, and since the Jekyll documentation is quite good I won’t rehash the basics here. Similarly, the Wikipedia YAML article and Liquid documentation provide good guides to YAML and Liquid, respectively (the Shopify Liquid documentation is also good). Instead, I’ll focus on how I’ve applied these technologies to the specific needs of my site.

CV

Markdown sacrificies sophisticated formatting to be easy to read and write. That’s great for basic article pages like blog posts. But a cv needs to communicate a lot of information quickly, and so requires more sophisticated structure, and formatting to communicate that structure.

The most straightforward way to add that structure is to put the markup directly in the markdown, but that means instead of writing markdown like this:

* __Web Standards Project, Jul. 1998–Mar. 2007:__ Served as project manager and volunteer coordinator during launch. Founded task forces and served on the steering committee. Wrote and edited opinion pieces and press releases. Promoted initiatives in online communities and email lists.

You write HTML like this:

<li>
	<h2><strong>Web Standards Project<span> • </span></strong>Jul. 1998–Mar. 2007</h2>
	<p>Served as project manager and volunteer coordinator during launch. Founded task forces and served on the steering committee. Wrote and edited opinion pieces and press releases. Promoted initiatives in online communities and email lists.</p>
</li>

It’s less legible, and also more brittle: miss out a </ul> and you have a broken page. For a write-and-forget page that’s not a big concern. But if I’m looking for a job I need to be able to tweak the text to match the role I’m applying for. Each edit is an opportunity to break the HTML, one I seem constitutionally incapable of declining.

I also need a PDF version to print or send via email. It’s possible to generate a PDF from the HTML version, and printing to PDF from Safari will even get you working hyperlinks. But getting a precise print layout with HTML + CSS is still more time-consuming than with a word processor. Until I polish up the print styles for my CV, I’m stuck with two versions and copying changes between them. Cutting and pasting around HTML tags just is just begging for errors, but wrapping structured text with repetitive HTML is exactly the problem template languages like Liquid were designed to solve.

A CV is mostly a series of lists: previous roles, skills, and so on. This is the perfect sort of data for YAML, which lets you create lists and key-value pairs with a bit of plain text formatting:

- company: Web Standards Project
  dates: Jul. 1998–Mar. 2007
  description: Served as project manager and volunteer coordinator during launch. Founded task forces and served on the steering committee. Wrote and edited opinion pieces and press releases. Promoted initiatives in online communities and email lists.

I then use Liquid for loops to iterate through the various lists and apply the appropriate markup, using if blocks to hide sections that aren’t present (descriptions for very old jobs, for example):

<ol>
	{% for job in page.experience %}
	<li><h2><strong>{{ job.company }}<span> • </span></strong>{{ job.dates }}</h2>
		{% if job.description %}<p>{{ job.description }}</p>{% endif %}
	</li>
	{% endfor %}
</ol>

This system minimises cut-and-paste errors and makes it quicker to adjust the markup as there’s only one list item of any given type to amend. It works well enough that even once I refine my print styles to the point I can generate the PDF by printing the web page, I’ll still want to use YAML + Liquid (or something similar) to generate that page.

Portfolio

Unlike the CV, it’s unlikely I’ll ever work out a system for generating web and PDF versions of my portfolio from the same source. For one, the PDF is a single multi-page file where on the web each project really needs its own page to keep downloads manageable and facilitate direct linking.

As well, many of the images were originally vector diagrams. The can be embedded in a PDF as native vectors without making the file size ridiculous. But they’re too complex to convert cleanly to SVG files, and even after GZIP compression the files are often larger than web-resolution PNG counterparts.

Finally, a layout optimised for print is typically very different than one optimised for responsive display on the web, and each page of the PDF is formatted uniquely for its content. That’s no big deal when using grids in a layout program. But with HTML + CSS, changing the content also means changing the CSS, and maybe the markup, and then re-testing across multiple browsers. Separate versions of the portfolio for print and web are probably here to stay.

Fortunately, the items in my portfolio are basic article-type pages, so markdown works fine and makes it easy to cut-and-paste between the web and print versions. So I could have created these as ‘static’ Jekyll pages, but I would have had to create the portfolio index and section navigation by hand. Instead, I’ve used a collection.

Recent versions of Jekyll have built-in support for collections, which are sets of related pages with their own namespace and properties. Unfortunately, my web host only supports an older version of Jekyll. So instead I used the jekyll-page-collections plugin.

It’s easy enough to use: just drop the plugin file into Jekyll’s _plugins directory, add your collection name to a collections: list in the _config.yaml file, and create the pages in the collection in a directory with the same name as your collection but preceded by an _. You have to name collection pages with the w/yyyy-mm-dd-[slug] convention used by Jekyll posts, but that makes it easy to reorder them by changing the dates or to hide a page by removing the date entirely (e.g. to change the list of projects for specific job opportunity). Jekyll permalinks keep the URLs tidy and consistent, regardless of the dates in the filenames.

For the subnav and portfolio index, I add a description, navigation name, and thumbnail image to the YAML front matter for each project. I then loop through the collection to generate the appropriate list. Everything about a given project (save images) is in one file, which makes for easy updates.

Images

Images are really the only part of the site that required a bit of cleverness on the server side, and even then the solution is pretty simple.

Markdown allows you to embed images, but it’s really basic: it only allows for title and alt attributes; no class or id. So there’s no way to float the image. And if you need a caption or link, you’re out of luck.

So instead of placing the images inline, I put the images for a project or blog post in the YAML front matter, like so:

images:
  - small: it-portal-concept-model-small.png
    large: it-portal-concept-model-large.png
    caption: Concept model
    alt: Content model

Then in the post, I use an HTML comment to place the images:

<!-- image1 -->

Using an HTML comment has two advantages. First, markdown processors ignore HTML, so they won’t munge it. Second, if something goes wrong and it doesn’t get replaced with an image, there’s just a tiny, nonsensical comment in the page source rather than visible breakage. One could argue this is abusing HTML comments, which should only be actual comments. But logically, if everything is working it never gets into an HTML document, so arguing HTML purity seems a bit daft. And from a practical standpoint, Apache SSIs have been ‘abusing’ comments for a couple decades now with no harm done. If you’re still not persuaded, this is where the people who care live. Tell them your trouble.

In my templates, I assign the rendered HTML page content to a withImages variable, then us an if statement to check if the page has an images array. If so, I loop through the array one at a time. For each iteration, I generate a replacement slug:

{% capture slug %}<!-- image{{ forloop.index }} -->{% endcapture %}

I use another Liquid capture block to capture the HTML for the image, filed with the values from the current image from the images array. As with the CV, I use for statements to include only the elements (classes, link to an enlargement, caption, etc.) present for that image. I then use the Liquid replace filter to replace the HTML comment in the text with the image markup:

{% assign withImages = withImages | replace:slug,markup %}

All that goes in a Liquid include for easy maintenance.

Back in the template, I output the contents of withImages into the page. I could just do the replacements right in the content variable, but it seems prudent to keep the unadulterated page content around.

The system is a bit brittle, as it requires knowing exactly what order images are in the YAML array. But as the array is defined in the same file as the slugs are placed that doesn’t concern me overmuch.

As well, this sort of output filter could arguably be better implemented as a Jekyll plugin written in Ruby, if only for performance reasons. But as it only runs for pages with an images array, and I’d want to be able to edit the HTML templates without digging into Ruby, the benefits to doing so seem small.

Bottom line, I’ve got a way to place images wherever I wish within an otherwise-vanilla markdown page and include classes (e.g. for floating them with CSS), a link to an enlargement, alt text, and so on. I can extend it whenever I like by editing a single include file and, provided the enhancements are wrapped if statements, old pages will continue to work undisturbed. Eventually, managing all the if statements may get cumbersome, but for now it does the job.

The last little bit of Liquid-fu is the navigation for posts belonging to a series, like this one. That’s accomplished by looking for a series property in the YAML front matter of each post as its rendered. I could have used page.tags or page.categories, but a series doesn’t seem to me to be the same thing as either. Rather than piggyback on a not-quite-right property that might cause headaches should I decide to categorise or tag my posts later I elected to create my own property specifically for series of posts.

If the series property is there and has a value, I loop through the build-in Jekyll site.posts collection, testing each for a matching series. When I find one, I add a link to that post to the text in a variable. When I’m done collecting links, I place the contents in the page. It looks like this:

{% for post in site.posts %}
	{% if post.series == page.series  %}
		{% capture series_nav %}
<li><a{% if post.title == page.title  %} class="active"{% endif %} href='{{ post.url }}'>{{ post.title }}</a></li>{{ series_nav }}
		{% endcapture %}
	{% endif %}
{% endfor %}

The existing series_nav is inserted at the end the capture block because the site.posts collection is in reverse-chronological order. I want the posts in the series navigation to be in chronological order, so I have to put each new link before the ones I’ve already created.

Also, to get the active page indicator I test to see if the post.title of the matched post is the same as the current page.title and add a class if it is. Using a content property like this is a bit dirty; it’s generally better to abstract this sort of thing into an ID. But since both sides of the test are reading a value derived from exactly the same bit of text in the same file, the dangers seem minimal and it avoids having to add an additional ID property to the frontmatter.

When this blog has more posts, looping through every post on the site may get prohibitively slow and I’ll need to look into something more clever. But as with the images system, for now it does what I need.

Escaping Liquid tags

The last bit worth mentioning is something I ran into while writing this post: escaping Liquid tags for inclusion in code samples.

My Jekyll installation uses an older version the Pygments syntax highlighter that doesn’t support Liquid (the most recent versions does, but I can’t use it because shared hosting). Instead, I’ve resorted to using Pygments’ HTML lexer and escaping the Liquid opening tags as a Liquid literal ({{" "}}), like this:

{{"{%"}} highlight html %}
	<h1>{{"{%"}} post.title %}</h1>
{{"{%"}} endhighlight %}

I got the idea from a post by Scott Tesoriere. It looks gnarly, but it works (as a sidenote, the double-escapes above were created using {{' '}} to escape the escape).

That’s pretty much all there is to the server-side code for this blog. So far, it working exactly as I hoped. Editing and adding pages is much quicker and less error-prone with YAML and markdown than were I editing HTML directly, and editing the Liquid templates and includes is considerably easier than mucking about with gobs of repetitive HTML. For once, it seems the ‘simple solution’ actually is.

I ♥ San Francisco

Tue, 16 Jun 2015 00:00:00 +0100

If you follow typography or Apple at all, you’ve probably heard the upcoming iOS9 and Mac OS X El Capitan will use San Francisco as their system font, rather than the controversial Helvetica Neue.

I love the change.

I fell in love with San Francisco the moment Apple introduced it as the font for the Apple Watch. I love its clean lines, slightly compressed letterforms and generous horizontal spacing. It has a precision-machined feel to it reminiscent of DIN 1451.

I tried it out as my system font using the technique described in this Gizmodo post and absolutely loved it for both aesthetic and legibility reasons. This Wired article discussing the switch from a typographer’s perspective pretty much sums up my impression.

Sadly, the early versions of the font didn’t have all the glyphs and weights necessary to be a system font in OS X. The resulting display glitches ultimately convinced me to switch back. That won’t be an issue anymore.

Apple has now posted official versions of the font for download, along with tools for working with fonts in OS X and iOS and specifications for the TrueType fonts and their ‘advanced’ font rendering technology. They’ve also posted a video of the WWDC session on San Francisco.

Back in the day, Susan Kare’s ‘city’ fonts — New York, Chicago, Geneva, and Monaco — were staples on the Mac. Apart from Monaco, which is still in use as the default monospace font in OS X, they’ve mostly fallen by the wayside since OS X replaced Chicago and Geneva were replaced by Lucida Grande as they system font in OS X 10.0. San Francisco is a welcome revival of the series.

This post was also published on the Tobias & Tobias blog.

Building My Site: Publishing

Wed, 10 Jun 2015 00:00:00 +0100

I finally built a blog.

To get past the blank page problem (and for my own future reference), I’m going to write a few posts about how I did it and why I did it that way. I’ll start with the publishing process.

About a year ago, I decided to redesign my 10-year-old portfolio site. As my career focus had settled on UX design, I took a Beatrice Warde approach: I wanted the site to be ‘transparent’, to just present the content as simply as possible with a minimum of technical and visual flourishes. That meant keeping both the technology and the design as simple as possible.

So when I decided to add a blog I chose to use Jekyll, which publishes a static site (i.e. just plain HTML pages served straight from the filesystem), rather than something like WordPress, which assembles pages using text pulled from a database and various bits of code. Vito Botta has written some rather thorough posts on the advantages and disadvantages of Jekyll relative to WordPress, if you’re interested in that sort of thing. What swung the decision for me were WordPress’s ‘security’ (I’ve been bitten by that before), constant updates, and the relative complexity of implementing a custom design.

The downside of Jekyll is that to publish, you have to use whatever computer hosts your Jekyll source files to build the site, then move the files to the server. That means no editing from, say, a smartphone without setting up SSH access to the main machine. It also means no remote editing without opening a port on your home router. Ugh.

The ‘simple’ solution is to run Jekyll right on the server and have the source files there. It’s still pretty secure, as you need to be able to access the shell to run Jekyll. And it allows me to build the site and move the files into position with a couple of shell commands. First I run:

jekyll build –source [jekyll directory] –destination [directory to build the site in]

Which builds the site in a ‘safe’ directory. Jekyll clears everything out of the directory before putting the site files in, so I don’t want it just building to the www directory.

Then I run:

cp -r [directory the site was built in]/. [www directory]

Which overwrites the old site files with the new ones, but leaves everything else alone.

Of course, I also want to be able to test the site in my live environment before actually making it live. By default, Jekyll assumes everything will be placed in the www root, so just publishing the site to a subdirectory will break the links unless you change the default site path in the configuration file. Rather than risk putting the wrong configuration live, I created a subdomain on my site (staging.setmajer.com) and publish to that.

The drawback to generating the site on my server is it leaves me editing remotely, which means some combination of a command line editor, no offline editing, lag when saving, or edit, then upload to view your changes. None of which is ideal.

I needed source management anyway, so I decided to use Git to keep everything in sync. I created a bare repository on my server and set that as the master for the working repository on my local machine. Next, I created a second repository on the server to be a working repository so I can edit remotely via SSH when needed. I can also set up Git repositories and Jekyll on my Dell Venue tablet, my work laptop, etc. As long as I remember to commit my changes, all should be well.

I could have used Github for the master, but getting to grips with Github seemed like another layer of complexity. Plus, I’m not ready to display my ropey liquid templates to the world just yet.

It’s working fine so far in tests with my home and work laptops. The next thing I need to do is find an editor for my iPad, Moto G, and/or Kindle that will let me edit offline and then push the edits onto my server when I have connectivity.

Even after creating shell aliases to combine commands, the setup feels like it’s too clever by half. Just look at how much verbiage it took to explain it (and well done you for getting this far — now for the love of dog go find something more interesting to do, like watching some paint dry). That said, it does seem more straightforward than many of the deployment methods documented on the Jekyll site, and lets me control where and when to deploy without mucking about with Git branches or the like.

In any case, 17 years after I first launched setmajer.com I finally have a live and usable blog. That’s something, anyway.