Impressive Designs

Very recently Facebook and Twitter have changed to (or added) new URI structures that contain a shebang.  A shebang looks like this: #!
(I know technically it’s not a shebang.  It’s just easier to say than a hash with exclamation point after it.)

Naturally, this threw many SEO’s like myself into a raging panic.  “Search engines ignore everything after a hash”, we proclaimed.  “All of our SEO work in social media has been for not!  Oh the humanity!”

Fortunately, this is not the case.  These major social media outlets are using Google’s spec to make AJAX crawlable.

That’s right, web apps can be as crawlable and optimized as static content.  Well… in theory.

If we take a look at what Google has indexed for these Twitter profiles with the new URI structure, we get a single result, and about 100 in the supplemental index.  For a major pagerank site like Twitter, that doesn’t look too promising.  Google even says in the FAQ, “Just as with static web pages, Google makes no guarantee about search rankings.” A bit of an understatement, no?  Granted, the change on Twitter is still rolling out and is still opt in at the time of this writing.

In any case, I think these results will improve vastly going forward.  More and more web apps using asynchronous javascript are popping up on the web everyday, combine that with Facebook’s adoption of Google’s spec, and you have something that will be going the distance.

So all that is the cat’s meow, but how is crawlable AJAX accomplished?  Well, it turns out that crawling through AJAX ain’t like dusting crops, boy.

Here’s the basics of how it works.  You want to have your regular AJAX app look like this: www.example.com/ajax.html#!key=value and then a canonical version that is a static snapshot.

When users hit your site, nothing will happen.  However, Googlebot automatically knows (it is their spec after all) to modify each AJAX URI to fetch a static snapshot of that page.

The static HTML snapshot must be generated when this URI is accessed: www.example.com/ajax.html?_escaped_fragment_=key=value.

So, you grab it:
$escapedfragment = $_GET[’_escaped_fragment_’];
or you grab it:
Dim escapedfragment As String = Request.QueryString("_escaped_fragment_")
depending on your favorite flavor, and if it’s not null, spit out an HTML snapshot.

How do you create an HTML snapshot? Just use some type of headless browser.  It’s not as scary as it sounds, just use something like HTMLunit or crawljax.com to grab it.

If you’ll forgive the personification, Google hates it when Googlebot sees something different than what users see.  I mean hate, with a capital H.  So be very careful to match your HTML snapshot with your AJAX app or you could find yourself filling out re-inclusion requests all night long.  Also, I believe only Google has a spec for this type of thing, so if your SEO strategy requires Yahoo! and Bing you might want to consider an alternate implementation.

For more info, check out http://code.google.com/web/ajaxcrawling/ and happy SEOing!

For our second Rally Point meeting, Gabe Kessler did a presentation on ExpressionEngine 2 and JQuery. The long awaited version 2 introduces a lot of changes in how the ExpressionEngine deals with javascript—since the admin relies on jquery the developers put in place a mechanism for managing jquery so you have one place to deal with libraries and plugins and such. Gabe demonstrated the essential tags for the module and showed us where in the directory structure to drop plugins.

The real cool stuff was his walk through of the JQuery UI. He demonstrated how easy it is to set up customized JQuery UI elements using the jquery theme roller. Go ahead… click the link and dink around for a little while… I’ll wait here.

Back? Cool. Not satisfied with that bit of marvelous-ness, Gabe went on to demo some Google API tools. The code playground, web fonts, translation tool and other goodies were demoed to the accompaniment of oooos and ahs (most genuine). For a list of links to the items he displayed, visit Gabe’s delicious bookmarks group for Google API.

What the heck is this all about? Twice a month one of the Imps presents a topic of interest to everyone at lunch. Currently we’re doing this on the second and fourth Wednesday of the month.

A few weeks ago Sheila, Gabe and I met and discussed coding and CSS strategies. We enjoyed the exchange of information so much we decided to make the forum official. Now we’re holding a Rally Point meeting the second and fourth Wednesday of each month. Each Rally Point meeting will have one of our team present on a subject of interest to all the Imps and allow for a free exchange of information about the subject.

Our first Rally Point meeting was all about Rails 3 and Bundler and was presented by our code ninja, Jerrod Blavos. Jerrod demonstrated some of the coolness of Rails 3 by building an app that pulled images from a Flickr account using the Flickr API, stored them locally, then processed various thumbnails and displayed them on a web page. He built this app in a matter of minutes… a feat made possible by the awesome-ness of Ruby on Rails!

