How many times have you been putting together your manifest in SMS and been frustrated that you needed to create a new department for a group of characters that are technically part of another department?  I think right away to things like Marines and fighter pilots.  What if you want to group various squadrons of fighters under a single department?  In SMS, you were out of luck, but in Nova, sub departments have arrived!

Sub departments are departments within departments.  To highlight how useful sub departments are, let’s build a situation to use them.  Let’s say you’re running an RPG with a fighters.  It’s a big ship, so you have 100 fighters assigned to the vessel and those 100 are broke down into squadrons.  In Nova, you don’t have to spend all kinds of time organizing the positions so all the various squadron positions are next to each other, you can simply create a new sub department.  When you go to create a new department, there’s an option to select a parent department, or in other words, the department in which the sub department will be added.  Once the sub department is created, you can assign positions to it or create new positions just for that sub department.  (Unfortunately, if you have 10 fighter squadrons, you’d need to create 10 pilot positions, one for each sub department.)  After that, just assign your characters to the right positions and you’re good to go.

When you check out the manifest, you’ll see any positions in the fighter department that aren’t part of a sub department, then like departments are displayed, you’ll see, indented slightly, the various sub departments associated with that department.

At this point, Nova doesn’t allow sub departments to have their own sub departments (a.k.a. nested sub departments).  We may add this functionality in a future version of Nova as well as the ability to assign departments positions to multiple groups without re-creating the position.

Over the 3 and a half years SMS 2 was in the public domain, people got used to how they interacted with SMS, regardless of whether it was good or bad.  With Nova, the goal was to keep the good and improve on the bad.  The mantra during Nova development was “is there a better way?”  In a lot ways, the way SMS did it was good, but there were a handful of places where I was able to significantly improve the user interface to make it easier to understand and simpler to use.

Position Updates

Easily one of the biggest UI updates is to the position management.  SMS forced admins to change the number of open position slots with a number in a text field.  It works, but there was a better way.  Again leaning on jQuery’s UI library, open position slots are now handled through a simple slider with a range from zero to fifty.  Want more slots open for a position?  Just drag the slider until you have enough open positions and click Update.

Update All

For admins, one of the biggest gripes about SMS is when updating positions, departments and ranks that they have to take action on each item individually instead of updating all items on the page and updating them at once.  Nova does away with that behavior.  Update everything on the page, click the button once and everything is done.

New Form Layout

Forms in SMS were laid out with the label to the left and right-aligned.  It certainly wasn’t a bad way to do it.  Forms can be tricky to design from a user experience point of view.  When you get a lot of form fields, using labels to the left can get messy and confusing for someone filling out the form.  I could’ve left forms in Nova alone and been fine, but after an experiment with grouping a form’s field label above the field itself, I was sold that Nova’s forms needed to be updated.  Now, most of the forms in Nova put the label above the field.  Doing this makes moving through the forms easier than left-aligned labels.

The New Join Page

One of the biggest UI changes is probably the join form.  SMS displayed everything all at once, but that can definitely be daunting to fill out.  To make it a little less daunting, the new join form is broken down in to several tabs.  The first tab is player information, the second tab is basic character information, the third tab is the rest of the character information and the fourth tab is other information, like the sample post question.  In addition to breaking things into the tabs, Nova uses a Next Step button to move through the form easily.  It’s definitely a new way of laying out the join form, but it makes the form less daunting.

For the last couple of years, one of the biggest technical buzzwords on the Internet was Ajax.  The technology (which is an acronym for Asynchronous Javascript and XML) can be used in very powerful ways to create user experiences that are more closely tied to a desktop application than a web page.  SMS started to delve into a little bit of Ajax, but Nova utilizes the technology to really create some useful interactions that help you when you’re interacting with the system.

Position and Rank Dropdowns

One of the places I put some Ajax functionality is when editing a biography.  In SMS, when you edited a bio or created a new character, you had to know what position you wanted to assign to the character, otherwise you’d have to check a different page for the position description.  In Nova, once you’ve selected a position, Nova uses Ajax to go out to the database and pull back the position description and display it below the dropdown menu.  The same type of interaction was created for the rank menus too.  In SMS, the rank dropdown were built to work in Firefox, but unfortunately putting images in a dropdown menu in Internet Explorer doesn’t work.  Now, when you select a rank, Nova grabs the image and shows it so you have immediate feedback about the rank you’re assigning to the character.

Award Nominations

Awards are renowned for being difficult to interact with, especially if you have more than a few awards.  In SMS 2.6, the system gained the ability to give awards to NPCs as well, which was a cool addition, but there were rules for what types of awards NPCs could receive.  The requirements meant that I had to create two different sections for giving awards to playing characters versus NPCs.  That’s all well and good, but there’s a better way to do it.  Using some simple Ajax functionality, Nova tells you to select a character then goes out to get information about that character and display only the awards that type of character can be given.  But that’s not all.  Like the position and rank dropdowns, when you select an award, it’ll automatically pulls back the award description so you know exactly what award you’re giving to that character.

