The QA team was handed SMS 2.5 Beta 2 earlier today.  This marks another big milestone for the project as we inch closer to our release.  At this point, there are only 2 outstanding issues and 1 missing feature left to be addressed before the release candidate in another 10 to 14 days.  Beta 2 brings a lot of changes, namely moving the menus into the database and fixing the glaring bug plaguing Internet Explorer.  A handful of other issues were fixed for the beta as well.  It’s encouraging when one of these milestones is reached, because it’s one step closer to getting it into the community’s hands.  They’ve waited a while for this release, but I think it’ll most definitely be worth the wait.

One thing that SMS has been lacking since 2.0 is a first launch feature.  We make a lot of changes between releases and if a user isn’t prompted, then they really have no way of knowing what’s been changed.  Admins should know what’s been changed about their site, so I’m adding a first launch feature.  When you install SMS and first login, admins are shown a box highlighting all the changes that’ve been made.  When you update SMS and first login, the same thing happens.  The display will only be shown once so that it doesn’t get overly annoying.  Just a little thing.

Beta 2 is shaping up nicely and should be in the hands of the testers in under a week.  It’s getting close…

So I’m already loving the whole UNIX timestamp thing in SMS, at least from a developer’s standpoint.  I started making the changes and it’s just so much easier running the timestamp through a function to get it to do what I want.  By default, there are three different formats used in the function, but that could be increased to a whole lot more and easier changed by simply swapping out the first argument of the function declaration.  However, changing them in the update will be fun.  I have the code to do it, but it’s just a matter of how many times it has to be done.  I’ll probably work on some kind of for loop to handle it, but we’ll see.

More often than not, being a Mac owner has wicked cool moments.  I commented to a friend of mine a few weeks ago that I felt like the third-party development scene is much stronger with Macs than with Windows.  Now, I’ve been out of the Windows world for a few years now, so maybe I just didn’t notice it before, but you don’t tend to hear about “wicked cool” third party applications being developed for Windows.  I’m sure they’re out there, but they aren’t given as much prominence as Mac applications.  I mean, Apple devotes a whole section of their developer conference to awarding independent developers for their hard work on their applications.  TextWranger is a free text editor for Macs that I used for quite some time to code SMS.  Slowly, I moved over to skEdit, a light-weight text editor that added some cool features like projects to make my life with SMS that much easier, but when it came time to test, I still had to pull out a trusty FTP client to get my stuff to the web.

Enter Coda.

Panic Software has long been known for their awesome Mac software and they’ve struck again with Coda 1.0, an all-in-one program that delivers a text editor, FTP client, CSS editor, terminal application, and even built-in reference section to a single program.  I saw they released it today and pulled down a copy to test it out.  “Wicked cool” is about the only thing I can use to describe this program.  It has all of the Apple flourishes that make it distinctly Mac, but then beyond that, it has those little things that make so much sense, yet you’ve never seen them in applications before.  How about a keyboard shortcut to un/comment a line(s) of code.  Well yeah, that makes a lot of sense.  Built-in project views that can use either local directories or a remote site.  Yeah, makes a lot of sense.  A light-weight window where you can store your most used pieces of code and then pull them into your project with a single click?  Yeah, got that too.  Built-in HTML validation?  Becoming more common, but still pretty slick.  Collaboration tools?  Why not.  The ability to convert one kind of line breaks to another kind.  Also very cool.  How about this … add a site and fill in all the information … the program goes out and grabs a screenshot of the website and sets it as the thumbnail for your “project” all without you doing anything more than telling it where the site sits on the Internet.  Impressive.

What does this have to do with SMS?  Not a whole lot, but it is cool because it can save me some serious time.  Right now, I have to have 2 programs open to code: an FTP client and text editor.  I have to double-click the file in the FTP client and then wait for it download to my text editor.  Then when I hit save, I have to wait for it to save it and then ship it off to the client to be published on the trunk site.  It doesn’t take that long honestly, but cutting out the middle-man makes things zip by even faster.  Despite its price tag, I think I’ll be buying a copy because this piece of software just deserves to be supported.