Jerrod also talked about Bundler, a gem that helps manage Ruby on Rails application dependencies. It’s a part of Rails 3 and massively simplifies the process of keeping gems in sync across an app’s environments (development, staging, production, etc.). Any Rubyists out there have certainly experienced the error message-gem install-restart-error message cycle that can occur when deploying an RoR app. If you know what I’m talking about and want to make your life easier, check out Bundler… it’s a godsend.

As with the first unofficial Rally Point meeting, everyone left feeling a little smarter… and perhaps a little challenged. Thanks to Jerrod for taking the time to put together a great presentation… now go out and download Rails 3 and Bundler and get yer Ruby on!

Additional Notes:
Mac OSX users should install RVM to aid in managing multiple versions of Ruby. Get it here. An excellent tutorial on Rails 3 is available here. I think they’ve kept up with the notes and such, but if you’re not comfortable dinking with the under the hood stuff on your machine, don’t.

Imagine you’re sitting at home and an unannounced visitor rings your bell. “I’ve been looking at your neighborhood and noticed that your house isn’t as attractive as it could be,” the visitor says. “If you’ll simply give me the keys to your house and $200/month, I’ll see to it that your house becomes the most noticed house on the block.” So.... in this scenario, how many of you are looking for the spare key and the checkbook? Not many, I’m sure.

Recently several of our clients have reported being contacted by an out of state search engine company. They state that they’ve been researching the market and discovered deficiencies in the keywords or coding of a site and that if you’ll simply sign up for a package and hand over all access to your website, they’ll make sure your site ranks on the first page of Google. Perfectly rational people who would never consider giving their house key to the visitor in the home scenario have called us asking if this is a good idea.

First of all, when’s the last time you even considered doing business with a telemarketer? No legitimate, ethical search engine company is going to cold call you. They don’t have to. Second, giving a third party total access to your website is a very bad idea. In the case of the company referred to above, I’ve discovered that they typically install hidden link farm pages on their client’s sites. Lastly, this company requests your credit card information over the phone for payment. A quick Google search of this company has revealed an enormous number of complaints concerning unauthorized charges.

There are plenty of legitimate search engine companies in the area. When choosing a firm, exercise the same discipline you would to hire any other vendor. Ask for references, follow up with calls to those references, and get everything in writing. Be aware that search engine optimization is an on-going process that takes time to see results. Stay away from firms that guarantee results or promise quick fixes; Google’s Webmasters pages state that you should be wary of such firms.

In other words, just think before acting!

Yep… just as I’m beginning to feel like I have mastered all the new stuff in CS3, Adobe has come along with CS4. I learned a long time ago not to be a big ol’ whiny butt about shelling out big bucks for an Adobe upgrade. Having the latest and greatest is part of what makes this career exciting and you can’t have that without buying new computers and software. Upgrading at every opportunity isn’t for everybody—I usually fall into the every-other-version category of upgraders myself—but when it comes to the Creative Suite and Mac OSX upgrades, I’m the born sucker Adobe and Apple thrives on.

My adventure with CS4 began with a frustrating trip to the Adobe website. The new online store is unnecessarily flashy (pun intended) and it steadfastly refused my attempts to login while stubbornly insisting that my account already existed. A phone call to Adobe’s support line, which is obviously outsourced these days, revealed that their latest site upgrade has resulted in a few glitches in their user databases and my account needed some behind the scenes rejiggering. Two hours later, I gladly parted with an absurd amount of money and headed anxiously for the download page.

...where I discovered no less than nine downloads which would require a combined 23 hours to download. Now all experienced Mac owners know that downloads almost always take less time than the “time remaining” indicator displays, but 23 hours?! I decided to postpone my new software bliss and made a trip to the office on Saturday to queue up the mass of downloads.

Monday morning I went to work early in anticipation of experiencing geek nirvana. Unfortunately, the download had failed sometime over the weekend and I was back to square one. This time, I chose to download only the essential application installer and Tuesday morning I was able to successfully install CS4. So far I like what I see. There was a lot of hand wringing over the new windowing system in Photoshop, but I’ve found it to be very useful and give it a bigs thumbs up.

I’ll add more to this post as I find time to experiment, so check back!

