Relicnews Redesign

We’ve just launched a major redesign of Relicnews, the original and best source for Relic-related news. I’ve added a portfolio entry on the design, but I have a lot more to say about it that either wouldn’t have been appropriate for a portfolio entry, or would have made it far too long. The development cycle was the longest and most problem-stricken I’ve ever had, and although it’s worked out fairly well in the end, let this be a lesson in how not to do a web design project.

Before I kick off, let me just say that the RN staff are some of the nicest people I know, and they’ve all worked incredibly hard to get the new site to the point it’s at now. The problems we had were down to management failures, external difficulties, and simple confusion, and if they reflect badly on any one person, it’s me. I hope for two things: that people like the new site, and that the lessons I learned on this project help me in the future. I’m fairly sure they will, if only because they were so painful.

The story so far

This project started so long ago that I don’t even remember when I was first approached about it. It was back in the autumn sometime; we were sitting on IRC one day and Pike said something along the lines of “Hmm, we should have a new RN design. Fishy, do you want to do it?” Like an idiot, I said yes.

At this point I should probably mention that when I first got into web design, I gave a certain amount of thought to creating a gaming portal / fansite, not so much because I thought anyone would ever let me do one, but because I thought that most of them were so horrible. The fact is, though, that designing a website isn’t as easy as it looks. I can see why so many of them end up looking the same as one another; there are a common set of design challenges, and when you have to take into account all the information you have to display, as well as having to fit in huge advertising banners, it’s not really surprising that designers are so ground down by the process that they give up on inspiration and simply go for something generic.

The first thing I did was some rough sketches; I don’t have the originals anymore, but you can get an idea of what they were like by having a look at my portfolio redesign post. After some initial messing around with an insipid blue and grey colour scheme (fortunately vetoed by people who were obviously thinking more clearly than I was), I settled on the red you can see now. This colour defined the new site so much that we took to calling it ‘Red’.¹ Unsurprisingly, given the large numbers of images used in the layout (quite a contrast to some of my work) it was first designed in Photoshop, and then sliced² by hand. The final design (that we’ve just launched) is not a million miles away from the XHTML/CSS template I created at this point. When that was finished, with some Lipsum filler text, I felt quite buoyant about the project: the design phase seemed finished, and everyone liked the results.

It wasn’t to last; in fact, it wasn’t long before we hit the first major difficulties the project suffered. I would say that in retrospect this was where it all started to go wrong, but that would be an injustice to my instincts, which at that point were screaming at me that this was all really a bad idea. Unfortunately for me, I didn’t follow their advice. That said, I’m not sure where the project would have gone if we hadn’t taken this particular fork; my own level of knowledge of the software involved wasn’t sufficient, at that point, to drive our direction. I’ll touch on what I learned from that later.

In any case, the decision was to use the e107 content-management system. We did this because one of our staff was familiar with it, having employed it on several of their sites, and because Textpattern (which I had a little experience with) didn’t have proper static page management out of the box. It was capable both of the news functions and the static page functions that we needed, and was supposedly easily customised to individual needs. I say supposedly because in actual fact, their template design system was horrendous.

The amount of superfluous markup it vomited into my design was, frankly, shocking; clearly the programmers had no idea what constituted “best practice” or even that standards existed at all. I had this problem with Textpattern too, albeit to a much more limited extent (the comments code stuck in loads of markup I didn’t want, leading to me having to re-write not only the templates but the comments backend). Why developers create content-management systems that impose markup (and worse, presentation) on the designer is beyond me. Regardless, developing for e107 was a painful process I have no wish to repeat. We got some way through it, and essentially gave up. It might well be a powerful system for managing a large site with diverse content to save and present, but it wasn’t suited to our needs. I suspect that these pre-packaged content-management systems like e107 or PHP-Nuke are basically aimed at those with no interest in or ability to design their sites, but want all the functionality these systems provide. As someone who basically makes bespoke, hand-coded sites with care and attention to detail, that mindset is just anathema to me.

