In my third of three related postings on some core programming principles, I’ll be talking about unit testing.  In the first part, we discussed code reuse, and in the second, I went over version control.

Unit testing is a methodology by which you run tests on individual bits of your programming code.  I have to admit that this is the topic of the three with which I am the least familiar.  The concept of “testing” in my past jobs has largely been comprised of this:

• Write your program
• Test it out as thoroughly as you can when done
• Turn it over to a user for them to test thoroughly.

This is actually a very broad generalization, and I would, in fact, test out bits of code that I wrote as I wrote them, making sure that functions returned the desired results before I was anywhere near to having a final product.  While this is a step in the right direction towards unit testing, it is no means formal unit testing.

Ideally, you would want an easily replicable suite of unit tests that you can run at any point in the lifetime of your project to see that the various parts of your code work and return the desired results. There are many tools available now that can automate your unit testing; after making a change to your code base, you can run your unit test tool and see if you accidentally broke anything.

The benefits of this should be obvious – you can find errors in your code MUCH sooner than by completing your program and then testing it out.  Unit testing involves a lot of additional work beyond just writing a program (you need to keep your tests up to date, also), but the end result should be that you are much more confident in your program being error-free.

An extension of this concept is test-driven development.  You design your tests around a theoretical programming unit first, and then you write the program unit to pass your tests.  This is an area into which I’ve been doing some research, and I plan to try out this programming technique in my next major project.  Just like with version control, I’m eager to hear others’ experiences with unit testing so that I can learn from you, too!

To conclude this brief series on some very important programming principles, I’ll mention that studying and learning new programming techniques is a very important methodology, as well.  No one starts their programming career knowing every best practice there is to know, and keeping abreast of the latest programming methodologies is one of the best ways to ensure your success in the field.

In my last posting, I talked about the benefits of code reuse and how any good programmer should swear by that coding principle.  Today, I move on to another key programming methodology, that of version control.

Version control (revision control, source control, or any of a number of other similar names) is a method for archiving and documenting changes to programming code, web pages, XML files, and, frankly, any other type of file of which you might want to store multiple versions in one centralized location.  A benefit of this is that multiple programmers can work on the same code base without interfering with each other, and that you can easily track or back out changes to a file and go back to an earlier version, should a new change cause problems.

This is something that has been hit or miss at the jobs I’ve worked at.  My first position at a larger software vendor company had a version control system for their main programming code base, but any custom tweaking that we did for clients was not included.  The smaller organizations that I’ve worked at since then haven’t had an official version control process either.  So, this is always something that I’ve been clamoring for, but I don’t have years of experience with it to list out my own version control best practices.

I’ve resorted to tactics like manually backing up my code to a new folder for each change, to installing the single-user version of Perforce onto my computer.  Neither of these would work in a large team setting, though in my recent jobs, where I worked on applications largely on my own, they sufficed.  Using Perforce on your own, however, is a terrific solution if you are a single-person company.

Getting back to the core concept of version control, it’s absolutely necessary to avoid situations where a change adversely affects an application and you need to back it out.  If you can’t readily restore to an old version of your application in case of emergency, then you better start working on setting up such a system.  The idea of Disaster Recovery in IT departments usually refers to how to get your organization back up and running should the worst happens, but version control is very much a disaster recovery system in itself.

Here are some of the more common software packages for version control, if you’d like to learn more:

• CVS
• Git
• Perforce
• Subversion
• Visual Studio Team Foundation Server

Feel free to share your experiences working with or implementing various version control solutions.  I’d love to hear about them.  Coming up next: unit testing!

In the more than a decade that I’ve been programming, I’ve found that there are three programming principles that I really wish were included in the computer science program that I enrolled in during the late 1990s:

• Code reuse (the DRY principle)
• Implementing version control
• Unit testing your code

There’s really no excuse for these topics not being covered, but it perhaps reflects upon how the academic world differs from the professional business world.  Academia considers you successful if you’ve studied all sorts of general aspects of computer science, while success in the business world requires following general coding principles, and not necessarily a grasping a thorough understanding of say, machine code or Artificial Intelligence (of course, my argument falls apart if you are designing computer processors, robotics, or video games!).

