One of the things I’ve heard consistently over the last few years is how people wish SMS skins were built from a single file instead of several different files.  Given the way SMS was built, that just wasn’t an option, but when I sat down to build the architecture for Nova, moving over to a single template file was a top priority.  In the big scheme of things, it doesn’t seem like a big thing, but the easier I can make it for people to skin Nova, the more skins the community will see and the more variety everyone will see  across the Internet.

Well, I managed to do exactly what I set out to do.  Nova’s skins are driven from a single template file that can be built however someone wants.  All tables?  Go for it.  Modifications of a current skin?  Easy.  Image-based layout like SMS 1?  Do it.  There’s a lot of flexibility.  But the HTML hasn’t been the hurdle people struggle to get over, it’s the CSS stuff.  I’ve had the luxury of working with CSS extensively for about 7 years now.  If something doesn’t work, I can usually fudge it until it looks right.  The majority of people skinning Nova (and SMS as well) don’t have that luxury, so it’s important to make skinning as easy as possible.  One of the ways to do that was moving everything over to a single template file, but I also had to address some of the confusion over stylesheets and today, I think a good solution landed in the trunk.

In SMS, a skin was broken up into 5 stylesheets: style-main, style-clickmenu, style-login, style-misc, style-ui.tabs.  Whew!  That’s a good chunk of stylesheets and, let’s be honest, the names are terribly descriptive of what each controls.  Usually, someone will end up combing through all 5 stylesheets trying to find one thing to change.  That’s just frustrating, especially when most of the CSS code isn’t applicable to what they’re trying to do.

Then came along the first iteration of Nova skins and not 5 stylesheets, but 7: main, display, forms, text, panel, reset and ui.tabs.  Sure, file names are a little more descriptive now, but I managed to add complication to the stylesheets by increasing the number of stylesheets you’d have to wade through to find your stuff.  Fail.  Back to the drawing board.

Over the course of Nova development, I’ve flirted with the idea of using a CSS framework because the folks putting those together are a helluva lot smarter with CSS than me.  But still, I’ve always hesitated doing that because I don’t want to force people to learn a way of building their site that conforms to a particular framework, not matter how powerful it may be.  But in the process of bombing around the Internet a few months ago, one in particular caught my attention: Objected Oriented CSS.  Now, for anyone reading who just had a mini panic attack, you can relax, because Nova isn’t using a framework, but the concept was incredibly simple.

The big draw of using an application framework for Nova was the ability to separate business logic and presentation from each other.  The Model-View-Controller paradigm is a great one, especially for web applications like Nova.  So why wouldn’t something like that work for CSS?  Nichole Sullivan, the creator of OO-CSS, argues that there’s no reason you can’t treat CSS like that.  Her ideas are awesome and I encourage you to check them out sometime, but for Nova, I wasn’t about to re-architecture skins for OO-CSS, but I borrowed a simple concept: functional separation.

When it comes to Nova’s skins, there are two main areas: structure and style.  Structure is the nuts and bolts of the CSS … width, height, margin, padding, float, outline and all the other powerful selectors that tell our stuff where to go and how to behave.  At the same time though, structure can be the most confusing stuff to understand, so let’s get it right out of the way.  For skin developers who want to mess around with that stuff, it’s there in a stylesheet called structure.  What about the rest?  The styles like colors, background colors, background images, borders, font sizes, font weights and much more that people are interested in tweaking, we’ve grouped them together in skin.css stylesheet.  That means when you want to change the color of text, you know right where to go and you won’t have to mess around with the other stuff.*  The only exception to this is that the major layout pieces of the skin are held in the skin stylesheet, effectively meaning that the majority of people looking to edit skins probably won’t have to touch the structure stylesheet at all.

This simplified approach to skinning the system should help out those folks who aren’t as comfortable with CSS but who still want to tweak their Nova skins a little bit.