Update
So far my experiences with CS4 have been in the “oh cool” category, not the “oh-my-freaking-god-how-did-I-ever-live-without-this!!!” category. Overall CS4 seems to be a huge collection of little tweaks… things like auto guides that REALLY work in Indesign, type setting controls in Illustrator that seem finished instead of half ass, documents opening in tabbed windows, the save for web dialog box in Photoshop… you have to use it to understand the glory of how this little irritating beast has been polished. Good stuff…

What’s not to like about open source? A group of developers working together to create free software built to answer the needs of the public. Need support? There’s a dedicated group of geeks maintaining forums that you can simply log into and ask a question. Everybody’s happy and helpful in Open Source Software Land!

Well, not really. We first experimented with OSS when our clients started asking for content management (CMS) and e-commerce services. We experimented with Post Nuke and Mambo in the CMS world and OS Commerce and Zen-Cart in the E-Commerce world. With the CMS solutions, all seemed pretty good with both until we turned the sites over to our clients. Both CMS systems we used turned out to be not so user-friendly for computer newbies. A little to much, “to do this, do this, then this, then this and this” to suit the occasional user. Both worked great for clients that had lots of posts and activities and a dedicated employee to take care of these tasks. But for the occasional user, we’d get the “Now how do I do this again?” phone calls so often we actually started just doing the posts for them.

The E-Commerce situation was a little different. We first used OS Commerce until we discovered Zen Cart, an OS Commerce spinoff. We loved it’s flexibility and the ability to customize the look and features… until we began to notice that we pretty much had to tweak every setting and touch every button to get a site that answered our clients needs. And the more customized the site was, the bigger pain in the ass it was to update.

Our final breaking point with OSS came when we migrated to a new server. Never an easy task, we found that the migration which included an update of PHP and MySQL services, broke every open source app we had online. We had started using ExpressionEngine by then to do most of our CMS work and all those sites migrated without an issue. Then came the US Postal Service rate hike… the first couple of updated shipping modules for Zen Cart didn’t work properly and the subsequent updates were awkward to apply. To make matters worst, the default download for Zen Cart STILL hasn’t been updated with the new shipping module… and nowhere does the documentation mention that.

And those droves of dedicated developers manning the forums? Well, mostly the forums seem to be packed with fans and haters with the poor “I got a problem” folks getting stuck in the middle of the battling factions. When I say we’re over the open source software thing I truly mean it.

About 3 years ago I discovered Veerle Pieter’s blog. She introduced me to ExpressionEngine through her praise of this amazing software. It’s amazingly flexible and, with a little effort to learn it’s ways, can do an incredibly wide variety of things. Best of all, it can be customized to be very user friendly. All our clients love it. Yes it costs money, but one generally gets what one pays for.

As for E-Commerce we’re in transistion. I was quite surprised to get a response from Veerle all those years ago when I asked what she used for E-Commerce. She replied, “We usually just build them custom as we’re not satisfied with anything available on the market.” I thought girlfriend must be crazy to do that! Now I see the wisdom in her statement. We’ve learned that although some aspects are standardized in E-Commerce such as checkout and payment and shipping modules, almost everything about the actual product management is SO different from client to client that we spend an extraordinary amount of time tweaking and twisting existing softwares to meet our client’s needs. So now we’re building our own using the Ruby on Rails framework.

What’s the lesson in all this? I guess it’s that anything you get for free is worth exactly what you paid for it. 

No secrets here, I’m a Mac guy. Have been ever since I decided to go to Kinko’s and make my band’s promo post cards. I tried to use the PC’s… hell, everybody KNOWS Apple is going out of business, why waste time on a dead platform? But after a half hour of struggling I moved over to the Mac and soon had postcard art set up.

Nothing burns me up more than to go to a website, attempt to access some feature or just navigate the site and get a “You need to upgrade to Internet Explorer” or “Sorry, we only support IE” message. Worse yet are the sites with no warning at all… they just don’t work in Safari or even Firefox for Mac. The response to Mac users in the past has been “You are less than 3% of our user base” a flawed statement at best as it’s silly to equate overall marketshare sales figures of computers with actual people that use computers. Think about it, those marketshare numbers include computers used as cash registers, kiosks, and simple business machines. Until recently all sorts of businesses used the marketshare figures as an excuse for sloppy coding and lack of support for the open standards that Mac OSX is based on.

