So for a couple projects in the past year I’ve utilized the Google Search Appliance (here forward called the GSA). The GSA is a powerful tool – it’s like your own slice of Google, only you can customize it, and in theory, tweak the algorithm and manipulate your results. Like a “SEO box” – but to my understanding, the algorithm is different, but in theory it’s the same.

The Versions of GSA

I’ve worked on a Google-mini, the Virtual GSA (version 5.0, no longer offered for download, for shame) and a 6.0 GSA. In terms of front end coding, you manipulate the XSL/XSLT code to change the default appearance. It’s cool – you can get the power of Google without the “branded” Google crap you get from the customized Google. So – your own branded, somewhat manipulatable Google box. Cool.

What is Google?

Of course, Google is not Bing. It is not Yahoo. It is not a commerce engine – it is a relevancy machine. The sole purpose of a Google crawl is to gather documents, have you execute a query, and for Google to say:

“I think this is what you want?”

At least, that’s *MY* experience with the GSA – they have a capability referred to as “Results Biasing.” This allows you to “influence” the results. My issues with this, is that you can make changes, but without arduous testing, you are never sure how long it’ll take the results to show up changed.

You can force a recrawl, but it seems the GSA “caches” the prior results for roughly 15 minutes. That means to tweak your results means retesting every 15 minutes, and even with results biasing, you may still be out of luck. It’s a crap shoot. A coworker and I spent several hours manipulating and testing results, only to eventually make one result bump up one slot, and we were working against tightly knit test set – we basically had 500 pages that were pure keywords and some other custom attributes to be utilized through a customized “Search As You Type” functionality.

Search As You Type

Yes – this was cool. A mix of plain JavaScript and PHP that essentially created a JSON result of your Google Search query. It’s a very cool project, and it allowed for some very unique experimentation with the results of a google query. I can’t delve into it to much, but we manipulated the data to spit out the results in a different display, for a more “spread” experience and relevant results. Very cool.

The Lessons Learned

I think the most difficult thing about the work was digging through the documentation – it was somewhat inaccurate at times, and very often some important, pertinent information was often in a single sentence, in some random blurb. Like Meta tag length limits (320 characters). Agitating, but we were able to rewrite our original meta tag code (to be better, in my opinion) to generate structural details in the PHP vs. including it in the meta data (it was a prototype stage, okay?). The only problem was the keywords were still being stuffed – way too many repeats and useless character phrases. This is a matter of education to the client, and clarifying that the GSA was not a “easy to manipulate” set of data – it was a complex beast, and that in ANY kind of manipulation should be taken with a grain of salt.

By no means is this article definitive, and, to be 100% honest, totally accurate. I spent many emails and phone calls with Google Support (which was a decent experience, I’d dare say surprisingly so) to come to many conclusions of our work arounds and test data issues and uncovered new information (little nuggets of wisdom) hidden in the documentation, and even uncovered a few inconsistencies in the documentation (from 2009) in terms of how the GSA was handling result diagnostics.

It’s a powerful tool – but it’s not EXTREMELY customizable to fit every situation. I wish the had more “virtual” instances (like the VGSA they had) of all their products. I’d love to really see the full capabilities when you don’t have to drop a ton of cash just to play with some hardware.

This article is not about learning CSS. It’s about having a set architecture in a project when moving forward. One of the first things in beginning development is setting in place a best practice procedure when moving forward – it’s not saying “there is only one way”, it’s saying “for this project, this is how we are moving forward.”

Rule: Choose a Browser Reset Style Sheet

Choose one, or don’t use one.

This helps you on your cross-browser journey. If we reset all browsers to zero, it allows you to spend less time figuring out why margins are inconsistent amongst your unordered list elements (<ul>). This also sets you up to have a default font-family and consistent font-sizes, line-heights, etc. This is most important when cross-browser similarity is a high-concern.

CSS Resets are Bad, M’Kay?

Jonathan Snook stated that he “…okay if the various browsers show things slightly differently.” Jens Meiert also states CSS Resets are bad because they essentially add up to a defined style being overwritten repeatedly, adding to network latency due to the multiple requests for CSS. Then follows up with the comment of using * { margin: 0; padding: 0; } which itself is a bit of a hack and causes performance issues.

