These two sites went live at the beginning of September, and while I’m still ironing out bugs, the public side of the sites is worth mentioning here.

Both of these sites are built in RedDot CMS (actually, it’s OpenText CMS now, but we still call it RedDot).  From January to, well, now, the majority of my job has been converting the old static site to RedDot.  I can’t say that this process has been an easy one.  I was responsible for the creation and implementation of the bulk of the pages and this required me to learn a completely new system that was coded in Germany.  I experienced European coding a few years ago after IQ outsourced a project to Poland.  Most of the syntax of languages is written in English (with the random Hebrew PHP error message), but that doesn’t mean that people who speak Polish or German are going to code in English.  What might seem like a perfectly logical variable name in Polish probably isn’t going to make nearly as much sense when it’s been run through Babelfish.  Likewise, Germans don’t have the same knack for writing concise English description as a native English speaker does.  The major impediment to learning RedDot was figuring out what exactly all the constructs inside it actually did, because the names given to a majority of them didn’t seem to accurately describe them.

The other major hurdle was that the team that manages the RedDot server is a school-wide resource, and a number of other departments were designing and launching sites in RedDot, often without the benefit of a developer.  This meant that the RedDot team was not only trying to build and launch a number of other sites, they were tackling my near-incessant questions, and dealing with an upgrade that resulted in a lot of things breaking.  On top of that, they were outsourcing major issues to one of the few RedDot vendors, a company of 15 people located somewhere near Vancouver.

So, here are the run-downs for both sites.  A quick note concerning the publishing:  Our RedDot setup has two publication packages: Staging and Production.  Additionally, we have three servers: Development, Staging and Production.  As these terms relate, it’s a bit confusing.  Ideally, RedDot Staging publishes to the Development server, and RedDot Production publishes to the Staging server.  The reason for that is that the Staging server pushes everything to the Production server once every 15 minutes.  We don’t have direct access to the Production server.

Giving to Wharton

This site actually went smoothly from start to (almost) finish.  The site itself was populated with content and, for all intents and purposes, ready to launch by the end of May.   As the project neared go-live, a number of the stakeholders came forward with content changes and section revamps.  All of these were handled fairly smoothly, and the only hang-up came right before go-live when we realized that the Staging publication package and the Production publication package were not mirroring each other.  The interim solution has been to publish both packages to the Development server, make necessary changes, and push them to the Staging server manually.

Wharton Alumni

This part of the project was a bear.  From the very beginning, the installation was fraught with problems that we kept attempting to address.  It seemed at every point that once one was fixed, two more would crop up.  Finally, nearing the go-live point, we decided to scrap the entire thing and re-create it.  This turned out to be a very effective tactic.  Scrapping 8 months of development wasn’t an easy argument to win, but the result was a completed site in just over two weeks.  The 8 months of combating bugs gave me a lot of good insight into RedDot’s inner workings, so once I had a bug-free environment, construction of the site went very smoothly.  The same publishing problem from the Giving site showed up, however, and at the moment, we’re still publishing manually.

All in all, it’s been a long, strange trip, but the reception has been amazing.  The new site is worlds better than the previous one, and it’s given the staff at External Affairs a much easier way to update their changing information than they had before.

I was hoping to post a lot more go lives here, but I’ve changed jobs to a position at UPenn’s Wharton School of Business External Affairs, and I’m working mainly on internal projects.

However, I’ve just completed a website for my Friendly Local Gaming Store, Alternate Universes.

Alternate Universes had an existing website, but it was built using static HTML that wasn’t very easy to update. The new site uses WordPress as a CMS, offering much greater ease of updating, as well as being able to update multiple pages using a single post. This allows for various pages to keep important content without the need to move content to those pages or clutter up the homepage for weeks or months.

Individual sub-pages are coded to include their related categories, allowing for general information for that page and a listing of pertinent posts.

The old site had an outdated calendar system, so I integrated Google Calendars using the wpng-calendar plugin for the site’s sidebar, as well as a static instance of the full calendar. This allows for much easier management and import of calendar data.

I converted the old phpBB3 forum to myBB, which was a bit more difficult than anticipated, even with a conversion app. The app didn’t accurately convert the forum settings, which necessitated a lot of snooping around in the database to get everything matched up. Once I found the broken relationships, though, it went rather quickly. There were also a few glitches with forum caches and settings files needing to be rebuilt, but all-in-all, the structure converted quite nicely. The new system will very aggressively tackle the issues they’d been having with Russian spambots filling their forum with Viagra ads and the like.

And finally, I get to take credit for the design. I don’t tackle design very often, because this is about the best I’m capable of.