Hot Koehl

The latest and greatest version of jQuery, version 1.4, was released on January 14, the birthday of jQuery’s original launch. Bugfixes and improvements abound!

The jQuery team has put together a site devoted to the new version, called the 14 days of jQuery, covering the major version changes as well as infrastructure updates coinciding with the new release. For example, the documentation site has been completely redesigned, and been moved to it’s own subdomain home, api.jquery.com. Links from the primary jquery.com site should be updated within the next week. With video demos of new features, Q&A’s with the core team (including founder John Resig), it’s well-worth checking out for every jQuery developer.

Everyone at this point knows the story of Michael Vick (quick summary if you don’t: he beat dogs, then got his high-paying job back after getting out of prison). Now the Philadelphia Eagles have given this guy a damn award.

I could sit here and articulate this guy’s rise-fall-rise-again story as a sign of the apocalypse, but I think most people would find it more interesting to hear this one from a veterinarian’s perspective. My wife Jennifer has a writeup on the matter, so if you ever wanted to know what someone in the industry thinks of Vick, I encourage you to check it out.

I recently made the decision to store times on Fwd:Vault systems in Greenwich Mean Time, or GMT. I decided to do this because I have time-sensitive events happening along several dimensions. Email coming into the system has several timestamps associated with it: the user’s initial delivery, relay from their mail server, and receipt by the Fwd:Vault mail server. Payment receipts come into Fwd:Vault from our billing provider, which gets stored in my system and made available to the user.

Up until now, my server time was set for the US Eastern, where both I and the server physically reside. Then I started building the code to display local time based on a user’s selected timezone.

Ugh.

Here’s the problem: displaying local time requires at least one time conversion, from server time to the user’s timezone. If the time is initially set to anything other than no-offset GMT, you have two calculations to do, from the server timezone to GMT, then GMT to user timezone. You can do it, of course, but who really wants to write even more code?

Now add to this equation the fact that most data-delivery systems have settled on sending time data in GMT. A very good practice, to be sure, but presents the need to do another timezone conversion when the data come into your systems. Going back to my example, I had to convert payment times from GMT to US Eastern before dropping them into my database.

Finally, add to the mix the potential for time data coming in from more than one source with more than one offset. Again back to my case, payment data is GMT, as is the Twitter feed I store and display on the site. Meanwhile, email was set to US Eastern. This matched the server and MySQL database where all the data ends up residing, so I was still looking at just one time conversion. But what happens down the road, when my server configuration changes, or I move to another timezone?

Tying this information to me makes as much sense as tying it to any one of my users. It’s the same rationale that data service providers use when delivering GMT time data, it applies to me, and it applies to you too.

I’m just too lazy to try and keep all that timezone switching straight in my head.

If you find yourself in the same scenario, save your sanity and your future support efforts. If you run a website that (a) displays time-sensitive data, and (b) allows users to create an account, you really owe it to everyone involved to store time in a neutral fashion and adjust time displays according to the user’s selected timezone.

The Future of Web Apps conference is so right up my alley it’s almost stupid that I couldn’t attend. Web development with a focus on business: customer service, driving traffic, marketing, sales… It’s essentially the event for geeks who want to go from the basement to the corner office. Fortunately, Ryan Carson and the team at Carsonified are kind enough to freely distribute some the presentations made at this year’s London event.

I couldn’t find an index of all of them, and I wanted to watch them all in chronological order, so here you go. If there are videos for the presentations I’m missing (here’s the full presentation schedule), please let me know so I can link them.

Taking your Site from One to One Million Users by Kevin Rose

Introducing Atlas: A Visual Development Tool for creating Web Applications by Francisco Tolmasky

Start-up Metrics that Matter by Dave McClure

Branding and Marketing Essentials for Your Web App by Alex Hunter

Now is the Time to Cash in on Your Passion by Gary Vaynerchuk

The Future of HTML5 by Bruce Lawson

You-Centric: The Future of Browsing by Aza Raskin

The Future of the Cloud by Simon Wardley

I was recently quoted in an article over at IT World, discussing underused developer tools (e.g. security testers). My quote is on page 2:

http://www.itworld.com/development/74088/developer-tools-you-dont-use-and-why-you-dont-use-them

Also FYI I am on vacation the rest of this week; return to our regular schedule next Monday.

The guys from big G never cease to amaze me. I was deleting an old coupon message from Pro Flowers today and accidentally hit the “Report Spam” button instead of “Delete”, and was greeting with this:

I thought unsubscribing from legitimate mailing lists was already pretty easy, but Google decided that one step was still one too many. The usability focus these guy extrude is mind-blowing at times.

If you’re curious, that “Learn more” link heads to a Gmail Help article. It just discusses why they did it, and nothing about how. So it’s less than helpful if you run a mailing list and are looking to leverage this feature for yourself. If anyone finds out how to tap into it, please comment or email me.