Covering all three topics in one article would be a bit much, so I’m going to split this up over the course of a few days.

Code reuse

My biggest programming pet peeve is when my fellow programmers don’t write code that is reusable, or worse yet, “reuse” their code by copying and pasting it into a multitude of different program files.  As a developer, you ideally shouldn’t write the same bit of code twice, which is known as the DRY principle (or Don’t Repeat Yourself).  As soon as you find yourself writing one or more lines of code that resemble something you already wrote, you should evaluate it for use in a function or utility class.  That way, if you need to make a change to your repeated logic, you only have to do it in one place, and the various places in your code where you reference it should all automatically work the same way.

One of my fellow programmers is absolutely notorious for copying and pasting code.  I’ve had to drastically refactor a few of his web applications, because he had copied and pasted the same script and HTML outline into numerous files.  His worst offending application had 30 files containing much of the same code in each!  It took me several weeks of cleaning it up just to get it into an easily maintainable shape – and I hadn’t even gotten to adding any of the new requested functionality that I was supposed to be working on by that point!

I probably don’t need to mention that I had thoughts of poking him with sharp pointy objects if I ever ran into him again.  After refactoring his code, it felt good looking at the result and knowing that I now only needed to make a change in one place to affect all the files at the same time, but to the end user, there was no difference in the application and I wasn’t helping to make it do “cool” new stuff.  If you develop your code the right from from the beginning, you can get at that “cool stuff” that much sooner.

Later in the week: we discuss version control and then unit testing!  Stay tuned!

While doing some research into one of the more recently hyped techs-of-the-moment, node.js, I came across this quote from debuggable:

“Another reason is JavaScript. You can use node to share code between the browser and your backend. JavaScript is also on its way to become a really universal language. No matter if you did python, ruby, java, php, … in the past, you’ve probably picked up some JS along the way, right?”

I’m not sure that’s a very compelling reason on its own to use node.js, but the author’s point is that most people know some JavaScript, so if you wish to use an evented programming framework, node.js is a wiser choice over, say, Ruby’s EventMachine, assuming you are more familiar with JavaScript than Ruby.

Regardless, I was fascinated by the part of the quote above that mentions how JavaScript is on its way to becoming a universal programming language.  There are lots of similarities between programming languages and spoken languages, with my personal favorite being how after you’ve picked up at least two languages, you can pick up virtually any after that very easily.

If JavaScript is indeed becoming the “universal” programming language, then it very well may be the programming version of the English spoken language.  Let’s see what I mean:

• Both can be tricky to pick up at first.  I’d actually argue that JavaScript is actually less tricky to pick up, but that might be because I learned quite a few other languages first.
• JavaScript is a bit loose in its rules and doesn’t require well-formed syntax.  You can write a program in JavaScript that looks horrendous, but most programmers could probably generally follow what you mean.  Similarly, the English language lets you mix up the parts of a sentence is so many different ways that new speakers might say or write something that seems odd but understandable to native speakers.
• English has become a universal language among scientists, professors, highly ranked politicians, etc., not because it’s a superb and easy language, but rather because the old British Empire and, later on, the United States’ cultural influence spread around the world.  The world at large is now stuck with a tricky language as its common tongue.  In the world of programming, web development has been gaining steam for years, replacing a lot of desktop development.  The “cultural influence” of our web browsers, where JavaScript is the main scripting language supported, appears to be making JavaScript the language “spoken” by the masses of programmers out there.  Like English, it too is often derided for not being a great language.

There are probably many more similarities that I don’t have listed.  What does this all mean?  Perhaps linguists can learn something from computer programming, and vice-versa.  I’d definitely be interested in studies looking further into this.

This gave me a good chuckle — I ran into this recently on the old systems I still work on (yes, this comes from a terminal session!):

          Transaction Editing Database
              Charge Batch Proof

THIS ACTIVITY PROVIDES DETAIL VOUCHER INFORMATION BY
SELECTED BATCH NUMBER(S).

     HOW DO YOU WANT YOUR BATCH PROOF SORTED
               A. BY NUMBER
               B. BY PATIENT

          PLEASE SELECT A OR B : B

