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.

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.

So, how do we tackle this without all of that pesky JavaScript which is likely to break on any given browser (I’m glaring at you, IE6. And IE7. And IE8. And Firefox. And particularly Safari.) More to the point, how do we do this in a way that’s not just images and can actually be picked up by search engines? We say Screw the JavaScript! (I say that a lot.) The W3C has given us all the tools we need with HTML and CSS! We just need to find new and interesting ways to abuse them.

The root of the issue here is that we have an image that we want to change when we mouse over it, AND we want text to show up for spiders. The Spider isn’t going to understand nav_contact.gif as well as it will understand Contact Doylestown Web Design, so we need to scrap the image tag altogether. We also need to put that text in there and not have it display. These two things are not quite intuitive, but hey, we’re left brain geniuses, are we not?

So, here’s our HTML construct:

  <div id="navigation">
   <ul>
    <li id="nav_01"><a href="/item_1.htm" title="Top Item 1">Top Item 1</a></li>
    <li id="nav_02"><a href="/item_2.htm" title="Top Item 2">Top Item 2</a></li>
    <li id="nav_03"><a href="/item_3.htm" title="Top Item 3">Top Item 3</a></li>
    <li id="nav_04"><a href="/item_4.htm" title="Top Item 4">Top Item 4</a></li>
    <li id="nav_05"><a href="/item_5.htm" title="Top Item 5">Top Item 5</a></li>
   </ul>
  </div>

What we have here is a container <div>, an unordered list, and list tags with links inside. Now, that’s not going to look very good if we leave it like that, so off to the CSS we go.

First, we need to set the stage with the width, height, and background:

#navigation {
	width:740px;
	height:30px;
	background:url(/images/navigation.jpg) top left no-repeat;
}

For that background image, you want to have your entire navigation as it looks normally. No need to cut up individual images for your default state!

Next, we need to whip that list into shape:

#navigation ul {
	width:740px;
	height:30px;
	margin:0px;
	padding:0px;
	list-style:none;
}

We make sure that the <ul> tag is the same exact dimensions as our containing div, and then strip all the margins, padding, and bullets from it. Viola, no more list! Just a happy semantic construct.

Now, we need to trim the <li> tags:

#navigation ul li {
	height:30px;
	margin:0px;
	padding:0px;
	list-style:none;
	float:left;
	display:block;
}

Define the height (because this is horizontal, and they’ll all be the same, right?), strip the margins, padding and bullets again, and finally, make it sit horizontally instead of vertically like it wants to. That’s what the float:left and display:block achieve.

Moving right along! We need to get that pesky text out of there, don’t we?

#navigation ul li a {
	text-indent:-9009px;
	display:block;
	height:30px;
}

So, we take it and shoot it 9009 pixels to the left. Unless someone’s on a 10,280 x 7,680 screen, that’s text is not showing up. But they’ll have other problems, too. Anyway, an important thing to note is that you cannot use <br /> tags inside those links or everything after it will still show up. text-indent only affects the first line.

Now, we are almost done. We just need to tackle the individual cells (hence the unique IDs on the <li> tags). Every <li> tag is going to have two lines in the CSS: one for the tag, and one for the link inside it.

#nav_01 {
	width:148px;
}
#nav_01 a:hover {
	width:148px;
	background:url(/images/nav_01.jpg) no-repeat 0px 0px;
}

In the first line, we declare the width of the <li> tag. We’ve already defined the heights before. This ensures that we’re filling the space of the <ul> tag. In the second line, we make sure that the link is constraining to the same width, and we set the hover property to change the background image. This is the big payoff here. When the user mouses over, instead of doing some fancy JavaScript image swap, we’re using the native CSS functionality to simply change the background to what we need. When they mouse out, the hover expires. Easy as changing the color.

So that’s it for horizontal navigation. Easy, right? But wait! you say. What about dropdowns? Dropdowns require an ID tag, which we’ve already defined. But what if you’ve got a nav parent that has no page? What if nav_02 doesn’t go anywhere? Well, that’s easy. Let’s change the construct a bit:

  <div id="navigation">
   <ul>
    <li id="nav_01"><a href="/item_1.htm" title="Top Item 1">Top Item 1</a></li>
    <li id="nav_02"><a href="/item_2.htm" title="Top Item 2">Top Item 2</a></li>
    <li id="nav_03"><a href="" title="Top Item 3" onclick="return false;">Top Item 3</a></li>
    <li id="nav_04"><a href="/item_4.htm" title="Top Item 4">Top Item 4</a></li>
    <li id="nav_05"><a href="/item_5.htm" title="Top Item 5">Top Item 5</a></li>
   </ul>
  </div>

See nav_03? We take out the URL altogether and add an onclick event. Return false; tells the browser that when the link is clicked, just don’t do anything at all. Effectively makes it a non-link. Then, we change the CSS slightly.

#nav_03 {
	width:148px;
}
#nav_03 a {
	cursor:default;
}

This tells the link to keep the same happy pointer you get for any other element that’s not a hyperlink. So now your link not only doesn’t act like a link, it doesn’t look like a link. But you keep all of your functionality (and the dropdown beneath it).

-pb

http://www.davidbisset.com/2007/12/20/drop-down-list-breaks-float-layout-in-firefox/

Say you have two divs – both have floats so that they can end up being two columns on your site. But sometimes when you add a dropdown menu (<select> tag) to one div) it will break the layout… usually meaning that the other div will be pushed down. And this usually happens only in Firefox. IE sees it just fine.

The solution to this?  Instead of the nice linear coding that you’re used to where the sidebar, to the right of the main area, comes after the main area code, it needs to be before the main area code.

Because apparently, in FireFox 2 seems to have a problem with floated divs, option tags, and SIMPLE COMMON SENSE.

Getting a lot done with AJAX. I’m shifting the user paradigm from a central account area to allowing users to edit things they have access to edit right on the page for instant gratification.

I’m also working on turning PhillyGoth into a WordPress site.

-pb