I recently discovered an issue with the mailing list signup on the Fwd:Vault placeholder site. [Aside: It was perfect when I set it up, I swear there are gremlins in my code sometimes. If you tried to sign up and were unable to, I apologize, try it one more time.] After fixing the issue, I naturally tested it in every browser, and Opera was simply hanging at the page load. The page would visually come up fully, but the Javascript effects wouldn’t fire, making the signup form unresponsive.

To start figuring it out, I enabled the Progress Bar to check out when/where the problem occurred. The bar contains a bunch of useful stats while the page is loading. To see the bar yourself:

Shift-F12 > "Toolbars" tab > choose "Pop-up at bottom" from dropdown.

Here’s a screenshot of the menu:

Then I refreshed the pageload and saw this…

Note the “Elements” load is off by one, yet the request is listed as “completed.” Keep in mind that the browser is still acting like it’s loading at this point: hourglass cursor, and I couldn’t interact with the page. To make matters worse, you can’t click through to see any further details on any of these stats, which is really dumb since this summary information is coming from somewhere.

Opera’s Developer Tools, Error Console, and Java Console interfaces showed nothing. I probed the rest of Opera’s menu’s and output options, and couldn’t find anything to support remedying the situation. I could be wrong of course, so if you have more Opera experience, please let me know where to look.

Instead, I used Firebug to discover a missing Javascript file, as the title suggests. I had a standard <script src=[...]></script> block, but the target file wasn’t in place. Now every other browser had handled this situation just fine, they timed out on the missing file and moved on. Opera is apparently more insistent, which wouldn’t be a problem if they provided the information necessary to diagnose the situation or manually override the hanging pageload.

This behavior is simply idiotic planning on Opera’s part: end users see a finished page that doesn’t allow interaction, and webmasters get zero clue to the cause of the hangup.

Expounding, this seeming lack of user focus likely contributes to Opera’s weak market position. With all the free choices out there, they have to be the most appealing in one or more categories to one or more demographics, and I never saw anything Opera that differentiated it significantly from the pack. That seems like a “Business 101″ observation to me, but they certainly aren’t the first netcom to come along without a clearly defined path to market and profit.

This is the kind of “usability fail” that drives me nuts, especially from a company of Google’s caliber. When you add a new site to Google Analytics, they present you with the Javascript code block you need during the setup process. But what if you need to look up that code block again? What if Google updates the Analytics code block (they just did it in Dec 2008)? Naturally you go back to the Analytics site to get the code…

Where’s the code block at? Anyone else stumped? Keep in mind that I limited this puzzle to just a single page; I scoured the whole site before finding the link on this page. As it turns out, the code block is hiding in the Check Status link in the top right corner of the main column.

It’s not part of any of the standardized navigation — the header, the breadcrumbs, the sidebar — and the link text is not at all indicative of what the resulting page contains. Speaking of which, the page that actually houses the code is even more incriminating.

The “status” information appears at least in part on the previous page, so the overt purpose of this page is pretty worthless. To make matters worse, the breadcrumb actually says “Tracking Code.” So someone got the right idea when they put this page together, but didn’t follow through when hooking it up to the rest of the site navigation.

Everyone (and so every company) makes mistakes. However Analytics is an offshoot of the Google AdWords service, which is their bread and butter. This kind of oversight on a flagship product is simply sloppy.

Make sure that you spend all the necessary time on the key “touch points” of your site/service to ensure they are operating at their maximum.

I was recently discussing Fwd:Vault with a typical end user, specifically how our service is completely oriented towards people who simply cannot or will not bother with anything technical. She whole-heartedly agreed, and expressed her mindset as follows:

• Just make it work.
• Don’t frustrate me.
• Don’t break on me.

I think those three sentences are the best litmus test for usability and user interface design that I’ve ever seen. They apply to software in any state, planning to released, and always provide an honest assessment (as long as you’re honest with yourself). Eye tracking and usability testing are great when you have the time and resources, but any developer can run this test by himself from his desk in about 5 minutes.

Try it yourself on your current project, and see if you don’t uncover an improvement of some kind.

Since announcing my work on Fwd:Vault, a few friends have come forward expressing interest in being angel investors. From what I’ve read, most entrepreneurs have to seek such people out, so I’ll take it as a compliment that these friends either (a) really like me, or (b) really trust my technical and prowess. I’m leaning towards (a)…

Anyway, despite my obvious flattery at the offer, I always answer the same way…

I’m not looking for investors at the moment, no. My goal is to get this thing off the ground with zero incurred debt or outside investment, and grow with revenue. That’s the beauty of a dotcom startup: depending on what you’re doing, if you put it together the right way the first time, it can largely run itself.

Think about that. After several months analyzing technical requirements, programming, support, customer service, marketing, etc., I’m confident that I can run the entire business in a solo fashion until reaching a certain point in revenue. The only reason I can do this is because I am setting myself up for a launch with as many core features and as few bugs as humanly possible. That will allow me to focus on customer support and marketing, both of which require that I not have my head buried in a computer screen 12 hours a day.

I don’t care what Michael Masterson says, “ready-fire-aim” will only create more work for you down the road. Don’t fire off projects half-cocked. Take the time to lay the groundwork, and you’ll reap huge benefits in the long-term.