Now along comes the iPhone. Possibly the most hyped techno gadget in the universe, this little wonder will give its affluent consumer-owner a REAL internet experience… as long as the site they visit is compatible with the Safari browser. So all you “We don’t care about Macs” web developers look out. Some day soon one of your clients will ask why their boss can’t see the dynamic content on the company website on their shiny new iPhone and you’re going to fire up Internet Explorer and answer, “It looks fine to me. Tell your boss to use Explorer.”

And the boss will call us.

Imp Designs, iPhone ready since 1999.

When’s the last time you checked the WHOIS information for your domain name? The WHOIS database (Wikipedia entry here) is a protocol that allows one to see the contact information on a domain name. Although technically no one in the world really owns a domain name except the Network Information Centre (NIC), it’s generally accepted that the Registrant of the domain name is its legal owner. If you look up your domain name information and no one in your organization is listed among the contacts, you may have difficulty establishing your rights to retain use of the domain name in the event it expires.

A simple way to look up your domain name information is to visit the website of a domain name Registrar such as Godaddy and enter your domain name in the Domain Search feature of the site. Entering a domain name already in use results in a “(domain name) is already taken” message and a link to click for more information. Clicking that link will reveal the domain name contacts. There are four types of contacts listed: registrant, administrative contact, technical contact and billing contact.

The registrant is considered to be the legal owner of the name. In exchange for an annual fee paid to the domain name registry, the registrant is in effect issued a license to use a given domain name on the internet. A registrant may name an administrative contact to manage the domain name. It’s the responsibility of the administrative contact to keep the information on the contacts in the WHOIS current and to manage access to the domain name settings. The technical contact would typically be responsible for the name server settings for the domain. The billing contact is responsible for making sure the annual fee for the domain name’s usage is paid on time.

In practice what usually happens is that a business contacts a web development company and they obtain the domain name for the business. Since the developer typically maintains an account with a registrar, all contact information for the name(s) are initially set to the developer’s default contact information. At Imp Designs, we go back into our account and set the registrant information to match our client’s contact information. We leave the other contact information to point to us, since we usually take on the responsibility of managing the other aspects of the domain. If our client prefers to manage their own domain, we facilitate it’s transfer to new account. If you find that your domain name information doesn’t list anyone in your organization, start trying to contact those who are listed. A reputable internet company will not try to block your being listed as registrant. You should also have login information for your registrar in case you decide to move your domain or modify any of it’s parameters.

A little investigation on the status of your domain name can save you lots of headaches. It’s not unusual for this vital bit of information to get lost as most businesses initiallly buy 2-4 years of registration and then forget about it. Making sure someone in your organization is listed as the registrant contact is much easier than trying to re-establish your authority to use a domain name if it expires and no one in your company gets the renewal notice.

Our recent work for Ticon Properties presented us with a challenging problem: the efficient display of floor plans. Many real estate sites display floor plans by having them display in pop-up windows. After launching a few of these, a visitor’s desktop can become littered with pop-up windows making comparisons between plans problematic. We felt that the plans should appear on the same page to allow comparisons, but traditional coding methods could only achieve this by reloading the page each time another floor plan was requested.

Designer Chris Sloan began to look for a solution and soon “discovered” AJAX. AJAX (Asynchronous JavaScript And XML) is a relatively new technology which was developed to make interactive web sites seem more responsive. Basically it utilizes the JavasScript XMLHttpRequest object to communicate with a server without the reloading of a page to display new content. In the Ticon site, it allowed us to load requested floor plans without having to reload the other elements on the page. Here’s what Sloan has to say about AJAX:

“With AJAX being a new technology, there is still a lot of buzz going around. Here at Imp Designs, we are just waiting to hear what Jakob Neilsen will cry and whine about with AJAX! As for right now, many people are praising the use of AJAX. Apple Computer utilizes AJAX found in some of their new applications and Google uses it with both their GMail email client and their mapping API. Many developers are creating “tool kits” to help the ease of interacting with the XMLHttpRequest object. A great tool kit that we have used is called SAJAX.  SAJAX is OpenSource BSD and takes care of all the code for different browser support, connecting to the XMLHttpRequest object, and processing the functions you pass to it through the server-side scripting language.  If you are at an intermediate level with JavaScript and your choice of server-side programming, a good tutorial on how to get started with AJAX can be found here. This will show you how to call the XMLHttpRequest object and gives examples of the JavaScript functions to process your server-side functions.

“There are many possibilities where AJAX can be used. I am finding out more about AJAX each time I work with it. As a web designer, I feel that AJAX is a great tool to help the web progress forward with usability standards.”