Here’s a trip: I was interested in learning more about how to make a URL more findable and when I Googled it (findability URLs), the 7th entry down was from Aarron’s blog! I read through his articles and found the general guidelines about URLs – i.e., adding keywords to your URLs make them more findable. I also found specific info suggesting incorporating the title of a blog post into the URL, and instructions on how to do that with WordPress. However, what I was interested in is something Aarron had mentioned in class that I didn’t catch – it was something about why you use hyphens in a URL as opposed to underlines.

Hmm. Back to Google. . . this time, try: findability URLs hyphens.
Success! I found an article (‘Google test: hyphen and underscore’) that explained exactly what I was curious about. Here’s what I learned: If you separate words with hyphens (in either a URL or the body text), Google registers each word as a separate keyword. Thus, Google would see ‘red-rose’ as having ‘red’ as a keyword and also ‘rose’ as a keyword. However, Google reads an underscore as a way to connect the words. So red_rose would be seen as a single keyword: ‘red_rose’. Yea! I learned something!

Hey! I at least just found out how to make categories for my blog! Awesome! Ok, so now on to what I just learned that I thought was totally cool.

I’ve been reading about how search engines don’t spider JavaScript. That’s been sort of a meaningless, no-context, ho-hum statement to me. However, I just found this article on SitePoint that livened it up for me and suddenly transformed it into something that’s REALLY cool. The article is ‘Avoiding the 5 Most Common SEO Mistakes’ by Johnathon Smith. In the article, he provides a real-life example of a site that gathered hot “deals” from around the web and aggregated them in one place. It was a great site but because it was coded with JavaScript, no one was able to find it. What the author pointed out (which was brand new info for me) was that if the web developer had coded the same thing with a server side language such as PHP, the aggregating would take place on the server, leaving the page with spider-legible HTML. Now THAT’S a concrete example that brings it alive for me.

I have been having horrible writer’s block on these posts. Being an “I wanna understand it” person at heart, I’ve spent some time trying to figure out why. Here’s the deal:

1. I feel totally out of my element in this class. I feel like I’m back in 33 RPM-land while everyone else in class is spinning CDs and DVDs.
2. The assignment specifically says we’re not to write personal posts and that’s what I do best.
3. The whole point of this course is to learn about findability and we’re supposed to use the techniques we’re learning to make our blogs more findable. To be honest, with the state of my learning at this point, I’d really rather hide my posts so no one CAN find them. (It’s probably not a coincidence that I titled my blog ‘To Find or Not To Find’.)
4. In short, I feel dumb, not up to the task, and that there’s no way in heck I can play catch up quickly enough to come up with anything important to say that wouldn’t be old hat to everyone else in the class.

So that’s what’s tying me in knots.

Now. I also know what DOES work for me. What works is for me to find something that sincerely interests me. It may well be kindergarten level compared to where everyone else in the class is but if I don’t worry about that and just write about what I learned, I’ll be fine. And I’ll learn stuff. The stuff I most want/need to learn. AND . . . I do want to learn about findability. I have a web application I’m hoping to market some day and heck YEAH I want people to be able to find it. So to be honest, I pity the person who finds this blog but maybe I can think of just using it as a vehicle to learn things I’m sincerely interested in learning.

There. 343 words of sheer personal indulgence to help me break through my writer’s block.

I was first introduced to HTML around 1995 or ’96 through some tutorial types of courses offered by America Online. Tables were used for layout and the font tag was applied liberally. Although CSS got an occasional nod, the topic of accessibility was almost completely ignored. If anyone dared ask about it, they were told that it was very complex, unsupported by browsers and in short, not worth messing with. My, how we’ve changed.

Andy Hagans has pointed out that accessibility is an important factor in findability. If a person who is physically challenged in some way can’t make sense of a website and find what they need, chances are that a search engine would not be able to, either.

The accessibility standards are presented in priorities:

Priority 1 checkpoints. These must be followed or one or more groups will find it impossible to access information on your site.

Priority 2 checkpoints. These should be followed or one or more groups will find it difficult to access your information.

Priority 3 checkpoints. These may be followed to improve access for one or more groups.

To be honest, the accessibility standards still seem complex – or at least, lengthy. However, with increasing browser support for the standards, it behooves us as web developers to roll up our sleeves and get a bit dirty as we figure out how to apply these standards to our sites.

Reference: W3C: Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0

To Find or Not to Find

This is a rather odd time. I find myself in a class on the topic of findability at the same time I’m trying to build an application that will hold sensitive data that specifically needs NOT to be found. Using the maxim that often one learns the most about a thing by trying to figure out how to avoid it, the posts in this blog will meander around in both territories: to find, or not to find. And if, perchance, I happen upon some outrageous fortune along the way (preferably without the slings and arrows), so much the better.

That said, a logical place to begin seems to be with a discussion of Web standards. Without this common foundation, neither findability nor unfinadability has much of a chance. The following steps are essential for good Web standards:

• Include the correct doctype: Doctype stands for Document Type Declaration (DTD) and its purpose is to tell the browser which version of (X)HTML was used in coding the page. It must appear at the top of each page and be exact in both spelling and case. The W3C has a list of recommended doctypes.
• Keep the following elements separated from one another:
  • Structure (HTML, XHTML, etc.)
  • Presentation (CSS)
  • Behaviors (JavaScript, PHP, etc.)
  • Content
  • This practice includes avoiding inline styles and inline JavaScript event handlers as much as possible. (The latter is called unobtrusive JavaScript.)
• Validate all code. Make sure all code you write is well-formed and passes the W3C’s validation tools.
• Use meaningful terms for id and class names. For example, using divs for the layout of the various sections of your page and giving them ids of header, leftNav, mainContent, and footer makes the structure of the page clear, just from reading the names of the ids.

This list is only a beginning but it’s an important one. Following these rules is essential to content that can be found as well as content that should remain hidden.