Sorry this portion of the program is being fixed !!!

Please selection A from the option menu.

Thank you for using the TE Batch Proof System

In short, I selected option B, only to be presented with the last three lines above.  This program first apologizes that B is not a working option and is currently being fixed (which is news to me – the last time I can tell that any programmer did any significant work to it was 10 years ago).  Then, it directs me to option A (why even bother listing an option B in the first place?).  And then perhaps my favorite part, it thanks me for using this system, apparently not realizing that it neglected to produce any useful output for me.

So, apparently, what we can learn from this is that if you don’t plan to eventually finish your program, at least make it sound like a pleasant convenience store worker.

I’m so chalk full of email pointers that I thought that I’d share some more. Incidentally, not all of these are as relatable to the new forms of internet communication as my last list (e.g., the idea of “read receipts” doesn’t quite make sense in something like Facebook… though they might surprise me one day with another one of their privacy-challenged new features). And so, here’s another list of email DON’Ts:

• Attaching huge files. Extremely large attachments can slow down a person’s email program and make the user think the program or internet connection is busted. This isn’t quite true with web-based email clients, though depending on the person’s email service, you still are risking maxing out their storage limit. Consider using an online service for sharing documents with others (publicly or privately), like Microsoft’s SkyDrive service or Google Docs.
• Really long emails with no summary of the talking points. I mentioned last time about avoiding really long emails. If you absolutely insist on doing that, at least provide a brief summary of your points at the start of your email (concise bullet points are good attention getters). There’s a good chance the recipient will nod off in the middle of the email, so if you hammer home your main points at the beginning, there’s a somewhat decent chance the person will understand your main ideas and hang on until the end. But again, it’s a really bad idea to start a new email conversation with an enormous email message. You’ll lose the recipient’s attention span before you even had it.
• Replying to an email and just saying “Thanks!” This one is debatable, and some people actually might like receiving one word emails of appreciation, but there’s quite a few others that can’t stand them. At the very least, don’t press the Reply All button and send a one-word reply and end up copying everyone and their brother on your email. If you do want to tell someone thanks, consider making it a full sentence such as, “Thank you very much, I really needed someone to help with that!”

And lastly, perhaps two of my biggest pet peeves, the kind that make me want to pull out my hair or jam pens into my eyes:

• Using read receipts. There was perhaps once a good use for these, back in the day when email wasn’t so ubiquitous and spam was hardly a glimmer in the eye of the con artists, asshole advertisers, and “adult entertainers” of the world. Now, however, they are seen as a major annoyance and a sign that you don’t trust the other recipient to respond to your message. Plus, since programs like Outlook let you turn off the sending of read receipts and some email clients don’t even support the concept of them, is there really any guaranteed use for them anymore?
  

  Just say NO to read receipts!

• Using email ‘stationary’ for the background of your message. I don’t think I’ve ever seen one used tastefully. If I wanted a gaudy picture of some flowery decorative scheme, I’d go visit an art fair. Using a lined sheet of paper design for the background of your message doesn’t make your email any more readable or memorable. In fact, I’m more than likely going to remember how badly I scowled at the appearance of your message rather than recall what your actual content really was. Thankfully, this tends to be more of a problem that’s internal to organizations that enforce a standard email program, as email stationary usually doesn’t translate well across differing email clients. However, it’s just as annoying to receive an email with stationary in a program that differs from the sender: the message in your inbox will more likely than not have an attachment indication, and if curiosity gets the better of you, you will open the attachment… only to be annoyed to find a gaudy picture of flowers or a virtual sheet of paper. Of course, I shouldn’t have to remind you of the danger of email attachments and how they can contain all sorts of nasty stuff that can infect your computer, so you should only open them when you’re expecting one.
  

  Tacky-looking nature images do NOT lend a professional look to your email

