Website for Jean Flanagan (2014)

A personal website for a science education and communication specialist.

This project was originally completed and worked on from 2013-06 to 2016-10.

This writing was last updated 2016-10-03.

My partner Jean Flanagan and I have a shared interest in writing, photography, and self-archiving. Over the years we’ve experimented with shared blogs and photo repositories on a number of different web services. We enjoyed working together but limitations in those services often made our projects feel ephemeral. So it made sense for us to pool our resources to make Jean a website to serve as a portfolio featuring her writing and photography. Jean would collect and edit her output and I would help her design and develop it.

Features of the site

Responsive design

The site was designed from small screens upward, using flexible images, fluid layouts, and min-width media queries. Typographic elements were tested out early on to ensure readability and appropriate scale and tone at different widths.

Content first

The first thing we started out with were full-length articles about science, already written and edited. Having content ahead of time meant that the site could be designed around actual words and images rather than lorem ipsum filler text. (I really don’t like using lorem ipsum if I can help it. 1) It was essential to the process to test typography and proportion with real content.

Designing in a browser meant that HTML prototypes were an early part of the process, right after sketching and rough notes. In the first week of active development, prototype code was being written that would evolve into the finished product.

Two text excerpts from a prototype of Jean’s website

Content excerpts from the very early stages of the site’s design.

Two text excerpts from a current version of Jean’s website

How the same content excerpts turned out in a later design iteration of the site.

The grid of posts on the home page on a large desktop screen

What the grid of posts on the homepage looks like on a large screen. This four-column grid is different from the single-column grid on small-sized screens and the double-column grid on medium-sized screens.

Jean takes beautiful photos, which I wanted to feature in a “full-bleed” format with photos taking up as much of the screen width as possible (without being so tall that they require vertical scrolling). The photo pages have a distinct layout from the writing pages to ensure that images are featured prominently without affecting the typographic measure of writing pages. Both layouts are able to feature edge-to-edge (margin-breaking) images, but the page proportions are different for each. Both page layouts feature images, but the photo pages tend to feature original photography, while writing layouts often make use of Creative Commons-attributed images.

Sample from photo layout

A screenshot of the photo layout on a medium-sized browser

Samples from writing layout

A screenshot of the writing layout on a phone-sized browser
A screenshot of the writing layout on a large desktop browser

Not every image is meant to be showcased, nor should every image overshadow the writing. For complementary images in writing posts, I crafted alternative styles for right/left floated images for large screens. These optional styles are automated through a Jekyll figure/image plugin that I wrote. The styles are flexible, reusable, and easy to maintain as well.

A screenshot of an image floated right alongside some text in a flexible layout

The image of Darwin’s finches floats right on larger screens, while it would be layed out in the center on smaller screens. View this page.


We wanted to make sure that some of Jean’s interests and personality were part of the site’s design. For example, the 404 page has a floating jellyfish animation which echoes her interest in marine biology.

Floating jellyfish vector graphic

A snippet from the 404 page, using CSS keyframes animations to translate an SVG image and shift the background color. The vector jellyfish illustration is by Michelle Site via Phylopic, licensed CC BY-NC.

Choosing Jekyll

Jean already had a personal WordPress site. I had helped her transition from the limited service to her own personal domain and host. However, Jean was still feeling constrained by limitations in configuration and design. I could certainly help redesign a WordPress site, but it would be a significant challenge since I have not ever made a theme from scratch, nor have I worked extensively with PHP. Building on existing themes was a sure way to end up with a compromised design with inflexible configuration. Hacking around in WordPress would only take time away from my developing my existing strengths in responsive HTML and CSS.

Both of us realized that WordPress was no longer a good fit. Jean wanted more control over content and flexible layouts, as well as an interface that wouldn’t involve fighting with a WYSIWYG editor or administering a content management system and database. The trade-off for ease-of-use and getting started quickly with WordPress was outweighed by a desire to publish independently and to develop a process that would be able to withstand servers misbehaving, databases being corrupted, or any of the pitfalls of locking in to a “platform”.

We chose Jekyll because it would allow for a high performance site with plenty of flexibility in design and configuration. We realized that there would be a learning curve for both of us, since I had only just gotten started with Jekyll and it would be new for Jean. A site built of flat files with neither a CMS nor server-side processing is limiting for some applications, but has great advantages in performance and maintainability. 2

Getting it right is difficult

Publishing something on the web is relatively easy, but designing a lasting home for creative output that you won’t be forced to abandon or migrate later takes a significant amount of time and effort. For this project, both design and content were weighed deliberately. Working content first informed the design. The layout, typography and other design elements had to suit the content well.

What I learned from this project

  1. Using lorem ipsum filler text encourages people reviewing the design not to read the text, which makes it difficult to judge legibility of body text until too late in the design process. Nathan Ford wrote some good words on this topic. Nathan Ford suggests reading tweets instead of ipsum, but I prefer a different approach. If I am constrained in my ability to design content-first, my current practice is to use unread content from my Instapaper queue, so my eyes will focus on trying to read in the working design or prototype. 

  2. I wrote more about my preference of minimal tools like Jekyll over tools like WordPress in an essay on why Jekyll