Recently, concerns have been raised on the support forums about the decision to drop support for Internet Explorer 6. I wanted to write something up the reasoning behind this decision. Believe me, I understand the potential repercussions that this change will have; a large chunk of the web population still uses IE 6 and SMS 2.5 won’t display correctly in IE 6, in fact, it’ll be downright ugly. So why have we decided to abandon the world’s most popular browser?

1. Stylesheet Compatability

According to Microsoft, “Internet Explorer 7 contains a number of improvements to cascading style sheet (CSS) parsing and rendering over IE6. These improvements are aimed at improving the consistency of how Internet Explorer interprets cascading style sheets as recommended by the W3C in order that developers have a reliable set of functionality on which to rely.” As any web developer knows, when you create a stylesheet, you make sure it works in something like Firefox, which it usually does without many problems, then you turn your attention to IE to fix everything else that’s been broken by your markup.  Hacks have abounded in SMS since version 1.5 just to make sure things displayed correctly.  Should developers have to bend over backwards for a browser that’s so poorly built that it just recently started being completely compliant with CSS 1, a standard that’s been out for years?  No, we don’t think so.  IE 7 attempted to fix some of those shortcomings, making life a little easier for developers.  Don’t get me wrong, IE 7 is a long way from being standards compliant, but it’s certainly closer than IE 6.  On top of that, supporting IE 6 and IE 7 simultaneously can get sticky since IE 7 doesn’t recognize IE 6 hacks and will sometimes try to render the IE 6 code along with the other code, creating conflicts for IE 7.  This clearly creates problems since we can’t predict what will happen or when it will happen.

2. PNG Images

PNG images work IE 6, so I don’t want people to think that I’m trying to say that they don’t, but what doesn’t work in IE 6 is PNG images with opacity options, also known as the alpha channel.  Firefox began supporting this a while back, but developers haven’t been able to take advantage of these things until IE 7 was released when Microsoft decided to begin allowing alpha channel PNG images to be used.  Why use these instead of GIFs and/or JPGs?  Sure, with a GIF you can get a transparent background, but GIF images require a matte around the outside of the image.  So if a skinner wants to create a background color different from the matte of the GIF image, there are immediately issues with showing that matte.  On top of that, GIF quality is significantly lower than JPG, however, JPG doesn’t allow for transparent backgrounds.  PNGs do.  Not only that, but PNGs allow for images to actually be semi-transparent and blend into the background seamlessly, plus, no matte required.  Skinners will love this change since they won’t have to touch any of the global icons that are used throughout SMS.  How does IE 6 handle alpha channel PNGs?  Usually it’ll stick a color in the background, and you can be sure it won’t be the color of your background.  In my experience, it’s usually a gray or blueish color.  It’s ugly to say the least.  I’ve experimented with advanced browser detection, but detecting versions can be tough, plus, more and more these days users are spoofing their user agent, causing even more problems.

3. The Next Generation

The fact is that Microsoft is shifting their focus in web browsers toward IE 7 and in a few years, IE 6 will reach the end of its support cycle.  Rumors from within Redmond say that Microsoft is already working on IE 8 to bring even greater CSS support.  The release may be a year or two out, but it means that Microsoft is dedicated to fixing the errors that have plagued IE for so many years.  You can rest assured that once IE 8 is released, IE 6 will be a thing of the past.  Some may think we’re jumping the gun, but if you were to sit down and chart how much time is spent correcting for IE issues, you’d be amazing.  Whole chunks of the stylesheets are hacks to make things work right in IE 6.  Why should we, as developers, have to spend so much time making something work in a broken product?  Would you drive a car that randomly put itself into reverse and started going the opposite direction you wanted to?  Absolutely not, you’d take it back to the dealership and demand another car.  Would you use a lawn mower that only cut half of your lawn when you were using it?  No, you wouldn’t.  So why should we be bending over backwards for something that doesn’t work?  We don’t think we should.

Believe me, I know there are people who will have nasty things to say about this and how we’re alienating users because of this move, but that’s a risk we’re willing to take.  Users have the option of upgrading to IE 7 or even download and use Firefox 2.  If they choose not to do that, that’s their problem, not ours.  It’s a hardline stance, but one we probably should’ve taken months ago.