My last few posts have been very instructional and aimed at a very specific audience, so let’s take a look at something from which we all could benefit. Being that it’s Friday and a beautiful day outside (hopefully your weather is gorgeous, too), let’s all roll up our sleeves, unbutton that top button, and enjoy a topic that’s both obvious and often overlooked at the same time. It’s time… to talk about email etiquette.

It’s a method of communication that many people say is dying, though that “many” does not seem to encompass a single person at the organization where I work, where emails fly back and forth like migratory birds confused by climate change. At my job, email exchanges are the norm for project communication, problem reporting, questions, and yes, even those most important messages of the day, what to do for lunch. While other methods of electronic communication are becoming more and more prevalent, be it texting, Twittering, Waving, etc., email is in no danger of going away just yet, which is why it’s always a good idea to review the following points from time to time. These points also have relevance in the new forms of communication, so they are definitely worth noting.

Speaking of texting, I can’t wait to see how the kids of today, who are quite adept at going over their monthly text message plan using less words than I’ve written in the above paragraph, manage communication in their careers in about 10-15 years. I’d bet it’s a popular topic of language arts grad students’ dissertations. But I digress.

Here are some email best practices in the workplace that I’ve noted over the years.  Follow these, and you almost assuredly won’t be secretly hated by those sitting around you… assuming you follow good hygiene, too.

• Keep your messages as concise as possible. Long emails tend to put off the receiver, who may start to despise you and curse your unborn children before he or she even begins to read your message. If you must, save additional talking points or questions for a follow-up email after you’ve gotten the receiver’s attention. Include just your most important point or question in the beginning.
• Unless your forwarding pictures of talking cats to your fellow coworkers, include a full email signature in at least the very first message you send or to which you reply. Important email conversations have a way of taking on a life of their own and getting forwarded to others later on. However, after a message has had a few responses, many email programs only show the name but not the email address of past recipients (I’m looking at you, Outlook!). So, if your message is one of the first in the email chain and one of the later recipients wants to get a hold of you, you can save him or her a lot of time by including a signature containing your email address or phone number so that they know how to to contact you. Oh, and if you are forwarding pictures of talking cats to your coworkers, there’s a good chance they are starting to despise you and curse your unborn children.
• Be selective of who you CC: on your emails. Back when I was fresh out of college, I had a bit of a rabble-rouser in me. I sent an email to our managers and copied my entire department about how our support issues weren’t being fairly distributed amongst our various regions, acknowledging our unspoken common frustration. The shared frustration became clear as I nearly caused an uprising among the ranks, something for which I got scolded. Our managers had no problem with me bringing up the issue, though I should have brought it up just with them and not copied everyone else. Without working out a solution to the problem with them first, I should have thought twice about copying everyone in our area on my message.
• 

  Careful with this button!

  Be very careful with the Reply All button. Only use it when everyone on the original email needs to see your response. One of my most memorable work memories is the follow-up to the above story. Even worse than my action, one of my fellow teammates sent me an enthusiastic follow-up email stating, “You go, Derek!”. Only, she too copied everyone in the department. Accidentally. Her scolding was worse than mine.

• Know your audience and keep your message professional where necessary. If you are contacting for the first time a senior manager from a different department or even a new client, don’t add a smiley face to your email. And for heaven sakes, watch your exclamation points (“Thanks!!!!!!!!!” actually appears to be part of the email signature of one individual I hear from a lot). Repeated punctuation is not very becoming of a professional email — this especially includes “???”.
• Perhaps most importantly, use the phone once in awhile. Every little question you have for someone doesn’t have to be done over email. You might actually save the other person some time in the process too, and make the world a happier place as a result.

If you have additional email tips that you’d love to share, let us know in the comments!

If you were with us last time, we were discussing the numbering of a product called Studio Enterprise by Component One.  I raised some concerns about their versioning scheme, stating that it likely would raise lots of confusion among their userbase.  This time, I’d like to focus on a splash page on their site that is advertising this product.  Again, let me make the disclaimer that I am not reviewing the product itself or making any claims about it being good or bad.  I’m simply using the advertising on their site as a lesson in web design.

