Imminent Transcendence

As promised, here is a post about skinning for ImperialBB.

Since I assumed the position of ImperialBB Designer several months ago, I’ve been neck deep in more CSS and HTML than I’ve ever been in my entire online career. This was a completely new experience for me. The only thing I’ve ever done in the past 6 years, as far as skinning is concerned, is color changes, HTML changes, and very few graphics here and there to things that were already pre-existing.

I was never extremely good at the graphic aspect, and I still don’t think I am. The postbit buttons in ImperialBB v1 are of my design, and I’m very critical of them. The rest of the team enjoy them, but every time I look at them, I find some other small flaw that just irritates the hell out of me. Those are going to be revisited today, because I have this little problem where I can’t stand to have something I’ve done be less than perfect.

Anyway, moving on after that little rant, here are my thoughts on skinning ImperialBB v1.

First off, I have to say that, when compared to other software, we have very few templates. Thanks to our template engines Nests, Conditionals, and Tags features, we are able to drastically reduce how many templates are required in order to display a page. Excluding the Header, Footer, and Pagination, most pages on ImperialBB only take one template to render everything.

For example, the template for viewing a forum is called “view_forum”. This is the only template that is used to fully display this page.

If you look at that screenshot, you see pretty much everything a modern BBS should display. Skin designers should know that certain information needs to be repeated using the same code over and over, and that these are called “bits”.

A common dilemma that comes with designing anything as dynamic as a bulletin board system, is how to repeat HTML that is supposed to display data pulled from either a database, or a cache. On top of that, it needs to be done efficiently. And on top of that, if you’re planning on marketing the product, it needs to be easy to change.

Each BBS has their own way of displaying bits of data. The more common method is to use “bit” templates that contain the HTML that needs to be repeated, along with the variables to dynamically change the information.

For example, you see this in the main template:

<table>
 <tr>
 <td colspan="4">Customers who purchased Product X</td>
 </tr>
 <tr>
 <td width="5%">ID</td>
 <td width="50%">Customer Name</td>
 <td width="25%">Purchase Date</td>
 <td width="20%">Active Status</td>
 </tr>
 $customerbits
</table>

And this in another template, that gets repeated for each row of data:

<tr>
 <td>$customer[customerid]</td>
 <td>$customer[customername]</td>
 <td>$customer[purchasedate]</td>
 <td>$customer[active]</td>
</tr>

And if there is no data, then, chances are, you also have to use yet another template to notify the viewer.

<tr>
 <td colspan="4">No data to display.</td>
</tr>

This is all fine and dandy, and works well. In fact, it’s great for organization. However, one thing I’ve found very irritating when messing around with any systems HTML is having to jump back and forth between the main template, and its associated bit templates.

In ImperialBB, we have completely eliminated the need for bit templates. All data generation is done within the main template. So, instead of having three templates to perform a function, we now have one.

<table>
 <tr>
 <td colspan="4">Customers who purchased Product X</td>
 </tr>
 <tr>
 <td width="5%">ID</td>
 <td width="50%">Customer Name</td>
 <td width="25%">Purchase Date</td>
 <td width="20%">Active Status</td>
 </tr>
 <!-- BEGIN SWITCH customers -->
 <tr>
 <td>{CUSTOMER_ID}</td>
 <td>{CUSTOMER_NAME}</td>
 <td>{CUSTOMER_DATE}</td>
 <td>{CUSTOMER_ACTIVE}</td>
 </tr>
 <!-- SWITCH customers -->
 <tr>
 <td colspan="4">No data to display</td>
 </tr>
 <!-- END SWITCH customers -->
</table>

I’m not going to get into the technical specs of creating nests and tags, that will be the subject of another blog post geared towards Developers.

As you can see in my above example, we’re achieving the same thing, but all contained within one template. This system has drastically reduced how many templates are contained in ImperialBB, while still retaining a modern BBS feature set.

After I was tasked with designing ImperialBB, I took the mockup done by our previous designer, and applied it to the ImperialBB templates, throwing in my own touches where needed.

The original mockup was only coded for Board Index, so I had to think of new concepts for the rest of the pages, and how to apply an easy-to-use interface that is still visually appealing AND easy to modify for skin designers. Something I have never done before.

If you’re designing a skin for ImperialBB, you have several options available to you.

For starters, you can actually use your own Editor. There is no need to code a template up, then copy and paste into an Admin CP Template Editing interface. Simply download the template file, modify to your needs, and upload. ImperialBB will handle the rest. The same concept applies to CSS. All of ImperialBB’s CSS is contained in files, not the database, so you are free to download the CSS files, modify them, then re-upload and have your changes take effect instantly.

But wait! Do you not have an Editor? Do you not know CSS well enough to tinker around inside a pure CSS file? No problem! ImperialBB has a Template Editing Interface in the Admin CP that allows you to modify your templates the old fashioned way. It also features an enhanced CSS Editor that takes all CSS Classes from any file of your choice. You click the class, and AJAX loads it up in an easy to use interface, and displays each definition as well as it’s value. This is extremely convenient for large CSS files, and makes finding a particular class rather easy.

ImperialBB’s Admin CP is also templated, so you’re free to modify it however you see fit. However, I decided to use tables throughout the Admin CP. I decided this because it makes it harder to break when modifying the Admin CP CSS. The features will retain their structure, even if CSS is destroyed.

Most skin designers will want to change HTML to make their designs more unique, I have no doubt about that. Hell, I even encourage it. In SVN right now, ImperialBB has 93 templates dedicated to displaying front end features. Needless to say, that is not a lot.

It took me roughly two to three months to rewrite all of those templates for the new skin. And that was because I only did one or two features per day. So, one day I focused strictly on View Forum, and then the next day I focused on View Topic. I was taking my time to make sure each feature got the attention it needed, so I could have probably done it in less time.

Now, I know, most designers will not be modifying all of the templates… but that should give you an insight on how long it could take you to design a skin for ImperialBB.

I really look forward to hearing comments and feedback on skinning ImperialBB. And you can rest assured that any suggestions posted during the Beta process, to make skinning easier, will be taken in by me personally and hopefully implemented before we go to the Release Candidate stage.

Now, comes the CSS3 debate.

ImperialBB does use CSS3 in several places, however it’s usage is not required by any means. You don’t even have to modify CSS files to remove CSS3. Simply flip a switch and boom… it’s all gone.

This is especially important for skin designers to know, because all CSS3 is contained in it’s own CSS file that is only loaded if CSS3 is enabled in the forum owners configurations, it’s not determined on a skin by skin basis.

Thanks for reading, and I look forward to your comments!

Skinning for ImperialBB

Tags: design, ImperialBB, skins

This entry was posted on Tuesday, February 2nd, 2010 at 11:23 AM and is filed under ImperialBB. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.