Blog Secret Santa's problems from last year and this year's fixes

Last year’s Blog Secret Santa was fun, for the most part. The platform was totally hacked together in the fewest hours possible, using as much code from CS Workflow as possible. People could sign up with their Twitter accounts, at a certain time they would get matched with someone to write for, they could add their gift post, and it was delivered at Christmas.

The platform worked well, even if it didn’t look very nice. We foresaw most of the problems that came up, but decided to fix as they came up. Everything we came across last year has a fix for it this year. This post goes into some detail about each of these problems and resulting fixes.

Niche content strategy theme

A few people wanted to join, but didn’t fit in the content strategy theme. One of the bigger changes this year is that we’re supporting multiple groups so people can join topics that suit their blogs and interests.

At the moment registering new groups is manual. Someone contacts us saying they want to start a new group. We check them out and see if we think they’re elf material, then setup the group and invite them to elf it. We’re not expecting a large amount of groups this year so haven’t bothered building out a group onboarding process.

Almost everything is taken care of, all elves have to do is drum up interest in joining their group. It doesn’t have to be a large group, just more than 3 will mean random matches can be drawn.

People pulling out

Less than a handful of people pulled out after they were matched. Fortunately we had a few people on an unofficial waiting list that could replace them. This was a manual process though.

Now elves can easily remove a player or replace them with someone on the waiting list. We’ll also add more communication with other affected people. The biggest problem is that if someone pulls out then the person writing for them has to tailor their gift for a new person.

No real waiting list

As I mentioned before we had an unofficial waiting list. Now people who register after the match cut off go on the waiting list. Elves can see the waiting list. If someone pulls out the elves can replace them with someone from the waiting list. Elves only have access to the group they are elfing for.

What we need to improve how people on the waiting list are communicated to. If we made no changes, people on the waiting list wouldn’t know they aren’t playing and have to wait for someone to drop out.

People without blogs

We were open to all last year, but one of the biggest disappointments people had was when they were given someone to write for who didn’t have a blog. They didn’t want to put in effort writing when that effort wasn’t going to make it to the internet.

This year we’ve made it mandatory for everyone to add a blog URL to their profile. Obviously, people can add URLs that aren’t their blog, but naming the field ‘blog’ will hopefully stop that happening.

If you don’t have a blog, but want to start one and join Blog Secret Santa, there are many many ways to do it. Your secret santa gift post could be your first post!

The giftless

Last year 5 people out of 50 were supposed to give gifts and didn’t. We knew some people wouldn’t end up giving, but had no idea what the number would look like. We had a worst case in our minds of 50%, so 5 wasn’t too bad. We were happy.

Max spent some time in the new year whipping up some posts about Blog Secret Santa to give to people that missed out. Everyone had a gift by the time we closed submissions at the end of January.

We don’t have a concrete solution for this year. Our idea at the moment is to let writers know when the person they wrote for didn’t give a gift. The writer will have the choice to give it to them anyway or to have it added to the group’s gift pile to be handed out to the giftless. I don’t think anyone who didn’t give gifts went on to publish their gift posts. So you may want to take that into consideration if you face yourself with that choice.

Unpublished gifts

The biggest problem last year was that people didn’t publish the gifts they were given. This really disappointed the gift givers, who all put time into their posts. They didn’t get the satisfaction of seeing their post on the 2013 blogroll, even though it didn’t credit them. Mainly these unpublished givers were left thinking “my content isn’t good enough for you?” and had their experiences ruined.

What we’re doing about it is to return unpublished posts back the giver at a certain cutoff point. That will probably be the end January. The writer can then publish it themselves and get featured on the group’s blogroll.

We’ve returned some unpublished posts to their writers. If your gift wasn’t published and you want it back then get in touch.

We’ll also make it easier to add the published URL to your gift so it can feature on the blogroll. This will make it easier, but I don’t think this was an issue that stopped gifts getting published.

Gifts after Christmas

A happier problem we solved last year was that someone people missed the deadline to submit their gifts. When gifts were handed out at Christmas, everyone who hadn’t submitted a gift was emailed to let them know someone had missed out on a gift because of them.

Most people then wrote posts and we had to add a way for them to submit their gifts late. This worked well and most people were happy. We’ll continue the same thing this year.

No way to communicate

True to Secret Santa tradition, matches were anonymous. There were times when people wanted to communicate with the people they were matched with. They may have wanted to find out more about the person they were writing for. Sometimes there were apologies for pulling out. Last year, these messages were ferried by Santa.