Since there’s a good chance the page will eventually come down or change (as it is, after all, advertising a product labeled “2009″, and the last time I checked, we were well into the year 2010), here is a small screenshot of the splash page in question (if this link does eventually kick the metaphorical bucket, just imagine this image blown up to 960 pixels wide and 1050 pixels tall):

The splash page advertising Studio Enterprise 2009 v3.

Artistically, it’s kind of cool and employs a 1950s retro sci-fi vibe.  Whether that helps or hurts the product is up for debate, though. The programmers that ultimately would be the end users of this tool might really dig it (after all, what programmer doesn’t have a little geek in them?), though Mr. or Mrs. Senior Executive that ultimately pays the bills might be discouraged and instead keep looking for something that has that certain “professional IT” look to it.

Regardless, implementing a splash page like this can be bad for several reasons:

• They can take a long time to load.
• Some may only slightly resemble an actual web page, and users may be confused or discouraged when clicking in certain places on the screen does not result in the expected behavior.
• They aren’t as accessible as a proper web page, and people with certain disabilities may not be able to use/read the screen.
• They take the page’s content out of the underlying HTML, which searches engines may not understand (Flash content has historically had a similar problem).

Let’s go through each point in depth.

Page load time

Splash pages can often take a long time to load, and when a page takes longer than a few seconds to display, your potential readers, users, and/or customers are very likely bolting for the virtual door and heading to a different site.  Let’s look at Component One’s splash page advertising Studio Enterprise.  On my fast broadband connection at home, it took a good 8 seconds to fully load!  That is way longer than what a good page should take.  A big bulk of your potential site viewers won’t stick around past the 4-5 second mark.  While it’s a few years old, Akamai has an interesting article on how this affects online shoppers.

To Component One’s credit, their splash page is divided into two main images that can be downloaded simultaneously to cut down the load time. I hesitate to think how small the percentage of potential customers would stick around if it was just a single huge image! There’s still a problem, however — each image averages over 750KB in size!  That’s a nearly 1.5 MB download just to see an ad on a page, which is pretty darn insane.

Both images are PNG files, and each one appears to be saved as a high quality 32-bit image. Re-saving the images as 8-bit using the free Paint.NET utility, I was able to cut the images down to under 25% of their original size.  You lose some of the sharpness of the original image, but when your intent is to entice a custom to click on the image right away and come into your site, who is going to stick around long enough to enjoy the quality of artwork in your ad?  Certainly not the web surfers that have already left and gone on to a different site.

Splash page interaction

When a splash page is set up like Component One’s, they often lose any semblance of an interactive web page.  In the case of their ad, the images that are used to make up the page contain what look like clickable buttons:

In fact, if you hover over them, the mouse cursor turns into a hand which gives the appearance that they are indeed clickable. However, upon closer inspection, each of the two images making up the page are entirely clickable!

Rather cleverly, they’ve placed the “buttons” in the above picture right along the middle of the page, which is the dividing point of the images.  “Download free trial” falls just above the border of the two images, and “Learn more” falls just under it. As it turns out, each image is actually a link to a specific page on their site.  Not surprisingly, clicking on the top half of the page takes you to a download page, and clicking on the bottom half of the page takes you to a Studio Enterprise overview page.

So how is this bad when the “links” basically work?  For starters, modern web design conventions are being ignored.  Hovering over the “buttons” doesn’t change the color or style of the buttons to indicate that you should click on them.  There’s other text on the page too:

The text at the bottom of the ad

Why don’t these words have their own context-specific links? As a user, I might assume that clicking on “scheduling” will take me to the overview of a scheduling product, and when I see that this is not the case, I may move on to another site.

Accessibility

Can blind web users that utilize screen readers make sense of the page?  There’s no alt text set up for the images on the page for such a user to know what they are viewing. The “buttons” mentioned above are in no way identifiable to such a user.

Content

Building upon accessibility, Component One’s splash page inextricably mixes the content on the page with its style. There’s no way to easily update the look of it without needing to change the entirety of the content.  Now, given that the content is simply an ad for a product that will probably be replaced by a new version (and thus a new ad) in the near future, Component One probably didn’t give this issue much thought.  In fact, I’d agree that in their situation, this really isn’t that big a of a problem.