* In addition, we have a ui.tabs stylesheet, but the only reason that wasn’t combined was because we offer the option to override the tab style from the Nova style to the jQuery UI style, so keeping that separate was necessary, otherwise people who wanted to do that would have to copy and paste all over the place.

Distributing Nova presents some unique challenges because of the genre feature.  SMS was easy to distribute because it used a single genre and it was really easy to distribute because I could just zip it up, throw it on the server and people would download it.  The same isn’t possible with Nova for a couple reasons.  First, if we provided a single zip archive, it’d be massive because we’d need to include all the genre rank images along with the system.  For people with hefty Internet connections that can download and upload those kinds of file sizes, that’s fine, but for the average user it’s just not feasible.  Second, if we broke the genre files out to a separate download, then the user needs to download a second package, unzip it and put the files in the right location.  Sure, maybe that’s not too difficult, but the goal here isn’t “not too difficult”, we’re aiming for easy.  The only conclusion to come to was that Nova needed a download builder.

Fortunately, I have a little experience with the kind of code involved.  At a previous job, I was responsible for developing HTML emails for a client.  Each email was identical save for new images and new content.  On average, it’d take me between 60 and 90 minutes to build an email.  That’s all well and good, but I had other responsibilities as well, so I sat down and started building a simple system that would move files from a source directory into a directory dedicated to email output.  The whole thing started with a simple form where I’d copy and paste the content into text boxes and hit submit to trigger the magic.  Even with all the Photoshop work that needed to be done, I was getting these emails done in about 15 minutes.  I was saving the company between 45 and 75 minutes for every email.

So how did it work?  Pretty simple actually.  On the front page of the system, you’d just paste the content into the appropriate boxes and hit submit.  Once the form was submitted, it’d take those POST variables and put them in the proper locations in a template.  It’d then write the template to a file and move it to the proper location in an output directory.  Once that step was finished, the script would go out and move files from a source directory into the output directory.

When it comes to a download builder for Nova, that seemed the most logical place to start.  Use a source directory with the latest version of Nova and copy files around the server until we have what we need then zip it up and offer the download to the user.  So that’s where I started, but immediately a challenge presented itself.  What if multiple people were building their packages at the same time?  Using a single folder wouldn’t work at that point because one might overwrite another.  That’s no good.  The answer was that the folders needed to be unique, so the next step was to create these directories on the fly with unique names.  CodeIgniter has a grand little string helper that’ll generate random strings for you, so I started using that to programmaticly build directories with random 16 character alpha-numeric names.  Beautiful.  But once that was done, another challenge popped up: file permissions.

Now, on a distributed system like Nova, creating a feature that relies so heavily on PHP modules being turned on would be impossible.  It’s just too hard to work on that kind of thing.  But with a close system like the Anodyne site, it’s a lot easier.  But still, when you’re fighting with file permissions and the server creating files and whatnot, it’s significantly more difficult.  Try as I did, there was just no good way to get around the file permissions stuff.  Add to that a memory usage of about 3MB per request and you can see how a lot of users hitting it simultaneously (say the Nova launch), would cause problems.  Unfortunately, I didn’t see any other options, so I had to keep going.

The next step was zipping the files up.  Fortunately, that was the easy part because CodeIgniter has a zip archive library that helps with zipping files up and offering them to the user for download.  As I read through the CI User Guide about the library, I saw that the library wasn’t just for zipping files up, it actually provided a whole series of methods for creating the zip archive from scratch and adding files and directories to the archive on the fly.  Wait what?  I’d done all this work and it might be possible that CodeIgniter has a built in solution?  Golden.  So I loaded the library up and started working on doing the same thing I’d already done, but through CI’s zip library.

