When the Node Knockout competition was announced several months ago, I signed up immediately; it sounded like a helluvalotta fun and lit a fire for me to learn the ins and outs of Node as quickly as possible.  I recruited a couple of my buddies and the contest slipped off my radar and out of my mind.

Days before, though, I was reminded that it was fast approaching! Long story short, I had somehow screwed up our registration, but the gracious folks running the show set up a random-team-name account at the last minute, “Zenith-Workloom“.  We set to work right away.

I was the only participant who had experience with Node, but the guys were excited to try.  We even had a few geek friends show up when we started, just to see what we were doing and how we were going to do it.

All told, I stayed up for a 36 hour period, crushing against the GitHub, Twitter, Facebook and FourSquare APIs, fussing with relative dates, wrestling with MongoDB… really a lot of work.  We found ourselves cutting back on our features list with every passing hour, desperate to get things stable before time expired. There is quite a bit to discuss here, but I’ll save that for a blog post I plan to write later this week.

The Results

In the end, we ended up exhausted with relatively solid services and 20% of our desired feature set in the front-end.  I emphasize this because there is quite a bit of code running in Node that didn’t “bubble up” to our front-end effectively… for example, I couldn’t get GitHub check-ins to sort nicely with other events before “last call”.  This is merely a side-effect of a deadline fast-approaching.

There are some amazing entries in the Node Knockout contest… I mean, incredibly awesome.  Here are a few of my favorites:

• Simulchart – http://awesometown.no.de/ – Real-time, embeddable data charting.
• Drop Note – http://done-js.no.de/ – Drop a file into your browser and share it instantly.
• Scrabb.ly – http://scrabb.ly/ – Real-time, addictive Scrabble game, (WOW!)
• CloudQ – http://nko-team-discovery-channel.heroku.com/ – Sandboxed Unit Test runner for GitHub projects.
• Serrano – http://starcraft2destroyedmymarrage.no.de/ – Share DOM events and other information with other users simultaneously.

These guys kicked our ass.  But here’s the thing that I take away: I watched folks from these teams on IRC, struggling through issues, getting help, providing it… I mean, the community was so f’ing powerful.

Halfway through I realized I was going to learn 1000% more just looking at winning teams’ source code than I was in the contest.  I got excited, and have remained so… and I’m still proud of what my team managed to accomplish, even though we’re not realistically in the running.

Along Comes John Resig

I took issue with the following tweet by Mr. Resig:

Disappointed in the entries to the Node.js Knockout; only a handful of the entries work in non-Chrome/Safari browsers.

Wow… really?  It prompted my reply:

Was jQuery coded in 2 days? RT @jresigDisappointed in the entries to the Node.js Knockout; few work in non-Chrome/Safari browsers. #nodeko

My point was fairly straightforward:  this wasn’t for production, this was for fun.  This was to test the limits of Node.js with stunning, whimsical or powerful ideas. Take away the pressure of “selling something” and just “do something”.

After some retweeting in the node.js hashtag, this reply from Mr. Resig crossed my TweetDeck:

@clintandrewhall Teams that made working, fully-functional, cross-browser applications in 48 hours deserve to win – and get my vote.

The more I’ve thought about it, the more upset his statements have made me.

In Defense of Node Knockout Teams

The Twitter medium is the worst place to debate these kinds of points; I mean, Mr. Resig certainly has more to say that 140 characters allows.  And his interpretation of a complete application is probably different than others.  But I have to take issue with his tweets on their face…

Look, my team’s entry is cross-browser compatible… but that was by the grace of a limited feature-set.  Mr. Resig was actually a judge for our entry, and leveled a very fair, honest critique of our missing features… points of view I share.  But I’m going to protest on behalf of those other teams who only supported a limited set.

There were people attempting very complicated, near-impossible feats under a very tight timeframe… and several succeeded!  For a judge to focus on the browser when the teams had been focusing on Node just seems so argumentative.

It’s one thing if the knockout had been for a week, or maybe if server code had been locked down early with additional time for front-end.  But we’re talking 48 hours here, starting from scratch.

