The Study

THOUGHTS on her WORK and PROCESS

Website Hindsight

It’s high time I wrote a rundown on the arduous process of putting this website together. Perhaps someone will find it useful – if not, hopefully at least amusing.

Without further ado I present:

How to make a website if you are not really a website person (but can write code)

or

Why Delia Is Not A Web Developer

Step 1: Probably choose a CMS

I mean, unless you want to write the content directly into the html forever. Maybe you are that person, who am I to judge? But I am not that person, because I, dear reader, am lazy.

I knew I wanted to have a blog, and a few custom pages that I could add content for (like the Games Room – I wanted to be able to add new items with a fixed format to the portfolio with a minimum of fuss). I had heard good things about WordPress. I knew it was user-friendly, I was familiar with the interface, and I knew there was scope to tweak the code per theme to a certain extent. I thought to myself, ‘this will be handy, I can get a better handle on HTML, CSS and PHP while I work’. (Hah!)

Now, WordPress is a great tool for people with no interest in programming. There is a lot of free stuff you can add with minimum fuss! Loads of free themes that don’t require any coding at all! But I have enough coding nouse that I probably could just as easily dived right into a more complex and flexible CMS.

Reader, if you are me in this situation, I have a nugget of advice for you:

Don’t Use WordPress
Don’t Use WordPress
~ Don’t Use WordPress ~

The eagle-eyed amongst you will have noticed that this site is indeed built in WordPress. I was too far down the rabbit hole when I realised my mistake. WordPress seems to be hobbled mostly by its own purported user-friendliness. Narrow (and occasionally rather dated) assumptions in the core code combined with a mostly uncurated mass of free plugins creates occasional hair-tearing inflexibility and over-simplification in what is otherwise an infuriatingly complex system.

There are a lot of things that could just be a check box in the interface but have never been integrated, despite myriad threads in the support forums asking “how do I do [thing]?”. You also will spend a lot of time asking ‘why doesn’t it just do [thing]?’ and either cutting custom code for [thing], or throwing your hands in the air and finding a plugin that doesn’t exactly do [thing], but is close enough. The joys of open source!

Step 2: Dick around for a while until you realise you have literally no idea what you are doing

Start with a child theme of a layout you like the look of. Rapidly discard it because it is full of voodoo CSS magic (negative margins. just. ???). Look for a basic boilerplate instead – I eventually found the _s theme, because I like a) starting from a comparatively blank slate, and apparently b) re-inventing the wheel. Spend a week poking things. Tentatively put together some test pages. Admire your website. Maybe Times on a white background is appropriately ‘retro’ now and you can just publish it? Are you supposed to be editing index.php, home.php or front-page.php? How do you put a menu in the sidebar? Who knows, it is a mystery.

Step 3: RTFM

Find the documentation for your chosen CMS and read it. Google shit until something clicks. In my case this translated to: stare in bewilderment at pages and pages of WordPress documentation until you finally give up and just start reading the source code because at least that way you can work out what it does.

WordPress has something called a ‘codex’, which is not to be confused with the WordPress code reference, despite frequently including code examples. The codex is not, in point of fact, a codex, no matter how one stretches the meaning of the word. It is a wiki; just call it a wiki, you pretentious fuckers. Jesus.

Did you know WordPress has a function called maybe_unserialize() ? Listen, I just feel like if that is a function you think you need, maybe your system has bigger problems than the serialisation state of that piece of data.

Step 4: Maybe having a design would help?

You think to yourself that every web designer you’ve ever worked with mostly made nice things in Photoshop, at least before they got handed to developers for evisceration and general mangling (er, the designs, that is, not the designers). So at this stage I went back to the literal drawing board and spent some time poking away at a layout, armed with Adobe Colour, my Bamboo tablet, and mediocre design skills. I knew I wanted the site to echo the layout and style of Renaissance-era printed material, and accordingly spent more time than necessary looking at pretty things on my bookshelf and BibliOddysey.