Chain of Command Ordering

One of the coolest Ajax/UI improvements to Nova is the Chain of Command management page.  In SMS, admins have to order the listing by changing a numerical value in a text field.  That works, but there’s a better way.  Utilizing a component from jQuery’s UI library, Nova builds a list of the items in the chain of command and attaches drag-n-drop functionality.  You can literally drag the items around into the proper order and click update and Nova goes out, without any refreshing, and updates the database.  The same type of interaction happens when you remove an item from the list.

Ajax is a very powerful technology that Nova has begun to leverage to create a better user experience with some of the trickier areas of Nova.

Every couple of weeks, the Anodyne forums will have a question asked about how to install a skin or rank set.  It’s a fair question, but it’s tough when you’ve answered it a hundred times over the years and people don’t read FAQs or do a search on the forums.  While Nova can’t solve people’s inability to search before posting, it does attempt to tackle the install issue with a feature that allows quickly installing skins and rank sets.

One of the big changes with skins and ranks was grouping them together into system catalogues.  Doing this gave us a lot more flexibility for manipulating the skins and ranks, setting defaults, dealing with deleted skins/ranks and setting statuses for skins/ranks.  The original thinking was that installing a skin or rank was much easier this way because you’d just click Add a Skin and fill in the form and be done.  But as we started to think about it, one thing dawned on us: people are lazy.  As harsh as it sounds, it’s true.  People are lazy and they want to do as little work as possible.  Fair enough, but when someone has slaved over a skin for weeks, they’d appreciate getting credit for the skin.  A lazy admin might not put the credits in the skin, thereby screwing the skin developer over.  I’ve been in that situation before, so I can certainly sympathize.

To solve the issue, we’re using YAML files to store basic skin information like name, location, credits, the sections, etc.  The YAML file is placed in the root of the skin where Nova can look for the file.  If it finds the file, it’ll prompt the user that there are uninstalled skins.  All the admin needs to do then is click on the install button and Nova does the rest.  All the credits and information remain intact and the process has happened almost instantly.  The same thing goes for ranks, too.

As we put the finishing touches on the feature, the flexibility of such a solution really hit us hard.  One of the things we’d been struggling through was the most efficient way to handle shipping multiple skins with the system that related to different genres.  The only thing we could come up with was calling the skins the same thing then hardcoding the information into the install files.  Only problem was that it relied on us maintaining as many install files as we have genres.  Wildly inefficient.  Then it dawned on us, we can use Quick Install just without the user interaction.  We hardcode the default skin in to the install files since it’ll be the same for all the genres then simply ship whichever skins we want with each genre.  After that, we use Quick Install to simply install whatever skins are left besides the default one.  The same thing happens with ranks.  It means that a game master can throw a handful of skins and ranks into the proper places before installing and when the system is done installing, there are all the skins and ranks they wanted (assuming the developers have used the Quick Install files … all of Anodyne’s stuff will).

Quick Install was one of those features that just kinda hit us and after we did the legwork we realized it’s potential.  Those are the best kind of features!

CodeIgniter’s structure is built around the idea of re-usable libraries, helpers and models and we’ve taken that concept to the nth degree in Nova by building our own authentication library to handle things like logging in, checking login attempts, setting session variables, setting cookies and much more.  The best part about the Auth library though is that it’s available to any developers to use for checking a user’s credentials or hashing a string!

I realize this is a topic that the average user is going to read with glazed eyes, so I’ll do my best to keep the technical details to a minimum.  Essentially, the library is a PHP class that handles checking a user’s credentials and passing information around the class for doing things like setting session variables or checking if a user is a system administrator.  Because the Auth library is separate from the login page, it means we can reuse those components elsewhere in the system, giving us a whole new level of flexibility with our components, something SMS never had.

Why would a developer care about this?  Being able to verify if a user is a system administrator allows a developer to create a page with logic to show a link or different components based on that without having to manually write the code to do so.  More to the point though, building the Auth library like this has allowed us to add a killer feature to the system: remember me.

The Nova login page now includes a check box that, when checked, will set a cookie with the user’s username and password.  If a user goes to the site and has that cookie set, Nova will automatically log them in so they can continue with what they’re doing without interruption.  By default, the cookie will be active for 14 days, but that setting can be changed from the config files.  For the span of a few weeks a few years ago, several people requested the feature, but CodeIgniter made it incredibly easy to add this feature.  How easy?  The entire authentication system was built in 2 days as opposed to the weeks it took to build and tweak the SMS authentication system.