But more importantly, Node Knockout entries are graded as follows, (from http://nodeknockout.com/judging):

Entries will be judged on a 1-5 scale across 4 dimensions:

• Utility – Is the site offering a service you’d use again and again?
• Design – How good does it look and feel to use?
• Innovation – How original is the idea and execution?
• Completeness – How “fully baked” is the site? Are there bugs or dead ends?

First, I concede that judges have every right to pet peeves, sticking points, etc… and we were told to keep the judges in mind when we were working. Still, I would hope that an entry would still be judged on its merits more so than those irritations.  And to be fair, where in the criteria above is browser compatibility even mentioned?

Perhaps “completeness” could include cross-browser compatibility… but in this context… should it?

Based on Mr. Resig’s logic from his tweet, had my team completed our feature set in our present level of compatibility, we’d have garnered a 5-star vote from him.  That’s great!  But is he saying that, of the entries I mentioned above, none deserve five star ratings simply because they don’t work in all browsers?  Is my team’s simple effort, to compile data feeds chronologically on one page, full orders of magnitude “better” than those ideas simply because our CSS happens to be cross-browser compatible?  I certainly don’t think so… my team didn’t even have JS in the front-end…

Look, I’m well-known for being a progressive-enhancement nazi, swinging the “gotta work everywhere” sword in wide archs… but I make an exception here.

This contest was about doing freakishly cool things in Node in 48 hours, not a browser.  Having participated first-hand, and seeing the absolutely amazing things that were done, I am in awe.  That’s not even to mention the inspiring, multi-continent community that was flash-created in a 48 hour period.  Even better, most teams have pledged to open source their code for all to see.

Absolutely incredible.

Yet… that someone, let alone one of the judges, would publicly minimize a team’s accomplishments by focusing on the tiniest, almost out-of-context point saddens me.

I don’t think anyone should be “disappointed” by these entries.

Go Explore and Vote

I encourage all of you reading this, if you haven’t yet, visit the Node Knockout entries page and comment and vote for your favorites.  Go and see for yourself what amazing things can be done with 48 hours, an idea and a ton of people willing to help.

The Chrome "New Tab" page with Facebook added...

The LifeHacker post contains all the details regarding how to enable apps in the latest Chromium builds.  All you need to do is copy the contents of one of the manifest.json files in one of the apps bundled with Chrome:

{
  "name": "Google Calendar",
  "version": "1.3",
  "permissions": [ "notifications" ],
  "icons": {
    "128": "128.png",
    "24": "24.png",
    "32": "32.png",
    "48": "48.png"
  },
  "app": {
    "urls": [
      "*://www.google.com/calendar/"
    ],
    "browse_urls": [
      "https://www.google.com/accounts/"
    ],
    "launch": {
      "container": "tab",
      "web_url": "https://www.google.com/calendar/"
    }
  }
}

and substitute your own values and icons:

{
  "name": "Facebook",
  "version": "0.1",
  "permissions": [  ],
  "icons": {
    "128": "128.png",
    "24": "24.png",
    "32": "32.png",
    "48": "48.png"
  },
  "app": {
    "urls": [
      "*://www.facebook.com/"
    ],
    "browse_urls": [
      "https://www.facebook.com/profile.php"
    ],
    "launch": {
      "container": "tab",
      "web_url": "http://www.facebook.com"
    }
  }
}

If you’re interested, you can download my ZIP file here, facebook-chrome-app, then follow the same instructions to enable it in your own Chrome browser.

See? Easy… happy hacking!

Tweet from Smashing Magazine

I took a look at the form, and I must say I was impressed too.  Unfortunately, I was using TweetDeck on my iPhone… as a result, I didn’t see the contact form at all because the background image didn’t load very fast.  That prompted me to post this reply:

My reply on Twitter

Being a social media junkie, this tweet was then cross-posted to my Facebook, prompting this reply from a web developer friend of mine:

...the resulting Facebook conversation.

As you can well imagine, I could not let this stand.  So I decided I would refactor the form to prove that, with a few tweaks to the CSS and markup, this form could avoid the problems I pointed out.

First, let me preface by saying that I am not saying the code is bad… on the contrary, I really like the concept.  I just want to:

1. Dispel my friend’s poor logic, and
2. Raise awareness about accessibility.

That said, I tried to minimize my changes to the original code as much as possible; there are certainly improvements that can be made to the CSS and to the markup, but that was not my goal.

For reference, here are the before and the after demo pages.  I’d load them in separate tabs; you’ll see they are identical, almost to the pixel.  I’ve also added a scripted link to allow you to hide the background image.

The Accessibility Problem

First, let’s define the problem. In the existing CSS, the labels are completely hidden and the background is applied to the form.  As a result, here are screen shots of the contact form, with and without its background image, (notice the dotted lines for each form field):

The contact form with images on and fully loaded

The contact form without the image loaded

Without the image, the form becomes unusable.  So how can we edit the HTML and style the form to avoid this?

The Approach

In short, we need to add labels to each field and have the image hide them if present.  This can be accomplished with z-indexing:

A diagram of the layout

The Solution

First, I refactored the original form into something a bit more manageable, such as adding a fieldset element to the phone number, adding a header element and consolidating the label and input fields, (and thus removing the pesky “for” attribute):

...
<h3><span>Contact Form</span></h3>
...
<fieldset id="phone-el">
    <legend><span>Phone</span></legend>
    <p id="phone-ac-el">
        <label>
            <span>Area Code</span>
            <input id="phone-ac" class="text" maxlength="3"
                name="phone-ac" size="3" type="text" />
        </label>
    </p>
...

Since the legend for the phone fieldset wasn’t being displayed, I decided I would forgo the addition of any empty element and just use it for the contact form.  A bit of positioning based on existing CSS and some negative text-indent and we were in business:

body#contact #form legend span {
    background: url(res/contact-content.png) center top no-repeat;
    position: absolute;
    top: -199px;
    left: -180px;
    width: 750px;
    height: 786px;
    display: block;
    text-align: left;
    text-indent: -1000px;
    overflow: hidden;
    z-index: 50;
}

