It was the first conference I’ve ever been to; I have to say, I can definitely see what all the fuss is about. I’ve already started following several new and interesting people on the twitter. I met so many cool and smart and nice people this weekend, and just got a chance to talk with people who want to share what they know. Even being part of the event staff, I got to see plenty of really good talks, and I learned so much.

Before last weekend, I was pretty dismal. I wasn’t really excited about web development anymore, in my mind, ColdFusion was a dead, bloated, washed up corpse of a former lover, being pecked at by sea gulls, and Flex was about as far from my mind as it could be. This conference completely re-energized me and gave me a new sense of motivation and a fresh new batch of ideas to go explore. It could not have come at a better time. I feel so excited and motivated about working with ColdFusion and Flex again.

And that is just about attending the conference. It was pretty awesome being able to work with really great people, especially the two really cool guys who shouldered a large portion of the responsibility. I can’t believe we actually did it. I can still remember our user group meeting back in the spring when Dan said he wanted to put on a conference. Nothing major, just a one day affair for locals of the Triangle Area, maybe people from Charlotte or even Asheville. Somehow, over the course of a summer it turned into a full-fledged, free, two day, international event with people coming from New York, California and Canada and a full list of well-known speakers. We kind of just did it as we went along, and some it was really done by the seat of our pants, but due to the hard work and determination of everyone involved, it turned out pretty okeydokey.

I think most of the people involved feel the same way: Last night, we had our debriefing/postmortem of the conference, at the beginning of the meeting, we cautiously approached the subject with the attitude of we may do this again next year, but let’s not commit. By the end of the meeting, when asked who would want to do it again, everyone in the room raised their hands. So without letting too much more out of the bag, it looks like there will definitely be another CFinNC conference next year and I’ll be  happy to work to make it better than this year’s.

Smashing Magazine answered that question succinctly and correctly (back in July of 2008, I might add): No. They shouldn’t. It’s as simple as that*. You should let your uses decide how to handle their links. When you force users to open a link in a new window against their will, it destroys their web experience for a few reasons:

• It removes control from the user in favor of control of the developer, and users should always be in control of their experience
• It forces the user to use the site in a way you’re dictating, which is usually not the way the user wants to use the site
• It removes use of the back button, an integral part of the web experience, even today with all of our AJAXy goodness
• To novice users, it’s confusing: where did my back button go, what just happened?
• To experienced users, it’s downright enraging: thank you, I know how to open links in a new tab or window, I don’t need your help telling me how to browse the web. In fact, I’m going to close your stupid site right now, just to spite you and your stupid ideas.
  
• It doesn’t do what it’s supposed to (keep users on your site): If a user wants to leave, opening a link in a new window won’t get them to stay. Giving them what they want (good content, good user experience) will, however.
• It destroys the very thin veneer that we’re in control of at least something in our existence, often leading to very severe existential crises in which a person’s entire reality might be shattered, leading to unintended consequences including but not limited to: psychosis, rage, murderous rampages, and losing touch with reality

*Of course, there are caveats. I would say that you should force the link to open in a new window or tab only when opening the link in the current window will interrupt the flow of the user experience. What does that even mean? I don’t know. Nah, but seriously, for example: let’s say a user is using your site to buy a vintage harpsichord, and he’s on the last step of the buying process: checking out. He’s found the perfect harpsichord to put in his basement, he’s entered his shipping and payment information, but he has a question about shipping. So he clicks the link that looks like it can answer his questions, and he’s taken away from his shopping cart. Crap, he’s thinking, now what? Do I have to re enter all my information? Do I have to start the whole process over? This is a perfect opportunity to open the link in a new, small window positioned right next to the link.

Smashing and webcredible provide a good cross section of times when you should open links in a new window:

• The link provides assistance, as in the example above
• The link will interrupt an ongoing process, again, see example above
• The link leads to a non-html document, like a PDF, mp3, or movie file
• The link leads to content that will take a long time to load, like a large image, or javascript heavy web page
• The link leads to a printable version of the current web page, although this can be mitigated by using a print stylesheet

Keep in mind however, that even if you do have a situation where it is appropriate to open a link in a new window, you should always inform the user that the link opens in a new window, either via the title attribute of the anchor element, or by specifying in the link text that the link opens in a new window. Similarly, if you’re in a situation where you’re forced to open links in a new window, like say if you work under someone who is convinced he is a usability expert and also makes the decisions and one of those decisions is deciding that all outgoing links will open in a new window, you should try as hard as you can to inform the users that their usability experience is about to be disrupted.

Remember: it’s not 1999, web usability has grown by leaps and bounds over the past decade, and one of the things we’ve learned is that you should trust the user to be in control of their user experience.

I’ve hacked together my own WordPress template for fun and posterity to integrate into my site. See, I’m a pretty big newbie to all of this, and it didn’t help that the /blog directory under my main site actually pulls from a separate blog directory one level up (don’t ask me why I did this, I was probably drunk – in hindsight it’s pretty obviously boneheaded). Regardless, I had a suspicion that this had something to do with why the syntax highlighting wasn’t working. I did searches and couldn’t really turn up many good results. It seemed pretty obvious that most people with normal working blogs weren’t having issues.