We also planning on adding anonymous communication between people and their giver and receiver. This will also be used to send messages to the group elf. The aim is to keep things anonymous and fun, as well as keeping things private like personal email addresses.

There will be a way to report abusive messages, because unfortunately combining the Internet and anonymity makes some people dicks.

How I migrated from Wordpress to Jekyll

Last weekend I migrated my personal blog from Wordpress to Jekyll. I tweeted as I went to keep some sort of record of what I'd done and the decisions I'd made. I also hoped that anyone else wanting to do the same thing would find it helpful.

It all started because GoDaddy reminded me that my hosting was about to expire. I'd been using Jekyll for the CS Workflow site and loved it.

That last part about hosting on Github isn't true. I hosted it on the CS Workflow server.

What is Jekyll and why use it?

Jekyll is a static site generator. A static site doesn't use any server side processing. Web browsers can easily handle static HTML, CSS, and Javascript. You've seen this in action if you have ever double-clicked a .html file on your desktop and had it opened in your browser.

Jekyll uses a template, processing rules, and content to generate a static site. Each page of the site has its .html file. The HTML file, along with the stylesheets, scripts, and images, can be uploaded to any web server. There are tons of ways to host static sites and almost all of them are free.

Wordpress, in comparison, uses PHP and MySQL to generate HTML each time a Wordpress page is viewed. The template is filled with content from the database, which is displayed by the browser. This only takes a few hundredths of a second.

Wordpress makes having a website really easy, especially is you use and don't worry about your own hosting. Almost everything can be managed through the web-based admin console. You can be completely removed from everything technical, like HTML markup and installing plugins. Wordpress and platforms like it have allowed millions of people with no web development skills to have their own websites. That's a great thing!

Why bother with Jekyll then? Jekyll is faster. The site will be faster to use. Getting a new site setup is faster. Oh, and it supports Markdown by default. I love faster and I love Markdown, but the main reason I love Jekyll is that it puts me in total control over my entire site. I have instant access to style, layout, and content in a single text editor. I'm using Atom for my text editor at the moment, which I completely recommend.

It's totally a preference thing and there is a skills barrier to Jekyll, so it's not for everyone.

Exporting from Wordpress

Let's get on with it. The migration starts with exporting my content from Wordpress. I'd seen in Jekyll's documentation that there is support for migrating. I started there, but the documentation wasn't very thorough and I imagined using their method would waste time.

Off to google to find a good guide. I didn't want to spend a lot of time or energy on this migration, so a good tutorial saves both. I recommend the how-to guide on This is what I followed. I'll assume your also using that as a reference and only chime in if I have something to add.

One of the first steps was to export comments to Disqus. I didn't have many comments, but I wanted to keep the few I had. I hadn't setup Disqus on a site before. It took than 3 minutes to complete the steps, going by the twitter timestamps.

Disqus had updated its export/import method and it was even easier that the way shown in the tutorial. Imports are queued and it took a few hours before mine were processed.

Jekyll's Wordpress exporter accessed the database remotely. The tutorial uses wordpress-to-jekyll-exporter, a Wordpress plugin. This plugin isn't searchable in the Wordpress plugin directory. I uploaded the plugin zip file to the plugin folder using FTP. Then I used the plugin installer in my Wordpress admin console to unzip, install, and activate the plugin.

The export was done with one click on the 'Export to Jekyll' link in the Wordpress console. This exported my posts and pages to Markdown. It also added any uploaded media to the export.

My only issue was that it used the .md Markdown extension instead of .markdown, which I prefer. I used the view/edit method in Filezilla and did a find and replace in the plugin file to change the .md to .markdown. I tried to use the plugin editor in the Wordpress console, but it went crazy when I tried to save the changes.

Setting up Jekyll

I didn't export my template. I decided to redesign instead. This is where I wasted the most time. I looked at theme sites for inspiration.

I can't remember what I searched for, but I found Poole, a Jekyll start kit built by Mark Otto of Bootstrap fame. Poole already looks pretty good, but has two themes. I used the Hyde theme, which I made a few changes to.

  • Made the post header an H1. Originally it was an H2 with the site title (on the left column) always an H1.
  • Changed the blog roll pagination directory from /page2/ to page/2/.
  • Removed the pages menu from the left column. I only had the home page, so this was unnecessary.
  • Removed the special font from the site title in the left and just went with the standard PT Sans.
  • Added an avatar image for myself.
  • Added social icons with links.
  • Changed the related posts header from H3 to H4.
  • Added a background cover image for the left column. I got the image from this awesome photo resource.
  • Increased the font size of the post headers.
  • Added a little clock icon next to the post dates.