For other sites that have a permanent splash page, though, presenting the content in this way makes for a real maintenance challenge, should the site owner ever want to update the look of the page.  You either do a complete redesign, or you do nothing at all.

Conclusion

If you’re thinking you want a splash page to be the first thing a visitor sees when entering your site, then you have to carefully weight the pros and cons of doing so.  A carefully designed page should pass the above tests and not discourage potential visitors.  However, in Component One’s case, their splash page is likely turning away more potential customers than it’s luring.

Inadvertently, I recently came across a software product that seemed rather odd to me.  It, in turn, also led me to a web site that I thought would work great for a quick web design lesson, but we’ll get to in my next posting.

Before I delve into what struck me as odd regarding this software, though, let me first point out that I in no way endorse this product, nor am I implying that it’s bad.  Frankly, I don’t have a use for it and don’t plan to test it out. In fact, it may actually be the best thing since Windows XP/Windows 7/Mac OS X (circle one).  That’s none of my concern, and I want to make it clear up front that this is not a review or critique of the actual software being discussed. In fact, I’m actually going to be focusing more on the advertising of said product.

So, what exactly is it that caught my eye?  I was looking at a page on Stack Overflow and noticed this ad at the top of the page:

The noteworthy ad

Now, my brain has gotten pretty good at filtering out ads on web pages.  I would guess many, if not most, people are getting good at that game based on how advertisers keep trying to up the ante in how dramatic they can make their online ads.  I usually don’t stop and do a double-take when my eyes scan past an ad embedded on a page. However, this one caught my eye for a couple reasons:

• Due to its coloring, logo on the left, and font used, the ad looked like it was for Microsoft’s Visual Studio, but for a version that I wasn’t familiar.  Visual Studio “Enterprise?”  Knowing that version 2010 is about to be dropped into the world and is replacing version 2008, I was surprised by its versioning also: “2009??”
• Realizing that this wasn’t actually a Microsoft product but one from a company called Component One, the next odd thing that I noticed was that it was essentially marketing itself as version 2009 version 3.  …Wait, what???

I have to admit that my curiosity was really piqued now.  Who versions their software twice?  Was this really the third major version of this software released in 2009, and do they restart their numbering each year?  Has Component One named their product “Studio Enterprise 2009″ for the last several years, patiently waiting for a larger company to gobble them up and force them to change their software’s name, all to avoid the paperwork headache of patenting a new version?

Actually, I can think of one example software product that’s near and dear to me that did something arguably similar: a healthcare solution that I’ve used time and time again and is now part of GE Healthcare’s stable of products. It was suddenly renumbered after years of each version simply being one number higher than the last.  In the middle of the release of version 9, however, it was retroactively renumbered as version 2.  The reason?  The vendor was trying to change its platform emphasis and decided to make the second version of its newer web-based product its flagship platform.  It’s older terminal-based solution (then up to version 9) wasn’t being phased out, per se, but it was kind of getting swept under the rug.

So, it was decided that their entire product line would be renumbered to 2.0.  While they weren’t advertising this using Component One’s numbering model as “version 10 version 2,” it was known internally amongst the vendor’s employees and to their older clients as version 10, and externally, it was advertised as version 2.  This, as you can imagine, led to all sorts of confusion.  Granted, the end users that relied on this software didn’t care if it was version 10.0, version 3.14159 or version Purple, as long as they were able to get their work done.  But for our managers and support staff that dealt directly with the vendor, it certainly was confusing when we would be in dealings for a new version, or if we received a notification about an emergency update for a specific version that we may or may not have had.

Let’s jump back to my new obsession, Studio Enterprise 2009 v3.  Curiosity got the best of me, and I had to click on their link to see what the deal with their software was. I was brought to a rather annoying splash page, an element of web design that I plan to cover next. I had to go digging through their site a bit, but I finally came across this page which had their versioning history:

The list of releases of Studio Enterprise