Once you’ve got an idea of layout, hazard a wild guess as to the appropriate screen size to design for. This will quickly go out the window once you start viewing it on different devices so it doesn’t really matter, you can probably pick a number at random? Don’t design explicitly for smaller screens or different aspect ratios, just assure yourself that you’ll be able to work out that whole responsive thing as you go. Everything will probably be fine.

Step 5: YOU NEED A LOGO

Spend several days drawing dumb shit in Photoshop because you feel like you need some sort of icon in the top left corner. That’s a thing, right? Painstakingly clean it up so that you can use Live Trace in Illustrator to make a vector version. Spend way too long painstakingly cleaning up the live traced version, and assure yourself that it was still faster than drawing it with the pen tool.

Waste a day looking at pretty Renaissance architectural drawings and motifs. Draw an arch. Excellent. What a good arch you have drawn. Export your icon to .png and realise it is going to be minuscule on the site. NEVER MIND you can always put it on business cards later.

Step 6: Create your custom content templates and agonise endlessly over them

Stare at PHP scripts. Stare at Chrome Developer Tools and Firebug. Did you know that if you have a syntax error in your PHP and you forget to put WordPress in debug mode, it fails to render entirely? I did not find the debug setting until a day or so before I was finished. It’s in wp-config.php, which is obvious in hindsight. Move divs around until you work out which ones are which. Decide that you want the sidebar function to be called in the header file. Use grep and sed to comment out the footer completely. What could possibly go wrong?

Real talk: This is where most of the work and most of the frustration happened. I happen to be a person who is especially fixated on ‘neat’ solutions to a problem – solutions done with a minimum of code and effort, that satisfy some inner aesthetic demon. WordPress happens to be a neat person’s nightmare in many ways.

I have three main areas in the site apart from the front page. Two of these are intended to show bog-standard blog posts, and The Games Room is a page of custom post types. What I wanted seemed simple – on each page a title, a subtitle, and then a pre-defined number of the appropriate posts listed.

At first I tried to do this using pages, with the subtitle in the page content, and custom query loops to get the appropriate posts, but it ultimately felt like a clumsy solution, and one that required far too much bespoke code. Besides which, I couldn’t get the permalinks to work without risking errors – I had a page with the slug games-room, but I also wanted my custom post permalinks to be /games-room/post-name. Protip: WordPress breaks horribly if you try to force it to share permalink slugs across different types of posts/pages in ways it doesn’t expect.

What I eventually struck on was using WordPress’ built-in capacity for categories and category pages to my advantage. The Study, The Salle and The Games Room are nothing more than post categories. Categories have a title and a description, which handily took care of the ‘title and subtitle editable in CMS’ issue. WordPress allows you to define custom php files for categories, which gave me my custom thumbnail layout for the games room.

Combining this with a plugin to remove the extraneous word ‘category’ from the urls gave me my nice, neat permalinks: root/room-name/post-name. A satisfactory solution, and one that uses only the main WordPress loop on the page for each post type, which gives me more flexibility for future changes and additions (infinite scrolling, for example, won’t work with custom secondary queries).

Other plugins I used included: the Metabox plugin, which allowed me to specify a bunch of custom fields like year, studio, site link etc for my Games Room posts; a plugin for category sticky posts, which lets me keep the ‘welcome’ post at the top of the Salle. There were also a couple for messing around with the database which I used sparingly (that is to say, activated, used once, and then deactivated).

Treat plugins cautiously. They are the most likely points of a) failure in the code, and b) entry for attackers.

Step 7: Style that motherfucker

Wail. Gnash teeth. Read StackOverflow until your eyes bleed. Wonder why it WON’T DO THE THING. Explain in great detail to your partner what is wrong with the CSS box model. NEGATIVE MARGINS. Why is it so hard to make something just fill the remaining space? negative marginssss. Decide it looks ok Chrome, Safari and Firefox. Internet Explorer can fuck right off. Realise it looks terrible on mobiles. Realise that there is a better than 50% chance most people will look at it some kind of mobile device, especially if you link from Twitter. Disappear into the woods to be a hermit for your remaining days.