The Result

Now, when the page loads and no images are present, the form looks like this:

My refactor of the contact form without the image

With a few simple changes, the form is completely usable… bulletproof… regardless of the user’s situation.

A Few Closing Remarks

I hate the oft-uttered mantra of, “those folks aren’t in my demographic.”  That is a dangerous and amateur view of an audience for your website.  You should always be looking to make your forms as simple but as accessible as possible, because, frankly… your demographic is anyone with a web browser.  Discounting any percentage is not only a disadvantage for your business, but a disservice to all users.

Having JavaScript events in-source binds you to whatever JavaScript method (and it’s signature) you’ve specified, not to mention breaking the tenets of Progressive Enhancement. When wishing to launch an anchor’s href into a new window while using a STRICT doctype, using window.popup is the only real option, (as the target attribute is invalid in this case). Looking at the W3C specification for anchors, the following could be a solution.

Problem Statement

Recently, a navigation header in one of our solutions had a requirement that all links within its boundary needed to launch their content into a new window, thereby not disturbing any the current page. Since the target attribute is not an option, this can be accomplished by the window.popup method, a fairly standard method within browsers. This meant either the call itself would have to be embedded into the anchor, or a surrogate method. In either case, JavaScript events would have to appear in source:

<a href="http://www.google.com" onclick="window.popup(this.href); return false;">Link 1</a>
<a href="http://www.google.com" onclick="return MyNamespace.popup(this);">Link 2</a>


Problem: Obligations Introduced

The trouble is that whenever script is included in source, it means that you are thereby contractually bound to offer the same method, with the same signature… regardless of circumstance. To give a stronger example, suppose I have the following code:

    <div id="navigation">
        Some content
    </div>
    <script type="text/javascript">
        var myAccordion = new Accordion("navigation")
    </script>

I am now bound by two things:

1. I must include an Accordion object, even if I don’t need it or if I want to use a different object based on platform (e.g. iPhone).
2. I must provide the same API as the Accordion object, because there is a global var called myAccordion, which could be referenced elsewhere.

I can still swap out the JavaScript files, but those files must have an object that meet these requirements.

Solution: Progressive Enhancement through Abstraction

It would be far easier if the same markup externalized these specifics and applied event handlers through script:

    <div id="navigation">
        Some content
    </div>
    <script type="text/javascript">
        MyNamespace.setup({
            navigation : "navigation"
        });
    </script>

In this case, an API is defined within a generic namespace object called MyNamepsace. The script block invokes setup, which takes (in this case, which may be overkill) a JSON structure defining the objects or parameters to be used in setup.

This kind of generic abstraction allows us to swap out not only the CSS but also the JavaScript depending on capability or browser.

Proposed Solution: Using the rel Attribute

In the spec, the rel attribute is described as:

This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.

The spec also says that the value of the rel attribute should be one or more of a set of link-types, but this portion of the spec states:

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.

The Proposal

Since the goal is to use JavaScript to “pop” the new window, we need to identify which anchors “pop” their content to a new window, leaving the current document intact. By creating a rel attribute that specifies this, along with the necessary profile, JavaScript methods could distinguish those anchors from other anchors, thus allowing the popup event handlers to be applied.