I ended up looking at the plugin code in the WordPress plugins editor to see if there was something obvious causing it. I spent about 15 minutes looking through it when I figured that there was some kind of issue resolving the directory/URL structure between where the blog was being included and where it was actually located. I found the following code:

// Initalize the plugin by registering the hooks
 function __construct() {
 // Check WordPress version
 if ( !function_exists( 'plugins_url' ) ) return;

 // Load localization domain
 load_plugin_textdomain( 'syntaxhighlighter', false, '/syntaxhighlighter/localization' );

 // Register brush scripts
 wp_register_script( 'syntaxhighlighter-core',             plugins_url('syntaxhighlighter/syntaxhighlighter/scripts/shCore.js'),            array(),                         $this->agshver );
 wp_register_script( 'syntaxhighlighter-brush-as3',        plugins_url('syntaxhighlighter/syntaxhighlighter/scripts/shBrushAS3.js'),        array('syntaxhighlighter-core'), $this->agshver );

I figured it had something to do with the function

plugins_url()

not returning the correct location of the plugins directory where Syntax Highlighter is located. I figured it couldn’t resolve the location of the plugins directory and therefore couldn’t find the JavaScripts that color the code. I spent about an hour tooling around with

plugins_url()

trying to get it to work in various ways and permutations, all to no avail.

I was starting to get frustrated when I noticed, for the first time, right next to the code editor a list of plugin files to edit. One of them was titled ReadMe.txt. “What the hell,” I figured, it can’t hurt to take a look at it. I scrolled down about half way until I saw a FAQ. Right there, in the middle of the page, like a veritable bullhorn shouting, “You freaking moron!!!” at me, was my solution.

The code is just being displayed raw. It isn’t being converted into a code box or anything. What’s wrong?

The answer, of course, was to call the

wp_footer()

function in the blog’s footer. Man, did I feel like a jackass. Here I was, making things difficult, wearing my Big Boy Coder’s™ pants, trying to hack up functions and make things more complicated than they are, when all I had to do was RTFM like the noob that I am and find the function to include.

So naturally, the first thing I had to do (after fixing it) was write a post about it rife with Syntax Highlighting. Thanks, Alex Gorbatchev.

So, for the first time ever, I wrote up a stylesheet with the media type set to print. I’ve just never needed to print anything from a website before. So I wrote up a stylesheet with the media type set to print. I just set the display properties of elements I didn’t want to show to none and went about testing it. During testing, I kept running into a problem where the left column, which should have been hidden, would still be causing the center content column to float right. The navigation menu wouldn’t be there, but the container the navigation menu lived in was still there, even though its border and content were hidden. This stumped me for a good day and a half, and after hitting my head against my cubicle wall I finally decided to try setting the media type of the main stylesheet of the app to screen. This solved every problem I had and now the tables are printing beautifully.

The moral of the story: Always set the media types of your stylesheets. It’s a good idea and a good way to add semantic meaning to your header files, and also, all the cool kids are doing it these days.

So that’s about it.

This worked fine every time in Firefox 3 and IE7, but in Safari, I noticed some strange behavior: Occasionally it would work like expected, but most of the time the form would stay hidden. It seemed the only times it did work were when the actual page load took longer to load than the stylesheets and scripts.

The following image shows the Safari Web Inspector when the strange behavior was occurring:

This image shows the Web Inspector when the normal behavior was occurring:

In all of the cases where the page behaved as expected, the page would finish loading after the stylesheets and scripts. I’m not really sure what this means, but it seemed like when the strange behavior was happening, the page would load, jQuery would show the form, and then the stylesheet would load and hide the form. I spent several hours searching for an answer to no avail.

The fix came when I changed the jQuery code. Instead of using the show() method, I used the css() method to change the css property, display: block. This fixed the problem in Safari, and did not introduce any strange behaviors in Firefox or IE7.

After two days, I want to say that my new job is fantastic, thanks for asking. I’ve signed on to be a ColdFusion developer with SRA International in Durham. Again, today was only my second day, but the first two were great. Yesterday was an orientation that was presented via a teleconference call with people across the country. Today was my first real day. I have to say, I’m very impressed with how organized and employee-oriented the company is. I have a nice sized cubicle that will have a name plate on the outside wall. Inside my cubicle today was a Dell PC with a dual LCD setup, which I thought was pretty cool. Also inside my cube were a stapler, a tape dispenser, a staple remover, a magnetized paper clip holder, paper clips, staples, and tape, two pads of paper, two pens, two pencils, two stacks of post it notes a telephone directory and instructions on how to use the phone. All of the office supplies were brand new in boxes. It was incredible, and also a little exciting to see the company that hired me putting in just a little bit of effort to show that I’m welcomed. That little bit went a very long way. It’s quite exciting to be working for a company that has their act together and tries to let their employees know how they feel about them.