Step 7: OH SHIT VERSION CONTROL

Throw it into git (or your preferred source control) at the last minute. I followed, approximately, this guide, although I didn’t version the database because bugger that for a game of soldiers.

Step 8: GO LIVE ALREADY because if you don’t do it now you will nitpick it endlessly forever

It might explode a bit. I had to do a find-and-replace on my database file to change out utf8mb4 encoding for plain old utf8, because my Dreamhost server is running rather an older version of MySQL than my MAMP install. (I suspect this will continue to bite me in the arse in future).

I had some errors due to the WordPress-generated .htaccess files behaving differently on localhost than on the server. The trick to this generally seemed to be to flush the rewrite rules, which is the WordPress equivalent of turning all your links off then on again. It is supposedly done by simply visiting the Settings > Permalinks page in the WordPress dashboard, but older documentation suggests you have to select a different permalink structure, save, and then reset it to the one you want.

Step 9: Fix the mobile version

Stare, befuddled, at your site on an Android Nexus 7, wondering why there is a such a giant margin above the site header. (The culprit: default browser margins, which caused most of my styling problems). Rage against the very small machine. Juggle magic number pixel breakpoints until it looks acceptable on all of the devices you can find in the house. Call it good enough.

Step 10: Share your newly-minted website!

Some friends will like the link on Facebook. Your mum will send you an email telling you how marvellous it looks. Success!

‘A Planet Wakes’ Post-Mortem, Part 1: Dispatches from a Remote Jam

It’s been a few months now since the release of A Planet Wakes as part of the month-long (well, month-and-a-bit-long) Antholojam, and it seems as good a time as any to do a post-mortem of the jam process. This will be the first of (likely) three articles elucidating what I think were the more interesting parts of the process. This first is a list of Lessons I Have Learned – a set of guidelines, if you will, for remote game jamming with small teams.

A Planet Wakes was developed with three other people, and the project was co-ordinated entirely over Skype and Slack, including one rather memorable conversation wherein the majority of my end was carried out from somewhere beneath the English Channel on a Eurostar train. Some of these lessons we got right the first time, without any apparent effort; others were learned the hard way. The question of which lessons are which is left as an exercise for the reader.

LESSON 1: ALL WE NEED TO DO IS MAKE SURE WE KEEP TALKING

The first suggestion is also the biggest caveat. None, and I mean none, of the following will help in the slightest if you don’t use your words and stay in constant communication.

You need to know that everyone is committed from the word go. Get everyone in a skype call as close to day zero as possible. If a team member can’t find and commit to a time, how are they going to find time for the project? The immediate follow up to this is: regular check-in times. Chances are you’ll all be working on different things at different times, so a regular meeting is a must. How regular that is will depend on the jam length – we found weekly audio/video Skype meetings worked for a month-long jam.

If someone goes dark for a period of time (again, how long is project-dependent), give them one direct contact in whatever medium is most likely to elicit a response. If said response is non-existent, extremely delayed, or otherwise worries you, remember that in drastic times this option is always open to you: MAYBE DROP THEM LIKE A HOT POTATO AND FIND A REPLACEMENT. (Be aware this is SUPER context-dependent. You know your team, work with them). In, you know, a nice way. Be clear, but don’t be a jerk about it. Most people are super well-meaning but if they are Not Actually Doing The Thing then it may not be working out (for caveats, see Lesson 5).

LESSON 2: THE MORE YOU KNOW

If you’ve never worked together before, get EVERYONE to articulate, clearly and in detail, what they expect their role to be. So not “game design” but “I can do level design and scriptwriting. I like to use google docs but I don’t have much experience creating and modifying objects in the engine. I can do the boring work to copy paste my numbers but I’ll need programmer support to make objects that are easy for me to edit and tell me where they are”.

Poke holes in your team. Find out whether there are any specific skillsets missing. Make sure everyone knows who to go to if they are blocked by someone else’s work. If you have multi-taskers (and in a small team chances are you probably do) work out what is and isn’t a feasible amount of work for one person to do. Some people (by which I mean ‘me’) will enthusiastically want to contribute to EVERYTHING that falls within their skillsets. Invariably, they won’t have enough time or brain-space in the end, so reel them in early if you can.

