My good friend Clark has been getting a lot of press recently about his new project 12 Hours In A City and I’m pleased to announce I’ll be helping him out.
These guys are using JetBlue’s All You Can Jet Pass to get a taste of America and get the experience of a lifetime. They’ll be visiting about 27 cities in 30 days, relying heavily on contacts made through social media sites for tips on interesting things to do in each city, rides around town, and places to crash for the night.
So far they’re off to a good start, they made it on the homepage of CNN’s Travel section the day they left and got invited to a see a Red Sox game from the Dunkin Donuts box at Fenway Park in Boston (their first stop)!
With their rigorous travel schedule and the fact that they’ll be spending most of their downtime in the air, I’ll be administering the site, making updates here and there, and implementing some additional social networking functionality.
I very often neglect writing here in favor of devoting that time to paying work. But recently I found something that might be helpful to somebody else so I thought I’d take advantage of that.
Over the last few months, a handful of our clients have had customers report issues with their websites. Online searches at the time didn’t turn up anything that sounded like the problem I was trying to fix so I figured writing about its resolution now might help someone else in the same boat I was.
The most common bug reported was that customers ended up on the site homepage when they clicked links that should go somewhere (or do something) else. For the few that reported it, clicking a tab on a Moosejaw product page to view additional details sent them to the homepage instead. Or clicking the Sign-In link up at the top of the same page sent them to the sign-in page instead of revealing a small inline sign-in form.
The sign-in link bug was more of a minor inconvenience since users still ended up at a sign-in page. They just missed the benefit of being able to do it without leaving their current page. The product tab issue was more critical however since users affected by the bug weren’t able to view information that may or may not affect their decision to buy.
All of the users who reported problems were using Internet Explorer 7 on either Windows XP or Vista. While the majority of the browsing public meets that criteria, we were still getting very few reports of problems. Unfortunately no one in our office or the clients’ could reproduce the problem. It had to be some setup unique enough that not every one using Windows/IE was experiencing it (thank god) but common enough among the half dozen people who took the time to report it.
Luckily we had a customer willing to help us diagnose the problem. He easily reproduced the error for us during a Go-To Meeting and also patiently labored through test pages that we tweaked on the fly to try to solve the problem. To no avail.
Without getting too bogged down in detail, the product tab links look like this:
Normal behavior is that javascript code in somefunction is executed when the onclick event fires and the browser is prevented from changing its location to the value of the href attribute by a return false; statement at the end of somefunction. In this case, the content of each tab is written when the page is rendered and somefunction sets the display attribute of the clicked tab to block and the display attributes of the other tabs to none. Simple.
Except that for some users, clicking the tab was taking them to the location specified in the href attribute, #, the root of the site. At first we thought there was a scripting error that was causing the function to fail before the return false; could be executed. But Internet Explorer wasn’t reporting any errors on the page. We tried moving the return false; statement inside the onclick to be on the safe side.
That didn’t work either. Although with a return false; statement in the function itself and no script errors being generated, I didn’t really expect it to make any difference.
Which is a common technique for using a elements to execute code rather than changing locations. But all that did was stop the browser from going to the homepage. Our tab content still wasn’t showing. somefunction was still not being executed.
Eventually fixing the bug ended up on the back burner because of the extremely low volume of people reporting it. My heart sank recently when another complaint surfaced. What were we going to tell this customer when we had exhausted possible solutions before and come up with nothing?
Luckily the most recent complainant was pretty comfortable technically and started investigating possible causes on his own. The best news came when he reported that restoring Internet Explorer to its default settings and disabling all his add-ons solved the problem and the onclick events started behaving as expected again. Then he re-enabled his add-ons until he isolated the cause as the McAfee anti-phishing filter installed by his McAfee anti-virus suite.
At the time of this writing, a Google search for ‘McAfee anti-phishing filter’ has only turned up complaints of it causing sites to load slowly. Nothing regarding its effect on Javascript code. I couldn’t find any evidence on McAfee’s website that this is a known issue. Supposedly, the customer reported it to McAfee so hopefully I’ll have additional details soon. Such as a possible work-around. Other than simply disabling the filter. Interestingly, Internet Explorer’s built-in anti-phishing filter does not exhibit the same behavior.
On a side note, this bug draws attention to an interesting usability question. The product tabs, whose href attribute is set to #, completely failed for those users affected by the bug. While the Sign-In link, whose href attribute was set to a sign-in page URL, was still usable even though the onclick event’s failure to fire prevented the inline sign-in form from appearing.
Should the tab links have real values in their href attributes? Since each tab content doesn’t have its own URL, where should the link point to? Is it necessary to create server-side programming that accepts URL querystring parameters and uses it to show the appropriate tab in the event the onclick event fails and the page is redirected? I know in at least one case, the failure of the product tabs code caused a customer to order from a competitor where he could view the information he needed to make his decision.
People who rely on their creative juices to make a living have always ‘collected’ inspirational items. Images, textures, toys, etc. get stored in the ‘bank’ for later use.
In the past I’ve made several unsuccessful attempts to keep track of website designs that I like. But simple bookmarking has never really worked for me. I rarely make the effort to go back and organize the bookmarks so I always end up with one giant list. Saving a URL doesn’t really take a ‘snapshot’ of the inspirational design, sites get redesigned, URLs change, etc. So my already unmanageable list can eventually be filled with designs different than those that originally inspired me or invalid URLs. There’s got to be a better way.
FlickScreen runs in your Apple menu bar. A dropdown allows you to choose between uploading a capture of your entire screen or just a specific portion of it. Users can easily enter titles, descriptions, and keywords for their captures and even put them in specific sets. It takes about 10 seconds to classify and upload a capture. All without leaving the page.
I’m pleased to announce that Radiant Skin Clinic, a client of mine, is now a certified green site!
Over the last few weeks we had been experiencing a lot of performance problems with our old host. The situation didn’t seem to be improving and after a few days of truly abysmal loading times, we decided it was time to move to a new host. I’ve always heard great things about Dreamhost so we went with them. With 500GB (increasing weekly) of storage and 5TB (increasing weekly) of bandwidth, their pricing and plans can’t be beat. It’s an added bonus however that Dreamhost purchases Renewable Energy Credits to offset the carbon emissions generated by their business activities.
While I wouldn’t recommend selecting any service provider based solely on whether they’re carbon neutral or not, so far Dreamhost service and the features have been impressive. Clicking on the “green site” badge above will take you to a Dreamhost page with more details on other steps they’re taking to minimize the effects of their business activities.
Unfortunately it’s also time to buckle down and do some much needed maintenance and upgrades to some WordPress and other applications I have out in the wild.
I’m pleased to announce the release of the NEW Yaeger, Treviso & Associates, Inc. website! It was great to work with Jon and Chuck on redesigning their existing website. They’re excited about the idea of clients being able to upload Quickbooks and other financial files directly to them. And because tax season is so busy, they’re always on the lookout for additional talent. Prospective employees can upload resumes as well.
I always say it’s because I’ve been busy. And it’s true. In the last month, I’ve moved this site to a different host and started everything but the content from scratch. Oh yeah, I also moved cross country.
Aside from the move, the important stuff is that I’m no longer with CUNet. I’m currently freelancing and looking for something web development/design related that really interests and inspires me. If you think you have the thing, please check out my portfolio site for examples of my work and contact information.
I summed up the latest changes to this site in another post so I won’t go into it again now. The newest of the new though is the LinkedIn icon that appears at the top of the middle column. I’ve always gotten good traffic and leads from my LinkedIn profile. Now that I’m left to my own devices for employment, I’m going to try to better leverage LinkedIn. Afterall, there’s a wealth of good information there about me. It acts as a resume of sorts, outlining my work experience. Even better, it contains loads of endorsements and recommendations from my coworkers and clients.
I spotted this a week or so ago in the grocery store parking lot not far from where I mountain bike. The sight of it (almost) made me giddy like a school girl
The DropIn bus is the home away from home for a half dozen or so pro and semi-pro mountain bikers. It’s a series on Canadian TV that I got turned onto about 5 years ago. I watched the first season religiously (then available only on the Internet in the States) and even bought the DVDs. At the time they were traveling throughout Northwestern Canada searching for great spots to ride and filming themselves ripping it up. Four seasons later they’ve been all over Canada, the Western United States, and even spent a season in New Zealand.
Life happened and I got away from riding for a while. I had forgotten all about the show until I had some downtime recently and decided to watch the DVDs again. It’s a weird coincidence that a few days later I’d spot the bus in my “neighborhood”. It was even more of a surprise to go out to the mailbox and find Dylan Tremblay riding down the sidewalk toward me. We chatted for a while about the local riding and their next destination. I also checked out his new bike (in the video below). It was definitely cool to personally meet a guy whose riding I respect and whose skill level I’d like to reach.
Well, here is the new “design”. I opted to go the theme route because I find I get bored with a design by the time I’ve got it all fleshed out for Word Press. Besides, like I said, I’ve been pretty busy with paying work lately.
Over the last few weeks I’ve upgraded Word Press to implement some security updates as well as take advantage of some widgets and plug-ins available for more recent versions. The Recent Reading and My Flickr sections of the footer are new to the site.
I’ve also updated the directory structure and moved some things around a little. It’s been tested locally but please let me know (in the comments here) if you click on something that doesn’t work as expected.
As I mentioned in my previous post, Coming…soon(?), this website also has a new home with Bluehost. They came highly recommended and they offer RoR hosting so hopefully you’ find some posts about Ruby here in the near future.
Unfortunately this site has been largely neglected (in favor of paying work). But hopefully soon all that will change…
I’m trying out a new host and this will be the first domain to switch over. When it does, it will have a new (sorely needed) look. The new host supports RoR so I hope to play around with (and write about that) here.