I think that's it. All I needed to do was to copy and paste the export Markdown files into the _posts directory and run jekyll build.

I needed to host the site myself because there are a few restrictions to hosting on Github. The main one that stopped me going with that option is not being able to use plugins. I use two plugins. The first is to figure out how old my daughter is. This is displayed in my bio in the left column. Jekyll uses Liquid templates, but doesn't come with a timeago filter as standard. The second plugin is jekyll-assets, which compiles the different stylesheets into a single, minified, gzipped, and cache-busting css file. This makes loading for the first time even faster.

To start, I created a new Github repository called chadfield-blog. This gives me cloud-hosted source control using git. Github also makes deploying changes really easy. To get the site on to the server I sshed in and ran git clone from the directory I wanted to serve the site from. To get any future updates I run git pull.

By default Jekyll generates the site in the _site folder. For CS Workflow I'd set the build destination to a different directory which used its own git repository. This time I kept the source and generated site together.

The trade off of managing a single repository is that I'm deploying the source files to the web server and not just the static site. I point the web server to /chadfield-blog/_site instead of /chadfield-blog and have a few extra kilobytes on the server.

All I needed to do was add the site to the Nginx config, restart Nginx, and point the domain name at the server IP address.

server {
 listen 80;
 rewrite ^$request_uri? permanent;

server {
 listen 80;
 root /home/deployer/chadfield-blog/_site;
 index index.html;

Publishing workflow

Obviously, the steps to get new content published is different to Wordpress. I'll lay out the steps needs and what I've done to make it easier.

  1. Write a new post.
  2. Create a new Markdown file in the _posts folder.
  3. Add meta-data and content to the Markdown file.
  4. Run jekyll serve and test locally that everything is okay.
  5. Commit changes to git using git add -A.
  6. Push local git repository to Github using git push origin master.
  7. ssh into the server and run git pull in the site directory.
  8. Check on my site that the changes are okay.

I automate steps 5, 6, and 7 using a rakefile. I use CS Workflow to write, get reviews, and export meta-data to Markdown.

desc "Commit changes to website repo"
task :commit do
	puts "Committing..."
  exec "git add -A && git commit -m 'Site update' && git push origin master"

desc "Update code in production"
	task :update do
  puts "Updating production..."
  exec "ssh 'cd site-directory && git pull'"

To use that copy into rakefile.rb and change the ssh details and site directory. Then all I need to do is run rake commit and rake update.

Hopefully you found that helpful. There’s plenty of gaps, which is why I’ve called it titled it as how I migrated rather than a general how to. Really there’s not much to improve on the how to I referenced. Feel free to ask any questions or offer improvements I could make.

Birthing a Content Strategy

This post is part of a creative, generous effort in the content strategy community called Blog Secret Santa. Many thanks to Margot Bloomstein for the germ of the idea, and to Ben Chadfield for taking it to fruition, expanding it into a community of 50 content strategy bloggers. I am honored to have gotten Ben as my Blog Secret Santa outlet! – Currently anonymous guest blogger

I always say that launching a website is like having a baby: There’s an amazing amount of preparation needed in advance, but once it launches you have this BABY that requires attention, guidance, discipline, and affection. Every. Single. Day. Since Ben is a new parent, I wanted to tie the two together.

For the most part, the post-launch work of any digital property is executing the content strategy. Therefore, the upfront effort to create a sound, smart content strategy is key to ongoing – and ideally, increasing – success for the site.

In the name of taking a metaphor to its logical conclusion, here are the four stages of birthing a content strategy:

Phase 1. Conception

A content strategy usually starts with a problem (the most common one in my experience being “no one can find anything on our site”), a redesign, or a new microsite. It’s followed by the decision to undertake the content strategy and getting the right resources in place. Then, voila – you’re on your way! (You can use your imagination in translating these concepts to conceiving a baby.)

Phase 2. Gestation

Understanding the conditions: How do things work now (who is publishing content? who is reviewing it? what is causing the problems)? What is successful and where are improvements needed? After these are identified, they all need to be prioritized.

Formation: For a content strategy, this is the audit and the development of the editorial guidelines, voice and tone, lifecycle, and governance.

Refinement: To make sure the content strategy can actually survive, its elements need to be tested on real content and with real content authors.

Phase 3. Labor

Now it’s time to prepare for the content’s entry into the world. Where will the content guidelines be stored, and what’s the plan for ongoing communications, education, community, success stories, and reporting?

Phase 4. Delivery

In addition to the launch of the new digital product, everyone involved in creating, reviewing, and publishing the content needs to know what the strategy is and how it will work. (If only parenting came with a rule book too!) They need to be held accountable for their input, their effort, and the results.

Congratulations: You are now the parent of a bouncing new website, and a shiny content strategy. Get ready – it will be a bumpy ride with loss of sleep, stressful moments, and even a few failures. But there will also be brilliant successes, swells of love, and rewards of all sizes and types along the way. Once you see the first glimmer of recognition (the website equivalent of that first true smile), you’ll know your efforts have been worthwhile!

I’m not a content strategist

Over the last dozen or so years I’ve worked for quite a few companies and on an uncountable (because who can remember) number of digital projects. As you would hope, I did learn things.

The problem is that I don’t know what I am. My role in CS Workflow is Founder. That just means that I do everything needed to get my startup out of obscurity.

This post, and any subsequent posts that follow the same title pattern, are explorations to try to figure out what I am. I figure looking at what I’m not is a good way to cross things off the list.

I’m starting with content strategy and the ‘ist’ of that for two reasons.

The first is Blog Secret Santa (read about how that got started). Being involved with a bunch of real deal content strategists, with the possibility of anonymously sharing content with one of them, showed that I’m not in that club. That’s not because I’m not welcome, but because their CS cred is so strong.

The other reason to start with this specialty is that I’m always looking for content strategists to share the CS Workflow message with. This feels a bit awkward to say, but there are a lot of people who inflate their content strategy expertise. I didn’t want to be one of those people falsely claiming the latest trendy skill set. It’s unfair to the real experts.

I create content, but I’m not a content strategist. I have even created content strategies, but I’m still not a content strategist. A content strategist, at least in my view, has a specialist focus in content strategy, either creating, managing execution or furthering the field.

There isn’t a single definition of content strategy. If you want a good description then check out the often referenced The Discipline of Content Strategy by Kristina Halvorson.

I’m not comfortable claiming that specialty, because the most obvious attribute of the real deal content strategists is focus. It’s also obvious that this focus comes from passion for content strategy, and content in general. I share the passion, but not the focus.

At the moment, about 80% of my time is spent on the CS Workflow product. This is mainly development time, including gathering feedback and planning next steps. The remaining time I have is split between content and trying to get people to use the product.

Fortunately, I’m not in this alone. My lovely wife and partner, Vicky, is flying the content banner. Her background is in educational publishing. Her passion and focus is far more diverse than my own.


Through CS Workflow and working with Vicky, I might eventually become focused enough to call myself a content strategist. However, I can’t see our team dynamic changing, or a reduction in development work. With Vicky able to spend more and more time on content (did I mention we have a six-month-old daughter) my focus is likely to only shift more to the product.

Keep an eye out for the CS Workflow blog. The content we’ll produce aims to educate people about content strategy, particularly the workflow and governance component.

Why I love giving feedback

I suck at following my own advice. CS Workflow’s website is pretty bad, we’re not active on social media and the amount of content we’re producing is only slightly more than none (there’s good stuff in the pipeline).

I seem to forget the basics when working on my own projects. For an example on top of the one’s already given, I forgot to add authorisation to Blog Secret Santa to stop people being able to edit each other’s account details. I fixed that a couple of hours after it went live, but still.

The point of this post wasn’t self deprecation, it was to remind myself of how much I get from giving other people feedback. I generally give feedback with the selfless intention of making the world better. I love startups, internet technologies and content, so don’t need any excuse to delve into those areas. From self deprecation to humble bragging…

I love giving feedback because it shames me into following my own advice. “I can’t say that if I’m not doing it,” I think to myself. Giving feedback is a mirror to my own efforts.

Beyond self reflection is simple exercise. Flexing the thinking muscle sharpens the saw and give me new perspectives and inspiration

Beyond all self improvement is making and building friendships. Friends in need of feedback are friends indeed. Friends are great and the win-win of helping them with feedback is the winningest of the win-wins.

I’m rewriting CS Workflow’s website content because of giving feedback to on someone else’s website. This will lead to a redesign. Of course, the content updates are based on feedback selflessly shared by others. Thanks David Siddall and Max Johns.