To be honest, the argument that CSS Resets/the * hack are a bit of a red-herring. For the majority of clients/sites I’ve worked on, this has been an incredibly minor concern. We’re talking milliseconds. Not even on the radar type performance hits. If you want to squeeze every millisecond (and I do) this is kind of an extreme (even for me) case.

Unfortunately, not all of us are as lucky as Snook and we work with clients/creatives that are not okay with things being a few pixels off sometimes. Personally, I’m with Snook.

Should You Choose To Reset

You have several to choose from:

• Toby Miller’s Equalizer
• Eric Meyer’s Reset
• YUI’s Reset

Rule: Link States

This is referred to as the “LoVe HaTe” rule. :link :visited :hover :active
This relates to CSS specificity, below.

Rule: CSS Specificity

Eric Meyer has a great article on CSS specificity in general that I find lame when sites try to duplicate his article with their own “twist.”
I fully admit, I suffer from over specificity. For good measure, you can read Google’s article about CSS specifity and the increase in performance by using effective CSS selectors.

To reiterate certain aspects, DON’T put a class and ID on everything.

div.imageHolder img#imageHolderImage /* this is BAD */
div.imageHolder img /* this is BETTER */
.imageholder img /* ding ding ding! we have a winner! */

As well, don’t code things inappropriately, i.e. use nested divs/p to generate what is essentially an unordered list.

Test
Test




Target the first item
General list item
Target the last item

Rule: Naming Convention

We won’t dwell on this. BE GENERIC. It’s better to have “.active” or “.select” and NOT “.greenActiveText” – what happens when green active text becomes orange? Now you have a poorly named class.
Also, pick a naming structure and STICK TO IT. camelCase? Dashes-instead? Hell_underscores_are_okay, AS LONG AS YOU ARE CONSISTENT. Do not change it up. This is extremely important walking on to a project. If you walk in and the prior developer is doing it different than you are used to, ADOPT THEIR STYLE, DO NOT REWRITE IT, ADD TO IT, OR MAKE IT MORE COMPLEX THAN NEED BE.

Rule: Shorthand

Use it. Know it. Love it.

div {
	background-image: url("to/some/image");
	background-repeat: repeat-x;
	border-width: unit;
	border-style: (solid dashed dotted double);
	border-color: color || #hex || (rgb / % || 0-255);
	color: #669900;
	margin-top: 10px;
	margin-right: 9px;
	margin-bottom: 8px;
	margin-left: 7px;
	padding-top: 10px;
	padding-right: 5px;
	padding-bottom: 10px;
	padding-left: 0px;
}
div {
	background: url(to/some/image) repeat-x;
	border:border-width border-style border-color;
	color: #690;
	margin: 10px 9px 8px 7px;
	padding: 10px 5px 10px 0;
}

Notice the “0″ has no identifier. It doesn’t need one. Notice 13 lines became 5. Love that. We also dropped the quotes to prevent any possible browser errors. Get to know your CSS shorthand.

Rule: Browser Targeting

For the love of God, they’re called hacks for a reason. They are hacky. They shouldn’t work, but do. You could fuck another browser down the line. You could introduce errors. DO NOT USE BROWSER HACKS This is a bigger sign that *you* are a hack and a not a proper developer. These are the “once in a lifetime” things that come up.

Except for IE.

Fortunately, IE has a nice, clean targeting system. Conditonal comments. If you target IE, use Conditional Comments.

Rule: CSS Behaviors Require JavaScript

If you’re writing CSS Behaviors, move it into JavaScript. Plain and simple. There is no reason to have CSS behaviors. At all.

Rule: Organize Your CSS

I know this one can be a bitch. The project can change. Your initial strucutre may not make sense. But try to organize it to prevent redundancy.

Alphabetize Yo’ Self

I alphabetize my CSS because I find it easy to read, search, and peruse. I also use a code highlighter in jEdit. Others group it by property (font styling, positioning, dimensions). I prefer my way, but that doesn’t make it right. Just when I’m leading the project.

Rule: Comment, Comment, Comment!

Comment the shit out of anything you are handing off. Eat the bytes. But don’t go crazy. /* this is a comment */ not /*——————– (several lines of this) CODE COMMENT (repeat several lines) ———-*/ Keep it simple. Keep it common sense. Break it up by section (however you organize your CSS).

Rule: The DO NOT Do List:

Don’t do these.

Don’t Use Inline Styles. Period.

Inline styles defeat the whole “separation of content and design.” Maintenance becomes a bitch, frankly. You also add to page weight, and can cause issues when a developer doesn’t realize you’ve done things inline and their properly coded external styles are not working properly.

But Keif, I do this all the time in development… – that’s fine, Timmy, but if you “accidentally” leave one in to production, or check it into SVN/CVS/Git and try to act like it’s not your fault, you’ve proven the point why you shouldn’t do this.

Reuse a “Standard” Set of Specific Styles

I don’t mean reset. I don’t mean element specific/font styling type items. I mean don’t use classes that are specific. #width100 .marginLeft25. This is representative of bad coding in general.

Now, this is a brief overview of many “best practices” I try to run with and improve upon. Google CSS Best Practices and you’ll find a slew of additional resources. Not all of them will agree with me – but that’s not the point. The point is understanding them, and recognizing that someone else’s preference may override your own, and my not be technically wrong. If you fail to recognize this, you need to reconsider your role and what you’re doing – you need to be both a team player that can adapt and evolve, and an innovator should you be charged with leading the effort.

What do you have? Send me your best (or worst you’ve seen!)

A constant debate is always “why support IE6? It’s expensive, it’s annoying.”

Now, I’m not disagreeing with that. I don’t like IE6. It’s old. It’s broken. I’d prefer it went away. Unfortunately, IE6 represents over 30% of all IE traffic (which represents roughly 64% of all internet browsers).

It’s not representative of my site.

If you pay attention to your browser metrics, you can see that IE6 is not representative of your site. At all. You can see this as a green light to ignore IE6 (particularly if it’s an intranet or members-only site, as you can dictate browser requirements as a “bare-minimum”). If you’re a blog, I’m all for ignoring IE6. I encourage more sites to do it.

Now there is one slight flaw with that argument. What if your site gets dugg? Slashdotted? Attached to a virus and spread? Date Is ay it – maybe an article you write goes viral?

Some Microsoft This Way Comes

Outside of a sudden surge in popularity, the other *very realistic* look is e-commerce sites. I don’t care who you are, a dollar is a dollar, and as such your e-commerce site better accommodate every visitor. No flash reliance, no JavaScript reliance. Period. I don’t care about it looking the same, but I better be able to make a purchase via Lynx. More importantly, any handicap should be accounted for (blind is the most often thought of). This is what we call Web Accessibility. All angles should be covered, within reason. And IE6, regardless of your metrics, is within reason.

AlphaImageLoader – Ye Olde Standard

I think anyone who is “in the biz” knows about AlphaImageLoader. We’ve all done the CSS replacement. I helped adjust and edit a MooTools Class that utilized it to account for all sorts of PNG situations. It was our “standard” because it was able to account for IE6 with a minimal amount of effort. Except…
AlphaImageLoader does not support background-repeat, or background-position. It requires set heights and widths. It requires one-off styling for images that are cropped. Plain and simple, it still sucked.

VML – The New Contender

I stumbled on a VML solution after researching a site to see how they were handling PNGs. It turns out they were utilizing DD_belatedPNG. I dug into VML vs. AlphaImageLoader and came across this article explaining the same thing – AlphaImageLoader or VML.

The obvious is pointed out: AlphaImageLoader eats memory. VML adds bad markup to a page. IE6 does *not* cache the image (according to the article, at least).

So, we’re stuck with a memory hog or a lot of image requests against a server, which can add to a lot of bandwidth costs if your traffic spikes (it happens).

Will The Real Slim Code Please Stand Up?

After reviewing DD_belatedPNG a second time, he claims to “mostly” have fixed the caching issue. To be honest, with as much grief I’ve had from AlphaImageLoader and changes in creative layouts that require PNG transparency, it seems like a real replacement for AlphaImageLoader, loaded using JavaScript and conditional comments so ONLY IE6 takes the hit.

The downfalls? No opacity on the VML. I haven’t looked into creating a container to wrap the VML and fading that, but call me crazy, it may not work. This means we may have to keep AlphaImageLoader around for a little while longer. I’m not sold that either solution will replace the other, but they both are going to be invaluable until IE6 goes the way of the dinosaur.

Performance Concerns? Not with VML.