Much to my surprise, they actually do start over with their numbering each year! Again, not being familiar with their product or the vendor, I can’t say what their users think of this, but I can imagine that confusion occasionally sets in.  Imagine two users, one with 2008 v3 and the other with 2009 v2, having a conversation about this software:

User 1: “What do you think of this terrific software from Component One?”
User 2: “I love it!  Especially for feature ABC!”
User 1: “ABC?  I don’t think we have that feature… what version are you running?”
User 2: “Version 2.”
User 1: “Version 2?  Hmm… we have version 3.  They must have taken that feature out of the program.  In fact, if you like it that much, you may want to consider not upgrading again!”

Both users are confused and don’t realize that each has a different year of the program, and the result is possibly a lost sale for the vendor.

So, what could Component One do differently for future versions of their software?  Let’s quickly go over two of the most general guidelines on how to do software versioning:

• Each major release should be a new whole number or year. Examples: Firefox 2 and 3, and MS Office 2007 and 2010.  This very often coincides with a complete rewrite of the application’s underlying programming code.  For software that is not free, these are the upgrades you pay for.
• A minor update to a major release adding new features should be a point release (e.g., Firefox 3.5) or possibly, in Microsoft’s terminology, a service pack (e.g., Windows XP SP3).  Usually free, vendors sometimes charge for these (such as Apple with its operating system upgrades).

Beyond that, you often see an additional number, e.g., the “.8″ in Firefox 3.5.8, that represents minor fixes in the product.  I won’t go further into that, though, as things get less standard at that numbering level, plus I couldn’t do a better job of summing up the entire scope of version numbering than the article on Wikipedia.

Instead of numbering their product with a year and then a “v2″ or “v3″, Component One would probably be better off going with a dot numbering after their year, like what Intersystems does with its Cache database product.  For instance, instead of 2009 version 1, they should just label it 2009.1 or even just plain old 2009 with no additional number trailing it.  2009 version 2 then becomes 2009.2, and so on.  How does this help the customer?  They immediately know if the product they have installed is older or newer than a differing version, and for prospective customers, they will have the confidence that “2009.1″ is a product with an established codebase, compared to something simply labeled “2009 version 1.”

Coming next: a dissection of the splash page advertising Studio Enterprise 2009 that leads you into their site!

You may want to catch up on my initial rounded corner discussion before reading this.

If you remember, we left off with a nice-looking tab design for use on a web page:

There are still several flaws with this that I’d like to fix.  To recap:

• There is no doctype defined for the page, so the page is being rendering in quirks mode.
• We’re using a table layout for the tab design, which is a no-no, being that we’re not actually dealing with a table of data.

So, let’s fix the first problem right away.  I’m going to declare that my web page is 4.01 strict by inserting this at the very top of the document:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Let’s see if this affected our tab design at all.  When viewed through Internet Explorer 7 (which, like I pointed out last time, I’m using since it’s the browser my company’s users have to use), it looks like this:

View of the tab design in IE after adding a doctype

Not bad – it still looks the same!  Let’s see what it looks like in Firefox, since it’s always a good idea to see what your web designs look like in as many browsers as possible:

The same exact tab design with the doctype set, as viewed in Firefox

Woah!  Our tab has grown a little hat!  Definitely not good.  As seen in Firefox, our tab design is getting rendered differently now when the doctype is clearly defined. No problem, we’re going to get rid of the table layout anyway.  The idea is to use SPANs and DIVs instead — spans are generally for styling inline page elements (text and other HTML that is meant to be displayed on one line without any line breaks) and DIVs are generally for styling block page elements (sections of your page where you want a line-break after them).

As a side note, you may also be asking why I’m concerned about Firefox when I said in my last post that we force our users to use Internet Explorer.  While true, you never know what we may make them use in the future, so making my HTML as clean and valid as possible now ensures that it should keep on working in the future, no matter what browser we end up using.

Back to SPANs and DIVs — here’s the general idea of what I want:

<span class="tab">
    <img src="images/left.png">Tab<img src="images/right.png">
</span>

It’s fairly simple: I’m simply surrounding the name of my tab (“Tab”) with my rounded corner images and putting it all in an inline grouping element (the SPAN tag).  Let’s give it some basic styling for color and add a basic DIV block afterwards to act as a placeholder for the content that will eventually be associated with this tab:

<style type="text/css">
span.tab {
    background-color:#faa344;
    color: #ffffff;
    font-weight: bold;
}
div.tab_content {
    border: 0.1em solid #faa344;
    padding: .5em .5em .5em .5em;
}
</style>
.
.
.
<span class="tab">
    <img src="images/left.png">Tab<img src="images/right.png">
</span>
<div class="tab_content">
    Tab content
</div>

This ends up looking like this in Internet Explorer:

The tab done as a basic SPAN design

Interestingly, the little “hat” is now present in IE, though it’s simply because our rounded corner images are hovering in the center of the SPAN, rather than being aligned to the top edge of the SPAN.  One way to correct this is to float the images, which will align them to the top edge of the container they are in (meaning, in our case, the SPAN tag).  Let’s see what happens when we add a new style to our code to float the images:

span.tab img {
    float:left;
}

This results in this in our browser:

Tab with floated images in IE

Tab with floated images in Firefox

This was about as expected as the Spanish Inquisition!  Where did our rounded edges go?  In fact, they’re still there, but IE7 and Firefox handle floats slightly differently.  Allow me to highlight our tab design to show where they went, since they’re hard to see considering they are colored white and are currently lying against a white background:

Highlighting the tab design in IE

Highlighting the tab design in Firefox

Interestingly, IE inserts a line break between the floated images, as it sees a non-floated element between them, whereas Firefox does not. More importantly, though, neither browser is actually containing the floated images in the SPAN element itself.  The solution?  Float the SPAN, too! If a parent element (in our case, the SPAN tag) is floated, then it will contain any floated children elements (in our case, the images).  So, let’s edit our “span.tab” style to include a float setting:

span.tab {
    background-color:#faa344;
    color: #ffffff;
    font-weight: bold;
    float:left;
}

This looks like this:

The results of floating the SPAN in IE

The results of floating the SPAN in Firefox

The good news?  Our rounded corner images are now back in the SPAN element!  The bad news?  There’s actually two bits of it:

• The tab name is to the right of what we want to be the right corner image, which makes the tab design look… odd.
• The entire SPAN is now sitting in the DIV element, due to how it’s floating on its own.

Our floating images aren’t playing well with the plain text tab name, so what should we do?  Put the tab name in its own floating element, too! Let’s wrap it in its own floating SPAN. Here’s a new style I’m adding, followed by the revised tab design:

span.tab_label {
    float:left;
}

<span class="tab">
    <img src="images/left.png">
    <span class="tab_label">Tab</span>
    <img src="images/right.png">
</span>

As for the SPAN running into the DIV, this can be cleared up by setting the clear CSS option for the DIV:

div.tab_content {
    border: 0.1em solid #faa344;
    padding: .5em .5em .5em .5em;
    clear:both;
}

Let’s see what this gives us:

The tab design in IE with 'clear:both' in the following DIV

The tab design in Firefox with 'clear:both' in the following DIV

Wow!  This is terrific — we have the same general tab design that we originally started with, but we have it set up in a better designed approach that should look good in future browsers.  In fact, I’d like to see the tab be a bit more prominent, so I’m going to tweak the padding in the SPAN element that surrounds the tab name (the one labeled “tab_label”).  Here’s my final styling and HTML:

<style type="text/css">
span.tab {
    background-color:#faa344;
    color: #ffffff;
    font-weight: bold;
    float:left;
}
span.tab img {
    float:left;
}
span.tab_label {
    float:left;
    padding: .3em .3em .3em .3em;
}
div.tab_content {
    border: 0.1em solid #faa344;
    padding: .5em .5em .5em .5em;
    clear:both;
}
</style>
.
.
.
<span class="tab">
    <img src="images/left.png">
    <span class="tab_label">Tab</span>
    <img src="images/right.png">
</span>
<div class="tab_content">
    Tab content
</div>

Here’s the end result, as seen in both browsers:

Our final tab design, as seen in IE

Our final tab design, as seen in Firefox