I was just about finished when another problem crept up.  This time, the library maintained the file structure of the source directory when adding directories.  That was a problem because adding the CI core and Nova core would require adding lots of directories and sub directories.  Instead of putting it in all nice and neat, the library would put it in the archive like /some/deep/path/to/source/dir/application.  Pretty useless when a user has to pour through those kinds of folders just to get what they’re looking for.  Lucky for me, the amazing community around CodeIgniter had already come up with a solution.  After downloading the extended zip class, I was on my way and in a matter of minutes, was offering up downloads to myself with the options I wanted.

So how does it work (generally speaking)?  Pretty simple actually.  You select the genres you want and click download.  The builder will take all of your genre selections and move the images and ranks folders where they belong, which is really handy in the event you select more than one genre.  If you only select one genre, the builder will also move a Nova config file into the right place that already has your selected genre set up meaning you only have to update your database settings and then install.

The builder should be a great tool for Nova when it launches and make life significantly easier!

M6 is officially underway and we’re excited to be able to make one of the major goals available in its entirety after only 30 days in the milestone.  Nova now includes all the reports it will ship with.  One report that bit the dust from SMS is the Sim Progress report.  It was easily the most difficult report to build in SMS and it’s more difficult in Nova.  We’ll certainly look at adding it back in the future, but for Nova 1.0, it won’t be there.

In addition, we’ve included the first of the upgrade work, so users will be able to test out how the upgrade process works.  Instructions are available inside the zip archive.  This report covers revs 1581 through 1697.

Added

• jQuery UI Accordion plugin
• jQuery QuickSearch plugin
• System update tab to the ACP panel
• Crew Activity report
• Applications report
• LOA report
• Milestones report
• Posting Level report
• System report
• Award Nominations report
• Moderation report

Updated

• Version numbers in the constants files are more consistent with what’s in the database
• Some icon work throughout the system
• Language files
• CodeIgniter updated to version 1.7.2
• Database schema
• Basic install data
• Upgrade controller with the start of the upgrade process
• Update controller with the start of the update process

Since April of 2005, people have been amassing tons of SMS data.  Moving from version 1 to version 2, we managed to keep almost all their data intact and people have continued to add to the data over the years.  There is a lot of data in there that most people wouldn’t want to get rid of either, but manually updating the information to Nova would just be a pain.

Enter the Upgrade Center.

One of the biggest focuses of Nova M6 is the upgrade from SMS to Nova.  Moving from SMS 1 to SMS 2, we used a very similar database schema, so rolling the data over was relatively easy.  Nova uses a completely different schema though, so moving all that data over is significantly more difficult.  Still, it’s a major issue we want to tackle head on with the Nova Upgrade Center.

So how does it work?

One of the big changes in Nova that people probably aren’t going to like is that we’ve moved back toward manual config files instead of writing the files for the user.  Some may view that as a step backwards, but it makes the process of installing/upgrading that much easier from a support standpoint.  One of those manual config processes is the upgrade.  It isn’t possible for us to pull all the data over, mainly because of the MASSIVE changes made to the database, but we’re trying to get as much of it as we can.

Before doing the upgrade, an admin just needs to open a single config file and select what they want upgraded.  By default, we’ll do everything listed in the page, but if an admin doesn’t want certain items upgraded, they can just change the item to FALSE and Nova won’t attempt to upgrade that item.

So what’s being upgraded?

At this point, we’re upgrading awards, a scant few settings, missions, news, logs, posts, players and characters.  We’ll likely add to this list over the next few weeks, but for the time being, those are the big items we’re pulling over.  Some of those are tougher than others (read: characters and players), but we’re going to get it right so that upgrading to Nova is as seamless a process as possible.

As of right now, Nova can upgrade some settings from SMS to Nova, awards and missions.  It’s a long, very tedious process doing these upgrade pieces, but when you see it work, it definitely makes it worth it.  I’ll probably slip the upgrade stuff into the October build even though it’s past the last day of the month (which is the cut-off for a build).  It’s just one of those things that’s too important not to put it into people’s hands to test.

It’s hugely rewarding to watch all the work that’s been going in to Nova start pay dividends.  We’re starting to get closer!