Even with two more releases in the SMS 2.x line remaining, a lot of people I’ve been talking to lately have shifted their attention to the future and SMS3.  There are, rightfully so, a lot of questions about the next major version of Anodyne’s RPG manager and what people can expect.  While it’s still very early, I don’t want to keep everyone completely in the dark about what the next major version of SMS will contain.

For those who currently use SMS2, there will, sadly, be very little new in the way of revolutionary features, but will have far more refinement.  For those who haven’t been able to use SMS2 so far (mainly those in other RPGs of other genres), they’ll get the chance to see what most people already know: how easy managing an RPG can really be with SMS.  For them, some of the feature set may be pretty cool, but mostly, SMS3 is a refinement release and finally making SMS the product that I envisioned when I took it over 18 months ago.

While SMS2 represented a lot of user-facing features, SMS3 will represent a lot of “under the hood” features.  There will be a whole new framework put in to place that I’m excited about.  For anyone familiar with programming, we’re moving to an MVC (model-view-controller) setup.  This allows us to separate logic and presentation, meaning we can make more coding changes without touching the skins.  On top of that, it allows skinners to have absolute control over what each page looks like.  I’m aware this creates a few issues, first of which is that, SMS2 skins won’t be compatible with SMS3.  It’s just way too different.  Second, there will be a lot more files in SMS3 skins, much like phpBB skins.  All in all though, it will give people greater flexibility.  Maybe you don’t want to see a column in a page.  Simply remove it and the system adapts (at least for that skin).

The framework we’ll be using also gives us a lot of tools to make SMS far more efficient.  Instead of manually building HTML tables, we now have classes to use for creating tables, zebra rows, headers and much more.  The depth to which this framework extends is mind-boggling.  On top of presentation tools, the entire framework has been built to allow the use of plugins and system hooks which will come in handy for anyone interested in developing third-party plugins for SMS.  Beyond that, SMS will get more secure as we start dealing with XSS filtering and better scrubbing for SQL injection.  Finally, there will be localization support, meaning that RPGs won’t have to change every file in the system after every release, they’ll just need to keep a single file updated.  The challenge here is that I have to learn a whole new way of doing things, but in the end, it’s going to be the best possible course of action we could take for this product.

For anyone NOT doing third-party development or skinning, this is probably a pretty anti-climactic post, but these are the things that we’re focusing on for the next major version in the hopes of making SMS a more robust and rounded web application.

One thing that’s always bugged me about SMS is the fact that there are sections of the skins that need to be defined.  Whenever someone duplicates a skin, they have to make sure they change those references otherwise the skin will still look for images in other folders.  It had just been something that I kept wanting to do, but it just slipped down the list or I’d forget about it before releases.  Since it was on my mind, I decided to go in and do something about it.  With SMS 2.6, skins are going to be a bit smarter in knowing “where” and “who” they are.  Now, duplicating and/or renaming a skin will just require that step, no more going into the files to make sure that the references are right.  It’s a little thing, but SMS 2.6 is all about refining what we’re doing.  It’s a cliche, but it really is the little things.

It’s been a quiet few weeks for me as I’ve been taking a little break from developing after the whirlwind of getting 2.5 finished up and out the door. Work on 2.6 is set to begin in earnest over the next few weeks and it should be a fun release with a lot of challenges that’ll make SMS that much better. As things get completed, I’ll fire off some blog posts about the kind of features you can expect from the next major release. The goal with 2.6 is to refine what’s already there, so I’ll let your minds dance with that for a few weeks.

I mentioned (on the forums I think) that SMS 2.6 would launch Anodyne into the Web 2.0 world with a feature known only as Neptune right now. That’s still the case, but I wanted to expand on that a little and talk about the (short) road to Web 2.0 so far. One thing that’s bothered me with 2.5 since early in development is the fact that tabs required a full page reload. Unfortunately, at the time, the schedule was tight, so I just had to keep plugging on, knowing full well that I’d have to come back and tackle the issue in the next release. After 2.5 was released, I started looking into various options for tab content being immediately available. Neptune aside, this refinement would take SMS into the Web 2.0 since one of the major “features” of a Web 2.0 application is use of JavaScript libraries, and none is more popular these days than Prototype and its animation counterpart Script.aculo.us for what I needed to do. So, a few weeks back, I pulled down copies of both and started playing around. I’d found a great tabs system in the Control.Suite from Live Pipe. It was good stuff and I even had it working at one point. Then the alternatives started rolling in.

The next popular JavaScript library out there is YUI, or the Yahoo User Interface library. It’s a project that Yahoo’s been working on for a while now and it’s a great effort. Then there’s extJS which is an offshoot of YUI. I checked both out, but never bothered to pull down copies and try to change what I already had working. Then, another one came up: jQuery. I’d remembered hearing about jQuery and that Wordpress was moving from Prototype to jQuery. I was intrigued since some of my original inspiration for SMS came from Wordpress. A little research showed me that jQuery and Prototype were actually very similar, but jQuery has a far more active developer group. As I dug deeper, there were two major complaints with Prototype. The first was that it wasn’t updated very often, which developers wanted to see more of. The second was the size/speed aspect. Turns out that with Prototype and script.aculo.us running together, they have a footprint of about 230kb. Nice chunk of change right there. jQuery has a footprint of about 28kb. Holy cow. On top of that, jQuery released a minor update a few months ago that, according to their tests, increased the speed of some operations by almost 800%. Insane. jQuery was looking like a better alternative, but I’d already developed the new tabs with Prototype, so I figured I’d just have to wait until SMS3 to roll in jQuery.

Once I started looking at the setup of the two libraries, it became pretty clear that they were similar enough that I wouldn’t have to wait until SMS3 to roll jQuery in. Very cool. On top of that, once I got the Prototype tabs into the trunk, I noticed some performance hits and some weird rendering bugs when switching tabs and loading the pages. That’s not good. I took some time to get myself up to speed on jQuery and then spent a few hours tweaking the tabs to use jQuery instead of Prototype. The end result is a tab system that makes the content immediately available when you click. No more reloading when you switch tabs, just instant gratification. On top of that, no noticeable speed decreases and the rendering issues from Prototype were gone. I’m definitely a happy camper with this, plus it paves the way for some even cooler stuff for Neptune, which is exciting.

Another little housecleaning tidbit for SMS 2.6? We’ve used phpSniff since 2.0 to detect the browser. Since this was done primarily because of issues with IE6, that’s no longer necessary, so we’ll be saying goodbye to phpSniff and hopefully getting a tiny speed bump there, plus a decrease in the archive size.

Update – turns out that jQuery provided an even smaller distribution of the library, so instead of almost 80kb, it’s now only 45kb.  Huzzah!