For 99% of people running SMS, they’re oblivious to what Apache is doing behind the scenes with SMS, but for those that do keep an eye on Apache logs, you know that SMS keeps Apache pretty busy in the way of error logs.  To give you an idea, in the span of less than a week, my SMS site has already generated an Apache error log that’s 16.4 MB and growing.  (For those that don’t know, Apache error logs are just plain text, so getting it up to 16 MB is an accomplishment.)  Part of it, admittedly, is lazy coding practices leaving undefined variables and a lack of checking whether GET and POST variables are even set (leading to undefined index warnings).  It’s pretty much the same errors over and over and over again in the logs.  Technically speaking, there’s nothing wrong with leaving them as is since it doesn’t negatively affect SMS, but let’s face it, generating a 16 MB error file since Sunday morning is insane and should probably be addressed.  Hence, for SMS 2.6, I’m trying to tackle some of those issues and get them resolved as I go.  The major ones with the menu system have already been fixed and checked in to the trunk.  Of course, they won’t all be fixed for 2.6, but a lot will, and the ones that remain will be tracked down and fixed for 2.7 so that by the time we end the 2.x line, SMS and Apache should play pretty nice together.

I mentioned in a forum post a few weeks back about how the notification displays were being updated for 2.6 and how the goal was to make them smaller and a bit more streamlined.  In the process, I showed a few screenshots that indicated the direction they were moving.  They hadn’t gotten much attention until today when I decided that what I had worked on a while back just wouldn’t cut it.  The problem has been to this point (both the trunk as well as all previous SMS 2 releases) that there’s very little immediate recognition of what’s going on.  Sure, up to now we’ve used little icons to indicate whether an operation was a success, failure or whether SMS was throwing a warning at you, but you still had to look.  The whole point of a notification is that you know almost immediately what’s happened.  The current notification just doesn’t offer that.  We need to be giving useful feedback users can use immediately.  To that end, I re-did the notifications this afternoon.

You’ll notice that from SMS 2.0 until SMS 2.5.5, they’ve looked like this:

In my post, I showed off the notifications to look a little more like this:

After this afternoon’s work, they’ve been changed significantly to give users more immediate feedback, so they know what’s going on.

Here are a couple of the other colors to give you an idea of what they’ll look like in various states:

Hopefully this will make it easier to know what SMS is telling you moments after it happens.  As always, this stuff will likely be tweaked over the next few weeks, but this should help, plus, it adds some much needed color to SMS.

There’s been some talk here and on the forums about the various framework additions that will be coming with SMS 2.6, so I thought I’d sum things up here so people know what to expect.  The following framework changes are coming in the next version of SMS:

• jQuery – using version 1.2.1, this lightweight Javascript library will be responsible for some heavy lifting when it comes to tabs and a lot of other snazzy little pieces, like Neptune.  The possibilities for using jQuery are just about endless and with a huge repository of plugins, adding a jQuery piece to a page is pretty easy.  The jQuery team is working on a new release, so it’s likely that by the time we release 2.6, that jQuery 1.2.2 will be out.
• jQuery UI – using version 1.0 (unless they release 1.1 before we launch 2.6) primarily for the Tabs extension.  The great thing about using jQuery tabs is that once you click on the tab, the content is there immediately, no waiting for the page to reload.  It certainly makes it nice when you click on a tab to not have to wait and not have to scroll back to where you were.  The UI also includes a lot of other pieces that could be used in the future or even in custom SMS pages if you want.
• Lightbox – just ported from Prototype, version 0.4 provides that most basic of Lightbox functionality.  Personally, I find Lightbox to be a prettier alternative to Thickbox (a plugin we were using until last week).  There’s one bug that could potentially affect SMS users, and that’s the lack of dynamic resizing of images larger than the browser window.  So, if you have a really big image, you’ll have to scroll around to see the whole thing.  Hopefully this will be fixed in the near future.
• clickMenu – using version 0.1.6, this plugin drives the functionality behind Neptune, the personalized SMS menu.  The developer’s blog states he’s working on a complete rewrite of the plugin, but it’s unlikely we’ll be using the rewrite since Neptune is working like a charm right now.  This is one of those plugins that really only has one use and that’s the way it’s being used now, so you probably won’t find too many people using it elsewhere in SMS.
• Link Scrubber – this tiny plugin eliminates the little dotted link around clicked links in Firefox.  Easy enough.
• Reflection JS – this neat little plugin, at version 1.7, provides dynamic “wet floor” effects to images.  We’re using this nicely on the tour item pages, but I’m sure people will find lots of other uses for it in their own custom pages.
• MagpieRSS – at version 0.72, we’ve been using this since SMS 2.0 for notifying users of updates to the system.  No changes here.
• phpSniff – at version 2.1.3, this library lets us figure out what browser/OS someone is using.  Since we were using it primarily to combat an IE6 issue, we’re going to try to eliminate it from SMS for the next release and save a little space, though depending on how IE7 handles the same issue, it may have to stay in place.