Thank God someone else ran the numbers. Tests have been ran, and also Yahoo! provided some additional numbers to help showcase that VML is not the memory hog AlphaImageLoader is. Bonus!

There is the argument that a PNG 8-bit image is a better solution. No CSS hackery, no JavaScript intervention. However, it requires whomever the developer is, and also whomever the designer is cutting up your graphics to be familiar with proper image optimization techniques to insure an efficient, optimized experience.

The REAL Solution
The priority of the solutions seems evident. PNG 8-bits for most cases. VML through most others. AlphaImageLoader only as absolutely necessary. I do believe that a JavaScript solution is the best solution for IE6 AFTER 8-bit PNG images (ran through a PNG optimizer (like PNGCrush).

Unfortunately, such optimal solutions require trained developers and trained designers. Who has time for that? You should make time to insure success.

Enjoy.

When you start developing in any JavaScript framework, you’re stuck wondering where to begin. Everyone’s got a tutorial, and an opinion, but when you’ve got “an idea” and just need to delve into the code to make it happen (say… porting functions? Figuring out the basics?) then sometimes wandering through the API isn’t the best thing you could do.

Suggested Dojo Reading

Sitepen has provided a nice primer on the basic functionality most people start off with in their library investigations, but where to go from here?

Is like a more detailed view into the Dojo API. I’d start here if I wanted to peruse the API in a more logical way then in their API docs.

I suggest reading the Dojo Basics from Dojo Campus to get in deep with querying elements and Dojo Quickstart Events to figure out attaching events.

Understanding Dojo Toolkit

The more I use Dojo, the more I see correlations with Java – and that’s not a good thing. In Java, you have JavaDocs telling you about the thousands of Java functions, parameters, returns you can have. VERY powerful. VERY difficult to learn. Most of the JavaScript frameworks took a different approach – they made what they did powerful, but kept it simple. Easy to read, easy to peruse – like the PHP docs (in my opinion). the function names and organization make total sense.

In Dojo, it doesn’t feel as quite intuitive – for me – and that’s it’s biggest downfall. It has a high barrier of entry, and a large, robust, sophisticated toolkit that you aren’t really expected to know every inch of (like Java), but understand the basics and have an API to refer to when you want to do the more powerful functionality.

Unfortunately, Dojo still feels like it’s in the infancy of this aspect, as navigating to the more complex aspects is a pain. Should my Dojo work increase in the near future, I may invest in a book to try and become more acquainted with the more difficult aspects.

Accessibility in the Framework

I’m seeing inklings in their code with reference to WAI, but I haven’t even *attempted* to fool with that in any accessibility sense. As my current projects haven’t adequately been in need of WAI guidelines, I’d love to see a more thorough analysis.

I am a MooTools JavaScript developer. I love the framework, and in writing MooTools code, I’ve become a better Object-Oriented-Programmer, and a better JavaScript developer. If you follow technology, you know there’s multiple JavaScript frameworks – jQuery being the most popular (IMO), with Dojo Toolkit being the most used in enterprise applications.

After having used JavaScript libraries (originally prototype/scriptaculous, some Moo.FX, then jQuery, then MooTools, and currently a project using Dojo) you come to expect a certain amount of consistency in general concepts, and in that expectation, the libraries have delivered.

$, $$, dojo.query, dojo.byId, document.getElementById – give me my element nodes!

So, basic JavaScript, people have developed a few different ways to get the elements they want, including custom functions – like Robert Nyman’s getElementsByClassname – which take advantage of local browser support, but you’re still forced to account for those without it. *cough*IE*cough*

MooTools uses the $ or $$:
[code lang="javascript"]
var idEx = $('someId'); //get element by ID
var arrayEx1 = $(document.body).getElement('someElement'); // return first matching 'someElement
inside of 'someContainer', or document.body in this example
var arrayEx1 = $(document.body).getElements('someElement'); // return array of 'someElement' (or class name, if you have the right components downloaded) that are contained inside of 'some container', or in our example, document.body.
var arrayEx2 = $$('someElement'); // return array of all found 'someElement'
[/code]

Pretty powerful stuff, for so basic an idea.

jQuery is kind of similar:
[code lang="javascript"]
var someArray = $('someElement'); // return an array of those elements/that ID/etc.
[/code]
Very powerful for a single selector – but it has the added bonus that they’ve allowed it to be overwritten, so you can use jQuery with another library (say, MooTools) that also uses the $ selector. It took me a little bit to get used to the return of an array outside of a single element.

Dojo does things a little differently
[code lang="javascript"]
var someArray = dojo.query('someElement'); // return an array of elements
[/code]

The get(’selector’).get(’selector’) (like mootools $(some).getElements(’someElse’)) can be pulled off in dojo/jQuery, but perhaps not as intuitive, in my opinion (again, I’m biased as a long-time MooTools fan/developer).

Which is better?

I can’t say which JavaScript library is better. Perhaps more-so, I don’t want to. It’s moot. You pick the library you’re most comfortable with, and most importantly, for your Clients – you pick the one that they’re development team can run with for the long-term.

How to choose a JavaScript Library – the condensed version

I’m a life-long student, and a professional developer – I’ve coded many languages, and I’m learning others, so it’s easy to see certain correlations that have started popping up.

MooTools… is definitely for the JavaScript Developer, and if you’re Object-Oriented as well, it’s even better.

jQuery… is for the designers out there who know some xhtml and want to get some JavaScript without dealing with the headaches it can bring. It’s go ta low barrier of entry, but I’ve thought of this Thomas Jefferson quote:

That which is Popular is not always Right, what is Right is not always popular

Don’t read too much into that. I just infer that people that say it’s “the way” have some additional education to do in general.

Dojo… is for the Java Developer crowd. As I’m delving more into Java, I see the strong similarities, and see why it’s involved in a lot of Java-based enterprise solutions – you could jump back and forth between Dojo and Java and feel pretty comfortable.

Coding Syntax, Preference, What’s Left? DOCUMENTATION!

This is the area most things suffer in – either too much or too little documentation. I’ve grown fond of MooTools docs structure. It’s easy to find what I need with it’s break down of how the functions are applied – string, array, elements… Easy!

jQuery docs are along the same lines, but I have difficultly in navigating them. I blame myself because of my long-term familiarity with MooTools, it’s become second nature, so jQuery is still slightly foreign.

Dojo docs, in my opinion, are the WORST of the docs. They’re broken down into their three main components (dojo, dijit, dojox), but beyond that it’s a guessing game to get to the API reference you want/need. I was finding myself hitting the wrong sections because the search led me there, but it was not representing what I was searching for.

I really feel their Dojo Campus is a much better doc representation than their dojo book, or their API docs. Their book is incomplete, and if you search and find references to the book, you’ll find items incomplete, moved, referencing different version of the book, to the point you’re better off not even reading it. Along with the occasional example randomly not loading, then working, then not. It was a nightmare!

The problem – perhaps the only problem – with Dojo Campus, is the search functionality. It defaults to “title search” which failed for me 99% of the time (because I needed something in the content, and was searching for the wrong titles). Even worse, the search isn’t even featured on the home page! I had to go four clicks in until I stumbled upon it for this post. (It’s accessible in two: Click on Tutorials and one of the options)

To my understanding, the Dojo Campus is going to become the “new” face of Dojo. And with their continued improvements in coding it’s becoming a stronger contender, and more importantly, more user friendly.

Examples from the frameworks

Every framework suffers from this. Outdated examples, drastic version differences that break code, or multiple version examples. MooTools and jQuery, for the most part, are pretty solid. Dojo, I hate to pick on you, but this is where you hurt the most. I googled – a lot – and the demos – official, sitepoint, others – are all over the place. Version 0.4, 0.9, 1.2.3, 1.3… and what’s worse, no one indicates what version the demo is in, so when I started looking at Sortable Tables, I find out it was made obsolete in another version. Links to non-existent pages in the dojo book… a mess!

In my own projects, it lead me to re-write a lot of items that existed in Dojo, but for a beginner with their library I ran into way too many issues to make it feasible to spend any more time playing with the code.

Overall, my impressions have not changed

MooTools is my favorite, jQuery is a recommended secondary, and Dojo is reserved as a “use it if you have to.” They pretty much throw the W3C to the wind with their coding structures – those dijits generate a mess of divs and classes as a default, to the point that I see the benefit in their examples, but in most of my scenarios, it was overkill (and my fellow devs would kill me if I ever coded something in that spaghetti menner).

It really showcases a difference between people that code for the front-end, and those that work with the front-end but primary experience is the back-end. the code makes sense to the extent in relation to Java code – but in comparing it to the majority of front-end applications, it’s a nightmare.

This is just the basic code you’ll find EVERYWHERE on the net. In an effort to be more like Scoble I want to start posting in regards to stuff I’m using/finding/reading to make future efforts in reuse easier – delicious only goes so far, in regards to remembering “what did I tag that with?”

The PHP Function to Update Your Twitter Status

[code lang="php"]
<?php
/**
* A simple function using Curl to post (GET) to Twitter
* Kosso : March 14 2007
*
* Feel free to do what you like with this.
* It's pretty easy. But I thought I'd just put it out there.
* Curl is your friend.
*
* usage : postToTwitter("myusername","mypassword","hello twitterati! I'm posting this from a PHP script! woo!");
*/
function postToTwitter($username,$password,$message)
{
// GET the API url via web authentication
// add 'status' param to send a message to Twitter

$host = "http://twitter.com/statuses/update.xml?status=".urlencode(stripslashes(urldecode($message)));

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $host);
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));