LESSON 3: SOME HAVE GREATNESS THRUST UPON THEM

Someone has to be the official bossy boots/meeting chair. You’ll usually find that at least one team member does this naturally. When you find out who that is, nominate them into the role. If it’s official, it’s easier for everyone and decisions will get made. It’s nice to want to be egalitarian about everything but at the end of the day someone has to say ‘ok, this is what we’re doing’. This doesn’t mean you have to give up any kind of democratic approach, but it’s incredibly useful to have someone who you all agree has the power to squash circular arguments or pointless tangents.

LESSON 4: FLOAT LIKE A BUTTERFLY, STING LIKE A BEE.

For a short project with no distinct ‘design phase’ you need to be agile, but for the love of all that is holy don’t ‘use’ agile. Go read the agile manifesto. Now read it again. Get it? (Got it.) Good. Particularly for programmers it can be tempting to try to do things the way you are used to doing them at work, but unless you work somewhere tiny, those processes are probably too detailed. Forget SCRUM, because you can’t do daily standups with a remote team, especially if some of you have day-jobs or are in different timezones. If you are a lover of methodologies and like to play “pin the tail on the buzzword”, go with Kanban.

Throw away as much process as possible. Keep core things – an online space to chat in (slack is great. slack is my favourite. I loooove slack), version control (we used github but I SUPPOSE it’s possible you might want to use something not made by/for lizard people*), maybe a task board (hello trello), but remember that the core of agile is people over processes. Don’t waste valuable jam time trying to find the best processes – process will develop organically from your team dynamic.

LESSON 5: DAMMIT, BABIES, YOU’VE GOT TO BE KIND.

By definition, jams are heavily constrained project spaces, and unresolved conflicts rapidly become ticking time-bombs. You’re all in it together and you need to take care of each other, because that’s how you’re going to get the best results. Give team members the benefit of the doubt. If something is coming through badly in text, try to make a time to talk with audio. If you blow a gasket or screw up some work, apologise, clear the air, and keep moving.

Be sensitive to mental health (your own and other peoples’) as the high pressure moments of a jam can be difficult to navigate. Don’t be afraid to say if something’s giving you trouble – whether you want to go into any detail is up to you, and will depend hugely on how well you know your team members.

So this advice is a little at odds with the earlier suggestion of dropping non-contributors. Sometimes people will go dark for mental health reasons that they cannot control. In these cases, talk to the person if you can, listen to them, and look for a solution. Maybe you can cut part of their workload; maybe you can help them break down their tasks; maybe you can credit them for what they’ve done so far and ask them to handover to someone else. You may still have to ask them to step back. If things are bad, you can be a better friend to them if you’re not trying to be a team member as well.

LESSON 6: BE PREPARED

That’s ‘be prepared’ in the Scar-in-Lion-King kind of way, not the cheerful boy scout kind of way. Expect things to go horribly, surprisingly wrong. Expect other things to be unexpectedly brilliant. Make contingencies. Make contingencies for your contingencies. Every time you add something, THINK AHEAD to what it might affect down the line (oh hi, sprite system). Kill your darlings. Iterate like crazy. Let things get cut if you’re running out of time/headspace/reasonable amounts of sleep. You might have to cut things that are awesome! Or things you spent a whole week on (OH HI, SPRITE SYSTEM)! This is ok. It’s part of the jam process. Let it go. (This is the Disney song reference paragraph, apparently.)

OKAY BYE

At this point, that’s pretty much all I’ve got. Maybe this is stuff that is obvious to other people, who knows! I know a lot of it has been said before, but I also think bears repeating. Some of the pitfalls we were aware of beforehand and we STILL didn’t manage to catch ourselves before we got eaten by alligators. Don’t get eaten by alligators when you are game jamming, ok?

*full disclosure: I love git. I am almost certainly a lizard person.