Creating a new profile

In order to create a new link type, we need^[1] to create^[2] a profile.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>Cerner XHTML Profile</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
<dl class="profile">
    <dt id="rel">rel</dt>
    <dd>
        <dl>
            <dt id="forked">forked</dt>
            <dd>
                Refers to a location that should be, if possible, launched
                into a new window or process without disturbing the
                current page or content.
            </dd>
        </dl>
    </dd>
</dl>
</body>
</html>

Using the Profile

Then, we would use the new link-type defined in the profile for any anchor we’d want “popped” into a new window, (or, indeed, whatever other action we choose, based on platform).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head profile="http://deploymentserver/contextroot/profile.html">
.
.
.
<ul id="links">
    <li><a href="http://www.cerner.com/" rel="forked">Launch Cerner.com</a></li>
    <li><a href="http://www.google.com/">Go to Google.com</a></li>
</ul>
.
.
.
<script type="text/javascript">
    // Example script; should be namespaced, etc.
    var list = document.getElementById("links"), list.getElementsByTagName("A"),
        event = function() {
            // Process the event for the link, (e.g. popup, alert, redirect, etc).
            alert("Forked page.");
        };

    for(var i = 0; i < links.length; i++) {
        var link = links[i], rel = link.rel;

        if(rel.length <= 0) {
            continue;
        }

        var rels = rel.split(" ");

        for(var a = 0; a < rels.length; a++) {
            var l = rels[a];

            if(l == "forked")) {
                link.onclick = function() {
                    return false;
                };
                // Use my established attachEvent method; it has an EventCache
                // to avoid memory leaks, etc, but is beyond the scope of this post.
                Util.attachEvent(link, "click", event);
                continue;
            };
        }
    }
</script>

References

1. W3C, link-type Specification
2. Tantek Çelik, XHTML Meta Data Profiles

The following link is a code snippet in PasteBin that shows the methods and a quick test:

http://pastebin.com/f7b68ab19

Basically, the two I wrote and that I’m evaluating are:

Create Element

This method caches a created element instance in an array. In some browsers, like Firefox, this method is marginally faster; I’m thinking the array access is hindering it from being even faster.

Create Element with Properties

This method basically allows you to set attributes using a JSON object. Nothing fancy, but the developers like it. I’m concerned about the speed of the loop, and developers have been asking about how to set the runtime style. Since element.style is, of course, not settable, I’d have to either expose a second parameter, or allow a more complex object and write more logic, (assuming I decide to support it).

I’d love some advice… here’s what I don’t want:

Just use jQuery / Prototype / my framework!

That kind of defeats the purpose of this exercise!

It’s much easier than that, once you figure it all out… here’s how to do it!

I scoured the Internet, searching for a way to do this… I ended up referring to more websites than I can remember, mostly from the Safari 3 beta period.  A couple of approaches out there required downloading a copy of WebKit, but I couldn’t get this to work effectively. I took a lot from Michel Fortin and his post of the subject. Although his solution didn’t get me all the way there, a lot of Google searching and web board posts did.

Basically, the trouble is that Apple stores the common WebKit framework for the entire Mac.  Even if you copy Safari 3 somewhere to your machine, it will still use the newer WebKit layout engine.  The trick, then, is to provide the older framework to the older Safari instance. What’s nice about this approach is you’re just “restoring” Safari 3 and giving it the older versions of the Frameworks it relied on… no extra WebKit stuff to worry about.

Here’s how to do it:

1. Install the Safari 4 beta.  Don’t worry; Safari 4 saves a copy of your Safari 3 install to an archive.
2. Go to /Library/Application Support/Apple
3. Extract .Safari4PreviewArchive.tar.gz somewhere, like your Desktop.
4. The Applications directory contains your Safari application; the System directory contains the older frameworks, like WebKit.
5. Right-click the Safari application and select Show Contents.
6. Copy the Frameworks, LaunchAgents and PrivateFrameworks directories from the System/Library directory of the expanded archive to the Contents directory of the Safari application.
7. Edit Info.plist from the Contents directory in a simple text editor.
8. Add the following XML snippet beneath the parent <dict> element:

<key>LSEnvironment</key>
<dict>
<key>DYLD_FRAMEWORK_PATH</key>
<string>Contents/Frameworks:Contents/PrivateFrameworks:Contents/Frameworks/WebKit.framework/Versions/A/Frameworks</string>
<key>WEBKIT_UNSET_DYLD_FRAMEWORK_PATH</key>
<string>YES</string>
</dict>