curl_setopt($ch, CURLOPT_USERPWD, "$username:$password");
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_1_1);
curl_setopt($ch, CURLOPT_POST, 1);

// Go for it!!!
$result = curl_exec($ch);
// Look at the returned header
$resultArray = curl_getinfo($ch);

// close curl
curl_close($ch);

//echo "http code: ".$resultArray['http_code']."<br />";

if($resultArray['http_code'] == "200")
{
echo "<br />OK! posted to http://twitter.com/".$username."/<br />";
} else
{
echo "eek! yegads! error posting to Twitter";
}

// debug the result
// echo "<pre>";
// print_r($resultArray);
// echo "</pre><hr>";
// $sResult = htmlentities($result);
// $sResult = str_replace("&gt;&lt;","&gt;<br />&lt;",$sResult);
// echo "<pre>";
// print $sResult;
// echo "</pre>";
}?>
[/code]

I credit Kosso with the PHP function – it’s basically a slightly more blown out version of the code flaoting around.

It’s weird that I swear David Walsh follows me around – everytime I have a conversation with someone about something, he writes an article about it – like preventing your css and javascript from being cached.

I had come to the same conclusion (from by conversation with Toby) that random querystrings being appended didn’t make much sense – that prevents caching, but why stop caching – unless the file gets updated?