So what did we do? We switched to another system, of course—Movable Type. This was more to my liking: I’d used it (with a little help from a friend and some-time rival) on the Homeworld Community website, and the fairly simple interface and template tags made it relatively easy to use, provided one has a friendly server admin to do all the Perl stuff. I think the site lasted a couple of weeks.

This time it wasn’t technology that did us in, but people—specifically Marv, our server admin. Without so much as a by-your-leave he switched off Perl, meaning that while the site was still there (Movable Type generates static pages, which have to be ‘rebuilt’ whenever a change is made), the backend was dead. With the amount of time I’d put into the site at that point, including a major re-vamp that tightened up the design and added a lot of nice detailing (the list bullets were added at this point, and the sidebar on the right-hand side made into an actual third column rather than just a box for an advert and recent news), having it all go down the drain was more than I was prepared to deal with. I quit the project, swearing I’d not do a stroke more work until we had moved away from our server hosts. Thus ‘Red’ entered a hiatus.

Resurrection

The next phase started innocuously; I didn’t think much of it at the time. We were trying desperately to find some alternative hosting; the forums were up and down like a yo-yo, and even removing things like the search feature wasn’t helping. Still, when Delphy offered to host us—he was already running a large vBulletin forum—I was less than enthusiastic. This was probably because I wanted the stability our hosting on Telefragged had brought, at least until recently. A big site that could support us was what we were looking for.

As the weeks wore on and we hadn’t found anything, we started talking to Delphy more seriously about the offer, making sure that he could provide sufficient server power and reliability. Given the stats on the forum he was running, it seemed as though (with an additional server) we’d found our solution. Slowly, we began to prepare for the move, backing up databases and files from the Telefragged servers onto Delphy’s system.

By this point, I’d started porting the second version of Red into our third CMS: WordPress. Since I knew WP from working on this site, the development went much more smoothly, and we had the basic install up and running within a short space of time. It wasn’t ready when we launched, but it was functional.

Once we’d moved house, including getting the forums up and running, as well as the old site and our new WordPress install, certain parties got ambitious, and decided that we needed to import all our old content. Fortunately, Delphy is a very talented coder and it didn’t take long before he’d written an import script to convert the news archives from the old RN into the new Wordpress format. Unfortunately, those posts were wracked with horrible old tag soup markup. We fixed this for the articles—interviews, features and so on—but there were just too many news posts. So we left them. They’re readable, mostly.

I changed a number of things before we launched, including tweaking the left navigation column. Originally, the section titles were just that: titles. Only the text links went anywhere. People found this confusing, and I saw the merits of having an introduction page for each game, so I changed the game titles to links and got some minions to write and steal introductions.

What took the longest was the content massaging. By this, I mean stripping out all the old, horrible code and replacing it with shiny, valid (mostly) XHTML. This took a long time, and involved hours and hours of search-and-replace. Moe should get a medal for all the work he did on this. We also had to change all the images used in articles, cropping them so they were the right size for the two content columns. This sort of stuff—tweaking, polishing, getting the content ready—was what consumed most of our time between switching servers and launching.

In the end, however, it was ready, and I told Delphy to throw the switch. The last thing I did before we went live was write up a little introductory post. It was slightly strange to finally launch; by that point, I’d been working on it so long, I’d got used to it being a kind of omnipresent force, constantly hovering at the back of my mind, a niggling pain that wouldn’t go away. Not to worry, though—I’m sure I’ll find something equally as time-consuming to replace it with.

In retrospect

The list of things that went well is, unfortunately, a comparatively short one. I’m quite pleased with the way the typography worked out: the Microgramma of the title has echoes of Homeworld, while the Trade Gothic of the navigation buttons give it a stark, futurist look. The clean lines and muted greys provide what I think is a nice juxtaposition with the heavy textures of the header, while small bevels and gradients give it some tactility.