That should do it!  You should now be able to run Safari 3 side-by-side with Safari 4.  If anyone knows a good file share site, I’ll be happy to post a ZIP of my version.  Hope this helps!

UPDATE: I’ve uploaded my Safari 3 standalone here.

Disclaimer: This is the result of obvious tinkering. I may have torn the fabric of space-time somewhere, and you could make it worse. Considering this possibility, I can’t imagine being held responsible if something merely goes wrong with your computer… use at your own risk.

I was directed to a CSSZenGarden design created by Outline2Design that is rather beautiful… I was really impressed, so I looked at their homepage.

Their designs are extremely artistic, and valid XHTML, so I was even more impressed; I wanted to know more about their work and where they manage an office, (mostly to determine if they were a small shop, a front for a larger shop or just “a person.”)  I noticed a copyright link to Zertle, LLC.  Clicking that, I saw that Zertle owns two shop fronts, Outline2Design and PSD2HTML.

That’s when I was absolutely disgusted by the pricing strategy at PSD2HTML.

Deciding How to Charge is Hard

I realize it’s difficult to decide how to price web work; I’ve had that problem before. You kind of have to divide the effort into the creative and the technical – creating HTML, (at least, in my opinion) is the easiest of the two. Creating a brand identity and graphical assets are far more subjective tasks, therefore requiring much more work.

Converting a design to HTML, however, is much easier. You can almost feel how the document flows. Sure, there are elegant and thought-provoking approaches to noodle through, and reusability and accessibility concerns… but the process goes very quickly. Oftentimes, you use tools from your toolbox, like Microformats or common libraries.

At Cerner, when I’m handed a design, it takes me roughly two hours per layout to complete, less if the following location follows a cohesive style, (and they do). So this company promises an 8 hour turnaround time, which I think is respectful, if not aggressive if they have a large workload.

What I find appalling is their package rates and “options.”

You Want to Charge Me For WHAT?!?

Here are a few examples, and an explanation as to why they are shady… I mean, “Used-car Salesman” shady. Throughout the following examples, I’m going to draw an analogy to someone coming to paint your house: you know what color you want, and how you want textures to look, but you don’t really have the time, nor the expertise, to paint it yourself.

How Good a Job are You Willing to Pay For?

Ok, we’re all set to start. Pick a package and price range for them to convert your image into a web page.

Screenshot from PSD2HTML.com

Figure 1 – So… do you want your page done professionally or not?

Asking someone to quantify exactly how professional they want their page is like asking if they’re willing to pay more to get things that a professional should already do. You’re telling me you won’t “pay special attention to Load Speed” if I don’t shell out the extra hundred?

The trouble is, someone who doesn’t really understand the web may not understand what they’re paying for… besides, the developer should do this anyway.

The painters show up with the crew, the paint and the brushes. They’re ready to paint your house, but before they start, they ask:

“Do you want us to tape off non-painted surfaces?  Then you’ll want our Professional Painter’s Package. Do you want us to avoid getting paint splatters on your concrete and bushes?  In that case, you’ll need to upgrade to our Hi-End Painter’s Package. You see, it’s all about what you’re willing to spend.”

These aren’t options: they’re the mark of a professional job.  Cross-browser compatibility, Search Engine Optimization, semantic code, prez-layer separation… these are professional, industry standards. You could get away with asking for more time, but more money?!? C’mon…

Flex Your CSS Muscles

This one, I kind of understand.

Flexible, or “fluid” layouts can be difficult, depending on the style.  You have to decide the widths of each column, how text wraps, and even when items start to drop.  Again, asking for more time is one thing, almost expected… charging more, I could almost condone.

But isn’t this on a case-by-case basis?  Don’t you have to ask some directed, consultative questions about intent and purpose?  And how did you arrive at $29?  It just seems nonsensical to me.

After shelling out more cash, your painting crew has another question:

“Would you like us to hand-paint your house, or can we go ahead and use our sprayers for the larger walls?  You see, when we got your address, we weren’t sure about the texture or composition of your walls, so we can’t tell you right now without looking which would be better, per-se… but we’ll knock $20 off if you let us spray.”

Maybe they’re encouraging a fixed width by offering a $29 discount?  At any rate, it’s a client call, and I just don’t think it can be programmatically determined.

Moving on… because the next one is my favorite.

Nickels and Dimes Add Up to Big Bucks

I’m curious about Advanced Markup Options.