I wrote a little php function that works with filemtime, albeit it requires the absolute path of the file.

[code lang="php"]

function autoVer($url){
$path = pathinfo($url);
$ver = '.'.filemtime($_SERVER['DOCUMENT_ROOT'].$url);
echo $path['dirname'].'/'.$path['basename'].'?'.$ver;
}

[/code]

What this means, is when we call our files like so:

[code lang="php"]

It renders like so:

[code lang="php"]

[/code]

So only when your file gets updated, does the query update, forcing the cache invalid!

It’s a simple function – and by no means perfect. Would you refactor it, or do you have a better way?

Shawn Morton may have beat me to the punch – both in writing about it – and a quick iframe demo of the Skittles idea.

The general point (in terms of Web Development) is that this is an insanely simple thing to accomplish – 15 minutes and Shawn had a working iframe demo.

I wanted to grab some of the effects and colors of the original, just to see if I could do it and “make it fancy” – I mean, there’s still a half-dozen effects that can be applied to it – fades, transitions, all those whizz-bang-pow stuff people love, but I had to pull myself back a test was important.

Skittles.com Initial Test

I decided to focus on Firefox 3 so I could use rounded corners in CSS (there’s a JS library for everyone else, sans Webkit, but hell, remember, this is a test. No one’s paying, so I’m not worried about IE.

It took me a couple hours, but here’s skittles.com, reproduced without flash.

I’m too tired to write more, so – here ya go.

You Flashed My Google

So Mark Scholl pulled up this nugget of a gem from an October post from Brian Ussery announcing their intent to start indexing flash.

I recall reading this in October, and quite a few people were excited about this – it means the old argument that “Flash isn’t SEO friendly” would boil down to “if you’re a good Flash developer, your stuff will get indexed because you wrote it properly.”

What’s interesting, is the article dives into the fact that the SWF/Flash files will carry their own rage rank – and as such, if you reuse the same SWF on more than one page, keyword thinning can occur (you’re using duplicate content).

So – it’s been a few months, I was curious just *what* was being pulled in by google in terms of flash content, and what was being shown. I used a simple google query that it seems most people have forgotten about.

Custom Google Search – FileType

search: filetype:swf site:ikeif.net

It’s that easy. Run this with some search terms and see if your site’s flash is being indexed like you hoped it would.

Of course, I felt like playing around and seeing what’s happening in the wide world of flash…

How’s my Flash being indexed?

I ran a couple searches against some sites to see how they were being indexed:

Query: filetype:swf site:nationwide.com – What’s interesting is their flash is being indexed (I’m assuming) properly. The descriptions make sense, until you hit number 8 that says “PLAY AGAIN. PLAY AGAIN. 0%”

Query: filetype:swf loading – I did this out of curiousity – much like how it’s been stated that “click here” is the worst possible wording for a link – over three million results for swf’s that say “loading!” Semi-interesting: The number one link is a flash USA Map Test.

Query: filetype:swf site:remhq.com and filetype:swf site:kanyeuniversecity.com – I figured I would have to do a couple band sites, as bands and labels were usually the number one commiters of flash atrocities. These two were high ranking when I searched for “band sites flash” (simple, yet effective). Kanye? Three links. REM? Four pages, all with some pretty good descriptions.

Query: filetype:swf site:roushhonda.com – As I recently moaned about the fact that so many car sites rely too heavilly on flash (mainly because I couldn’t hit their sites on my iPhone). All those listings in flash, none of it being indexed. I settled on Rousch from a search for “used cars columbus“.

We’ve come a long way, baby.

So – we see some areas of needed improvement. SEO for Flash is something that I feel needs to be addressed more often (by designers and developers!) and it’s something our SEO people need to keep in mind and discuss (I’m looking at you, Mark Scholl and Jennifer Laycock!). As this is slowly moving from the “I wish flash was indexed” to “Oh shit, it’s indexed, but not how I want it!” the discussions need to ramp up and we need to start thinking about it.

Find anything interesting in your own google queries? Let us know!

Edit: As Oskar points out, the MooTools can be more concise, so I’ve updated the code!Thanks Oskar!

So I’m a fan of unobtrusive javascript – that means I like avoiding “onclick”, “onblur”, “onfocus” etc. etc. I don’t like doing “href=’javascript:dostuff();return false;’”. It makes me cringe – in this day and age, everyone has their favorite javascript library, and they make event delegation damned easy to the point that I have to ask – if you load a javascript library on your site, why not use it?

Print this window!

Generally, those “print this window” links tend to be something along the line of:
<br /> <a href="#" onclick="window.print();return false;">Print this window</a><br />

or even:
<br /> // ewwww javascript in an href?<br /> <a href="javascript:window.print();return false;">Print this window</a><br />

Why do it this way? Why create a link that may not work?

The MooTools way:

MooTools is my rifle – I tend to focus on it first and foremost when it comes to thinking about UI.

Let’s take a “Print this Window” link and add a CLASS.

<br /> <a href="#" class="print-window">Print this Window</a><br />

Why CLASS over ID?

This is a valid question – some people like having things spelled out down to the letter, and they like their specificity. MY concern here is (recently) a client had a “print” link at the top and bottom of an overlay – IDs become invalid! So I prefer to keep that in mind at all times and code accordingly to the “what-if” scenario:

<br /> $$(‘.print-window’).addEvent(‘click’,function(e){<br /> new Event(e).stop(); // if you code your print link as a link, this basically does the same as “return false;”<br /> window.print();<br /> });<br />

ZOMG! So easy! And it’ll hit EVERY class with “.print-window”! This method will hit ALL elements, so you may want to tighten it up a little bit:

<br /> $(‘container’).getElements(‘.print-window’).each(function(el){<br /> el.addEvent(‘click’,function(e){<br /> new Event(e).stop(); // if you code your print link as a link, this basically does the same as “return false;”<br /> window.print();<br /> });<br /> });<br />

Now, why not search for “a.window-print”? Why use an “anchor” if it’s not going to be used?

To be honest – you don’t have to use an anchor. The class name is what’s important – you can make it a <span> if you don’t like using <a> or simply attach it to an image.

jQuery “Print this Window”

<br /> $(‘.print-window’)<br /> .click(function(){<br /> window.print();<br /> });<br />

Simply delicious! You may need to double check me on that – jQuery is my backup, the dillinger to my glock.

What if javascript is not enabled?

Gasp! The horror!

No doubt this is something that may need to be accounted for – and I’m all about accounting for it all. This also brings up the question – do we care if search engines see it? Are google searches for “print window” a maker or breaker? Really, for our purposes, they’re a “nice to have” function that adds no real added value to our page, and if you don’t care if a search engine sees it, there’s more than one way to jam this tune out.

For this, I like to use javascript to inject the elements in the page – javascript is needed to USE the link, so why not use it to make it available?

For this, it could be as simple as using CSS to HIDE the links, and javascript to SHOW the element, or you could go a step further and generate the images via javascript to begin with!

It’s kind of a pandora’s box – use with care!

If you haven’t heard – Ma.gnolia – the online bookmarking service experiences that horrible event everyone fears – database corruption, and total loss of data. Not just the “primary” database – they lost their backups as well! Needless to say, that sucks. At the very least, their home page now has an apology explaining that it’ll take days to get things sorted out. I wish them and their crew the best of luck. Those situations always suck, are never fun, and no doubt is causing a lot of lost sleep.

I’m not a Ma.gnolia user. I don’t know why I never joined – I was always a del.icio.us user and never felt the need to change to another service – I just needed something that let me access my bookmarks wherever, and I used it even moreso when the firefox plugin came out. I tag, I comment, I move on. I used to publish a collection of my recent links, but they were out numbering my posts.

Needless to say, Ma.gnolia’s issues made we wonder about the safety of my own bookmarks – I don’t back them up. Now sounds like a great time to find out!

Delicious Backups

The easiest, most obvious method is going to “Settings -> Export” – you can include your tags and comments, should you want, and it’ll spit out one humongous HTML file.

After a little googling, I found out from eConsultant that you can use this file a few sites:

• Blogmarks.net
• Feed Me Links
• Furl.NET
• Ma.gnolia
• Simpy
• Yahoo! My Web 2.0

It’s possible to output your bookmarks in XML using their API – but they ask that you use it sparingly.

Now, the additional “very cool thing” – they have a collection of third party plug-ins you can use – we’re talking plugin importers, API calls to PHP, Java, Ruby, Python, Perl, Lisp, C# and MySQLicious – that last one I’m interested in, possibly as making it a permanent addition to my main server!

Toby Miller has released his Mootools Enhanced Element Script to the masses on MooForum - and it’s a sweet idea that falls inline with how web developers often describe as “how they always code.”

How should Web Developers code?

Everyone has the basic understanding of how they should be coding – semantic, clean code. They should be coding with the idea that screen readers should be able to easily navigate the site (you know Target tried to fight accessibility in court?)

You should be starting with your content in mind – and often it’s always gone – Header, Body, Footer. But why?

Generally, we always assume people want the navigation (in the header) at the top. We then include accessibility links to allow them to be skipped. Download lynx and test for yourself - and then hit up some e-commerce sites and see how many use it (I know that Nationwide.com does, outside of e-commerce). Of course, this leads to the question – why include a link that is necessary when we can manipulate the appearance for visual browsers?

Content is King – so treat it as such!

Why do we lead with our navigation when it’s the content that matters? Content – Navigation – Footer – why isn’t this how a page is coded? It’s something I’m struggling to wrap my head around and start pushing forward with in my own code – to be accessible, and also to show it *can* be done. Code should be clean and simple! And I hope to see a return to simple websites in the future…

After you’ve got your clean, validated code – now you manipulate it with CSS – you take your skeleton and give it its skin and a coat of paint. Javascript enhances the experiment, and flash is the last piece (further enhancement, a plug-in experience). It’d be nice if the accessibility flash detection was reliable…

But on to Mootools Enhanced Elements!

This goes beyond the simplistic “is javascript available? Then add this ID/class to the body tag.” It goes beyond saying “if less than IE7, load this style sheet and javascript.” If you understand these ideas, you’ve got the basics of what Enchanced Element is about.

Yes – this is taking it up a notch. Adding classes, properties, custom elements and styles! I suggest reading the article and checking out the posts about it and looking at the site built with it!