The list of the things that didn’t go so well is partly recounted above, but I’d like to touch on a few design decisions that, perhaps, I’d have done differently were I starting the project from scratch (and knowing, of course, what I know now). One thing that does concern me is the site’s width; it’s over 900 pixels wide, and being a fixed-width site will require horizontal scrolling from anyone running their screen on 800×600 or lower. The number of people of whom this is true lessens year on year, and our target audience is even less likely to fall into this category than the average web user, but nonetheless it’s still a worry. At this resolution users will be forced to maximise their browser windows if they’re running 1024×768, and it’ll still take up two-thirds of the screen on a 1280×1024 display. The site was created with a particular set of advert sizes in mind; I didn’t want the content to be dominated by those adverts, so I spaced it out a bit. I’m not entirely happy with it at this size, but unfortunately those constraints are still in place and I don’t see them changing any time soon. The effort to remake it as a narrower (or even worse, liquid or elastic) design would be more than I’m prepared to put in at that point, given the blood, sweat and tears it’s taken to be launched at all.

One other thing is the colour scheme; the grey on grey is fine as far as readability is concerned (although I may look into some contrast tweaks), but it’s a pain for links and headers. The dark grey background basically kills any colours other than grey and white, which is why they’re the tones used for (respectively) body text and links/headers. Part of the problem is that there is an idea out there of what a gaming website should look like, and it can be hard to resist. Were I doing it again I might, effectively, opt for something more lightweight (Eric has done some good work in this line).

Lessons learned

Amongst the painful lessons from this project are the following. Firstly, figure out right at the beginning what the hierarchy is: who’s in charge of what, how much autonomy you have, what you’re expected to do (and just as importantly, what you’re not expected to do, although in my experience this tends to be a very short list indeed). In the absence of solid leadership, and assuming that you want to go forward with the project, take charge. Say to those nominally leading the site that you’re doing the new design, that either it will be done your way or they can find someone else to do it, and that if they want it to ever see the light of day they have to jump when you say so.

This isn’t just empty leadership rhetoric: if a project is to come to fruition, and be a coherent and well-made product, then direction is needed. Sometimes, you have to provide this yourself, but you have to be honest both with yourself and those you’re working with just where that direction is coming from. It’s no use slogging your guts out on making hard decisions alone if you’re then just going to ask if it’s ok. Either work in a truly cooperative fashion and make those decisions together, or tell those you’re working with that your word is the law. Discussion can be a great way to bring out important considerations and find solutions to problems, but in the end choices have to be made. When no one’s sure who’s in charge, choices end up being made almost at random. This is not a good thing to have happen to your project.

Something else I’ve discovered ties in with my point about leadership quite handily. It’s this: tell people to do something in an authoritative manner, and guess what? Quite often, they actually do it! This has been a revelation for me, as I’m not used to either telling people what to do or having them listen. Actually, this whole “working as part of a team” thing is new to me too. When I first started out as a web designer, I had to learn the nuances of a new type of relationship, the designer-client relationship. Now I find myself learning to be part of a team (it’s something I’ve had some prior experience with, but not in the particularly active way one has to engage with others when working on a project like this).

The last piece of advice I’ll leave you with is this: don’t try to learn the ins and outs of a new piece of software or programming language on the job if you can possibly avoid it. I experienced this not once, but twice, firstly when trying to write that thrice-damned e107 template, and secondly when porting the design to Movable Type and figuring out the templating system. I breathed a sigh of relief when the server move went through and I changed it all over to WordPress, a system I’d just spent several weeks getting intimately familiar with. I’ve now resolved to learn new techniques and test them out on personal projects like this site, before I ever apply them to commercial work (not that ‘Red’ was commercial, but it was at least as much work as one).

I think this has to be the most ludicrously long post I’ve ever written here; a testament to the monumental amount of work and frustration that went into the new Relicnews. Finishing it at last, and venting here, will hopefully create some space in my head for all the other things I should be worrying about: the websites I should be making, the essays I should be writing, the exams I should be revising for. But for now, I think, I’m just going to have a beer and bask in the warmth of a job reasonably well-done, horrendously late, and doubtless to be publicly reviled. Cheers!