“This option gives you the guarantee…”  Are you kidding me?

You know, in my office, hack-less cross-browser compatibility is a point of pride.  Sometimes, when we do a demo, we like to give the people in the room the choice of which browser we use to demo… no-holds-barred.  We also give the option of a JavaScript-disabled or CSS-disabled configuration.  It’s cool to be challenged, to be able to show our stakeholders that no mainstream browser was ignored, no detail was overlooked.

“I’m sorry, but which side of your house faces the most people?  I mean, people who live next door to the east can’t really see the house wall… their window on that side is pretty tiny.  And most people don’t drive east on the street, so most wouldn’t see the east side.”

“Oh… and should we avoid painting the exterior window fixtures?”

To ask a client to pay more for cross-browser compatibility, or to offer a discount to let it slide, encourages the very attitudes web professionals hate: that only the majority matters… that it’s too hard to code (and test) for 99.9%.  That attitude is what allows Microsoft to continue including proprietary features, (and oftentimes, tolerating omissions): they’re the majority, make your site work in their browser.  It’s unacceptable for a professional web shop to not work in these browsers out-of-the-box.

And, I’m sorry… but $4 for rollovers?!?  Are CSS hover implementations been deemed hard enough that the code to create them is worth $4?  Are you telling me I have to pay you the equivalent of your morning Starbucks Latte for the effort?

The following, though… is unacceptable.  That’s all I’ll say:

What else can I say?

Damn, I’m Sorry, but…

I don’t mean to pick on these guys; I don’t know them from Adam.  They’ve obviously put some thought into how they’re to be paid for their work.  But the strategy is flawed: what they’re charging more for should just be included. They should just state the job will cost between $150 and $300, depending.  As I’ve pointed out, they have more questions to ask once they get the design anyway.

Will they change their pricing “menu” because of this post: probably of course not. But then again, I don’t know how much of a market there is here.  Most web professionals like to be in control of the design.

For someone like me, I’d love it if the client provided me the visual they want; I suck at drawing.  But even if they did, I would still consult with them and provide them with a quality product that another web professional would be able to edit…

… but more importantly, respect.

Unfortunately, as in all rules assumed in parsing, mistakes can be made:

My guess is that it was looking at “7.50 ea” and translated that into 7:50 Eastern, but I can’t be sure.  All I know is that it interpreted three items a friend of mine ordered into appointments.  No big deal, but it just reminded me that, even when some parsing rules seem simple and straightforward, someone is going to have a use case that breaks them.

Microformatted

I used the hResume microformat, which basically makes it readable by any microformat-parsing utility. Very slick. My microformat plugin for Firefox lit up as soon as I loaded it, telling the who, what, where and when of my resume.

Print / Screen stylesheets

Yes, it’s pretty. But if you’re printing it, you shouldn’t need a color printer, so I set up a print-only section of the sheet. Do a “print preview” to see what that looks like.

Portable

The HTML file is written to be portable, so you can save a copy locally, even from the web, without any external resources. Now I can send my resume in HTML format, instead of Word or Adobe PDF.

We arrived last evening. The hotel is really, really nice. It’s brand new, with flat panel televisions and really large bathrooms. It’s very contemporary furnishings and “un-crushed” chairs and couches. The computers were down, though, so after an interesting “here, let me write your information down and give a room key” transaction, we headed to the LTK restaurant down the street… quite good. Afterwards we wandered back to the hotel, and I decided to hit the lobby restaurant/bar called Sauciety and have a scotch before bed.

While I was there, I met two HR representatives from Ask.com named Kelly and Amy; very fun people. Amy works for Kelly, and once they learned I was there for the same conference, they proceeded to tout the benefits from using Ask.com, (vs. other engines I was not allowed to mention by name without a dirty look).

We were having a nice time talking, so they snuck me in to the Speaker/Sponsor reception around the corner. I got to meet a few of the speakers… most were tired from the trip and were there only to pick up their registration materials (and free iPod). A few were playing some tile game called Hive… the gameplay logistics were lost on most of us, but they looked like they were enjoying it.

After the reception, we wandered over to the other lobby bar, The Birch Bar. It was there I met the booth guys from IceSoft, a Canadian JSF/JavaScript framework company with a booth downstairs. After a couple of hours talking geek and hearing a much more, er, robust pitch about Ask.com, it was off to bed for an early morning.

It was a nice start to an exciting conference. I’ll be (well, attempt) blogging about each day I’m here, perhaps even each session. Stay tuned!