That’s it so far.  There may be a few changes here and there, but overall, this is what you can expect in terms of framework changes for SMS 2.6!

As I’ve been doing implementations of jQuery stuff, like tabs and the click menu, I’ve been focused on making sure they’re as easy to modify as possible.  Previously, presentation and positioning CSS code were mixed in with each other.  While that’ll still be the case, there’s more of a delineation between the two in some of the files.  I’ve taken and separated out some of the CSS that people are most likely to change and made it clear which things they should be editing.  The hope here is that there will be a little less wading through CSS code to make simple changes to a skin.   Below is an example from the click menu…

/* ### START EDIT ### */
/* background color and border color of the flyout menu */
border: 1px solid #111;
background-color: #090909;
/* ### END EDIT ### */

It’s inevitable that you start working on something, get almost done with it, then realize it isn’t going to work as well as you originally thought.  It’s happened quite a bit with SMS and we’ve always turned around to figure something else out that works better than the original idea (menus out of the database is a great example).  Well, you can now add Neptune (aka the SMS Toolbar) to that list.  I’d shared a few screenshots on the forums about the shape Neptune had taken for SMS 2.6.  The people I talked to seemed to like what they saw.  Awesome!

Over the course of a few days though, I started thinking about putting the new menu structure into place in the Cobalt series which is one of the many steps that has to happen as we move toward the testing phase.  I put the first pieces into place, and well, it was ugly, but I expected that  because of the way things were built (necessary because of the plugin I was using).  I started messing around with things and found myself screwing around with little things more and more, to the point that I gave up.  A few days later, I was thinking about it and realized a couple of things.  First, it’s way too hard for a basic HTML/CSS person to do and do well.  The forums would be flooded with questions about doing this, that or the other thing.  Strike one.  Second, it was very limited in that it would only be able to be placed on the left side of a page, otherwise, there was some major (and pretty advanced) CSS needed to make it behave correctly.  Strike number two.  Finally, there was an issue where the entire process wasn’t entirely intuitive.  Strike three and you’re out.

That left me in the unenviable position of having to rethink the strategy behind this feature.  Believe me, it’s not a position I enjoying being in.  So where to from there?  I stirred over the idea for a few days and didn’t come up with anything until I was poking around my Facebook account and noticed a little flyout menu at the top.  That immediately drew me back to a conversation that’d happened on the forums a couple weeks ago where someone suggested a drop down menu.  The problem with the web is that terms can easily get lost.  Someone suggested drop down menus, but in terms of web development, drop downs are usually the HTML select elements.  The idea of using something like that right in the main navigation left a sour taste in my mouth right away, but seeing the flyout on Facebook got the wheels turning.

It took a lot of searching, but it turns out there’s a jQuery plugin that does exactly what I was looking to do.  I plugged everything in and it got ugly really fast as there were a lot of problems with overlapping styles.  But after wading through code and stylesheets for a few days, I finally managed to get something working that was exactly what I wanted.  A small arrow to the right of the menu signals a submenu, and after clicking on it (clicking was very important … I hate accidentally mousing over something and having a menu flyout), the submenu appears.  On top of that, it allowed me to increase the number of link options from 6 to 10.  Plus, it’s less obtrusive than the previous iteration.  Finally, it’ll be far easier to tweak this menu for different skins (if someone so chose to do that).

For anyone interested, the new jQuery plugin being used is called clickMenu.  Below is two images of the new iteration of Neptune as it stands in the default skin.  Haven’t gotten around to tossing this into the Cobalt series yet, and it’ll probably be a few weeks, but this is the start of things.