That is, I didn’t find anyone, though they may well be out there.

I did find several references to a Google Maps helper, but, that didn’t help too much since I had an address and no geodata. The helpers I found looked, well… helpful once you had the correct data, mind you. Before you can do all of the maps-type stuff, you have collect the geodata and that’s where I came in.

I built a quick little script which takes an address and returns geodata. It isn’t a ton of code, it doesn’t handle paid accounts and it isn’t fancy. What it lacks in bells and whistles, it makes up for in pure, unadulterated Google Maps API query ability. Let’s have a look at how to implement the code.

First, download the file and unzip it. Place it in /app/controllers/components. That’s the bulk of the work. Once you have the component added to your components directory, just add it to the components array in your controller and call the getCoords() function like in the code below.

class FakeController extends AppController
{

     var $components = array("Googlegeocode");

     /* functions and whatever other code ... */

     function getGeoData()
     {

          $address = $this->data["ModelName"]["address"];
          $coords = NULL;
          if($address)
          {
               $coords = $this->Googlegeocode->getCoords($address);
          }
          $this->set("coords", $coords);

     } // End of function

} // End of class

There is more code there in general class setup and comments than there is in actually making the coordinate request. Note, do not URL encode your address before passing it into the function. This can have unexpected results as the geocoding component will properly encode the address for you.

There are a couple of other functions in case you need them. First is a call to retrieve the data set which is returned from Google.

// ... code ...
$geodataRecord =
     $this->Googlegeocode->getGeodataRecord($address);
// ... code ...

This will return an array built directly from the XML returned by Google. From this you can extract all of the information they typically return, including status, address information and geodata as well as several other odds and ends. There is actually quite a bit of data returned for each address.

Two other useful functions are the lastCoords() and lastGeodataRecord() functions. They are called as follows:

// ... code ...
$coords = $this->Googlegeodata->lastCoords();
$geodataRecord = $this->Googlegeodata->lastGeodataRecord();
// ... code ...

Once a record is retrieved, it is stored in memory until a new record is requested. You can refer to these as needed to recall the latest records retrieved from Google until the script finishes executing.

Though this isn’t the typical user experience related post, hopefully this will help you get moving more quickly on your project involving geocoding addresses for use with the Google Maps UI API. I hope you find my component useful and you use it to make the web a better place.

©2012 Chris Stead. All Rights Reserved.

Ultimately, it is rarely clear where boundaries are in a project. What is too much, what is too little? Somewhere between too much and too little is just right, much like what Goldilocks wanted in her porridge. We know that even the most limited of users should be able to access our sites within certain considerations. A photo gallery is, ultimately, little use to a blind person, but alt tags should still be in place. Sound clips of the Boston Philharmonic Orchestra would be useless to a deaf person, though a caption or indication as to what each sound clip is would be quite handy.

Coming back to the point, finding a balance point is critical to providing rich, meaningful interaction between your user and your site. Perhaps the first question which should be answered is “can this be done without Technology X?”

Technology X is always the hot technology everyone is dying to use. Flash, AJAX, CSS3, these all have fallen under the Technology X heading at one point or another. By using Technology X as your baseline interaction, you may be causing your users pain when you thought you were enhancing their experience.

A prime example of where Technology X is used when standard interaction would do is the Google login procedure. Many, if not all, of Google’s login boxes use AJAX for verification of user creds. It sounds cute and looks vaguely neat, but what happens when the browser barfs on their Javascript or you suddenly lose your internet connection? You have no clue what happened.

Your experience just took a nose dive and left you in the dark.

This is especially bad news for something like a login. Logging into a website should be a simple, straightforward, FAST experience. I want to type my creds, log in and be on my way to my dashboard. If something dies unexpectedly, I want a clean, clear indication as to what happened and why. If someone cut my ethernet cable in the next room, I want to know my computer lost network connectivity and that’s why I’m not seeing my dashboard in all its glory.

CSS is another item which can choke on users, leaving them feeling lost and confused. When things are hidden or altered with CSS in a way that makes them unreadable or unusable to the user, it can get ugly. The user sees a damaged site and moves along. Your rep falls to pieces and your user has moved on to greener pastures. This is especially true for people using Javascript to reveal something hidden with CSS.

The phrase “if it is to be shown with Javascript, hide it with Javascript,” carries a lot of weight with me. If your Javascript is going to die, it would be preferable that you err on the side of caution. Show everything. Make sure the page is as usable as possible.

So, the balancing act. I’m not saying there is no room for Technology X. The Technology X of today is the old standby of tomorrow. People will become familiar with new technology and learn to expect it. In the meanwhile it is important to consider what your user is aiming to do.

As a friend of mine likes to quote: Proper prior planning prevents piss poor performance. Know what it is your user is trying to accomplish by using your site. If they are there to purchase widgets, build a no-frills site which sells widgets. Use styles only to make the page more readable. Make sure everything makes sense without styles. Don’t use Javascript to do anything. Let the server do all the grunt work.

If you plan your site carefully and build something which is clear, usable and meaningful, adding Technology X will only make the site better. If something fails, your user will still be able to interact with the site and get things done. It may take them an extra click here or there, but it won’t be the show stopper it would have been if Technology X had been your only approach.

Balance is everything. Balance your plain site with your desire to incorporate interesting new technology. Just because it might be neat to see something done with AJAX doesn’t mean you should. Flash doesn’t solve all world ills. Sometimes a little bit of HTML a dash of simple CSS and some server-side elbow grease will do just fine. Build your sites for real use. Make your toys secondary. Think about your users’ goals and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

The user.

Several articles I found talk about the SEO benefits of pretty URLs and whether it is very important to consider using them with a site as they don’t encourage a major boost anymore. “It’s ten years too late,” they say. It’s never too late, I say.

Rather than bashing SEO experts that cry “content, content, content” let’s look at content and wrap it up in an easy to guess URL the user can make sense of. Peter Morville argues for findability, meaning users are more likely to use resources which are easy to navigate. Moreover, users will naturally navigate to whatever satisfices their information needs.

I wonder why users are forced to satisfice when pretty URLs make it much easier to satisfy by simple guessing. Unfortunately, something that stands in the way of this guessability is the combination of SEO professionals considering pretty URLs as a lesser sin combined with technologies which stand in the way of smarter URL writing.

Actually, I don’t necessarily wonder much, at all, why users are forced to satisfice when attempting to find something on a site through URL guessing. Much of the available technology on the internet is fairly limited when looking at URL rewriting.

When working with PHP, Python, Perl or anything else that works well with Apache, rewriting is easy. If you are working with Java or anything that runs under IIS, rewriting gets tricky quickly. Some of the technology which lives under the skin of the web gets a little ugly when you want to start doing pretty things. We’ll talk about overcoming these obstacles soon.

See, here’s the issue. We really want to do URL rewriting, not maintenance-heavy URL trickery. I came across an article about creating pretty URLs which claims it is “pretty easy.” Technically it IS easy but the suggested method is to make a directory for every page and have a single index.php or index.html page in the directory.

Using this method is a one-way ticket to sites you’ll have to manually manage forever. If you are a maintenance thinker, this is fine. If you want to solve the problem correctly, once and for all, you’ll want to do a little URL rewriting, instead.

In case you are new to the idea of URL rewriting, here’s a quick overview. When someone arrives at a site using a URL of the following form:

http://www.chrisstead.com/search/url rewriting

The server captures the URL which was used and then works a little magic, making it look more like the following:

http://www.chrisstead.com/?s=url+rewriting&submit=Search

Which makes the whole URL much MUCH easier to manage and manipulate by, in this example, a PHP script. There are a couple of different reasons we would want to do this kind of rewriting. Let’s take a look at them.

Note: Yes, those both work. Give them a try!

Rewriting hides the underlying technology. This might sound like a strange thing to want to do, but there is learning in my lunacy. People interested in compromising your site will use any knowledge they can get to take advantage of common little flaws and loopholes. By disguising what technology you are using, it sets up a roadblock, making your site less interesting to attack. This isn’t really what I wanted to write about, however.

Rewriting makes gives you the opportunity to make your URLs guessable. If users start to notice a pattern in the way the URLs are structured, they can take advantage of the common themes. This means it is easy for the user to guess how to get to something they want directly and just type the URL. This might seem like kind of an obscure goal, but let’s look at something a little more reasonable.

Suppose you are a music retailer. If you write scripts to handle URLs like the following, your users might not be particularly keen on trying to guess how to rewrite things to find something else:

http://www.mymusicsite.com/query.aspx?s=records&key=LKIH8hi7iKJbkjykjBJ&artist=some%20artist

This looks a little intimidating to me and I know what I was trying to say. Let’s suppose you, then, rewrote URLs instead so what the user sees is this:

http://www.mymusicsite.com/search/some-artist

This looks a lot less intimidating and, better yet, your user knows precisely what happened without even looking at the results you present. They typed “some artist” in the search box, which took them to a search page. They then know how to type another artist in and get a result. It would be even better if you capture the URL and replace the spaces with dashes for them, they can just type the artist name in and get what they want.

When the day is done, the SEO work, usability and findability could and SHOULD work together to create a site that is friendly to search engines as well as your users. That single little string is the first, last and only direct link your user has with the underlying system that drives your website.

**Disclaimer**

If you are a designer reading my blog, you are welcome to stop here. If you have concerns about URL rewriting, I encourage you to contact me and I’ll address them. Take what you have read and make the web a better place. If you are comfortable programming in a web-friendly language, please read on!

**On with the code!**

That’s great and all, but this doesn’t really get us any closer to how you DO any of this rewriting. There are, of course, barriers which get in the way of making this all happen. See, if you are writing in PHP then you are probably serving everything with Apache. This is great since Apache supports URL rewriting directly. If you have any skill with regular expressions then you can work a little juju and be rewriting by this afternoon. Your work will start and stop in the .htaccess file.

Common rules will look like the following:

RewriteRule (.*) /command/directory/index.php?$1 [L]

This was totally made up, so I can’t promise it will work, but this is the basic idea. Apache URL rewriting is a cryptic art that I have yet to master. Fortunately, there are many people, much smarter than I, who can advise and direct your work.

Apache is the nice situation, however. When we look at two languages used on the web, things get tricky really quickly. The tools for rewriting get few and the machinations become more cumbersome. I’ve encountered problems with each of the following.

ASP/ASP.Net runs on IIS which does not natively support URL rewriting. If you are interested in writing your own module or paying for something someone else has written for you, I give you my blessing. However, this may not be an option for you. Fortunately, you can still write URLs of the form:

http://www.mysite.com/Default.aspx?/my/ugly/url

Sadly, this probably cause more pain than anything else. Java, through JSP, has much the same problem. Unless you are running a Tomcat instance, hiding behind an Apache instance where you can rewrite your URLs nicely, your URLS at best will look like this:

http://www.mysite.com/index.jsp?/my/ugly/url

Once you have written your URLs like this, you can get slick and tricky with the code by simply doing the following:

ASP with C# code behind:

String path = Request.QueryString.toString();

JSP:

String path = request.getQueryString();

Now that we have gotten that little piece of ugly out of the way, let’s look at a solution for that gorilla in the corner. ASP and Java are typically only used to solve problems in a business environment. This means your IT department probably has a router and a load balancer sitting between the world and their servers. Enterprise routers are typically highly configurable, and can do quite a bit of rewriting work for you.

The most difficult part of getting your IT department to rewrite your URLs for you is convincing them it’s worth the time and effort. If you can provide them with precisely what you want the end result to be in your efforts, they can probably create the right rules and get everything situated fairly quickly. Be ready to buy them beer.

In the end, pretty URLs, under the skin, are pretty ugly. When it comes to getting your user to the site, moving them through your vast amounts of information and converting the visit into a sale or a return, the pain is worth it. Just think about how much easier life will be for your users once you have taken the time to craft their journey even outside the carefully designed presentation of your website. Think about URL rewriting and guide your user gently. Make the web a better place.

©2012 Chris Stead. All Rights Reserved.

In saying all that, I would like to oficially kick this post off with a bit of rejoice. CobbleSite version 1 is complete and ready for people to play with it. Let’s just call it a version though it’s not. Not really, anyway. This is exciting for me as I get to do more than simply blog about what I do, I get to show it.

All of this isn’t very useful if I don’t share a little about why I did it. I mean, what’s so special about just one more content management system if it’s built to be a variant on everything else that is already out there? There is, after all, one major difference:

Object oriented content.

The CobbleSite CMS is not so much about doing something that others before me have already done, it was about a philosophy. I believe that treating content as objects is the right way to move forward into new places on the web. Moreover, OOC makes life easier for administrators and users alike.

I’ve poked through several different content managers to see what they do well and what they do poorly. Every system has a strength: simplicity, focused function, raw power or vast ability to integrate plugins and custom functions. All of these things are wonderful, but they come with a tremendous amount of stuffing and whatnot that makes them unwieldy given the situation.

Personally, I love WordPress. I think they have done a great job of building a tool that is easy to install, use and administer. Templates are reasonable to build even by the relative novice and getting a site up and running takes little time and effort. I would consider this a success on many levels.

Regardless of how I feel about WordPress, it, just like every other system, fails to fulfill requirements I typically have for a website. I don’t only work on blogs. I build Corporate sites with pages and content distributed throughout a medium to large hierarchy and, sometimes, across multiple domains.

There are other tools as well, which are open source, that might fill this need a little better. Drupal is one. Drupal, however, is hardly friendly to the newcomer. You must learn new technical jargon, become familiar and comfortable with a cryptic template system and then struggle through building menu systems which support different levels of users. This is just too much work for me. Moreover, running a distributed Drupal installation for multiple domains becomes challenging very quickly.

In short, I can’t build a site, push it out to the world and then hand control to a creative team to maintain the content. Worse than all this, every CMS I have seen (so far) has content tightly coupled with pages. This is precisely why I built CobbleSite.

I had only one aim when I set out to build CobbleSite in the first place: decouple content from pages. I won’t go into detail about the benefits of OOC as you can read them in a previous blog. Let’s take a peek under the hood and I’ll give a little insight into why I did things the way I did them.

First, let’s look at hierarchy. Up-front, the hierarchy management works a little like a folder system. There are pages, sub-pages and sub-sub-sub-pages. This can be carried as deep as necessary. I was inspired to manage the hierarchy this way after working with people who would ask “so, where do I find that page again?” The answer: right where you left it. If the page is in a particular location within the site, it is right there in the hierarchy too.

Another benefit of managing the hierarchy this way is taxonomy management. It becomes quite obvious whether a taxonomical dictionary for your site will work or not. You can ask “does this copy work,” and get an answer with a glance. It allows people to tackle user-centric questions before the site has been built.

Within the hierarchy lay the pages. Pages are containers and, as such, just because you’ve made a page doesn’t mean you are stuck with some lorem ipsum to fill the space while you construct the site hierarchy. This approach maintains focus on one task at a time.

Pages are defined rather than created. This means, you give it a name, a template and some related meta information. Page definitions are manipulated through the hierarchy. Grouping and subordination are defined and stored.

Finally, let’s take a look at content. Content is created and given a type. Content can be created through a page view, or it can be created independently. The function of the content is left to the user to define. This is where the principle of OOC becomes clear.

The “class” of the content can be viewed as the content type. Meanwhile, each piece of content can be viewed as an object instance of the class. The translation of this technical jargon is, content can be created and reused across pages or even websites. This cuts down on duplicated work and turns the work of building a site into a much more straightforward act of creating and posting content inside of existing containers.

In the end, my method is not the only way of implementing OOC. Moreover, I wouldn’t even dare say it is the correct way, but it is the best I have done so far. There is much MUCH more related to the topic of building CobbleSite, but now is not the time. I encourage you to try CobbleSite, think about OOC principles and find ways it could improve. Better yet, think of ways you would build a better system altogether. When you make a site, think about object oriented content, provide a great site for your users and make the web a better place.

©2012 Chris Stead. All Rights Reserved.

Fortunately, users often leave hints as to who they are without knowing it. They (hopefully) travel through your site, touching certain pages and avoiding others. They also arrive from somewhere.

When trying to select your user and direct them, your initial response may be to directly ask them who they are and what they want. This works well if you are an e-tailer like Amazon, but the rest of us don’t have quite the same luxury.

If you are planning on selecting the user once they get to your site, you are already too late and they have left. You should know something about them before they every arrive. This, surprisingly, is not just about knowing your audience. It’s also what they can tell you.

Yes, your users choose to tell you something before they arrive at your site.

To learn about your users sub rosa, you need look no further than the HTTP referer. From the HTTP referer, you can find out where your user came from and, hopefully, something about what they want.

If your user accessed your site directly, you know they are either a returning visitor or they were recommended by someone. If they arrived at a landing page, it is, undoubtedly, due to some marketing effort. This, however, says the least about the user.

If they came from another website and not a search engine, you’ll know they were reading another site related to yours. Perhaps this is a competitor. Perhaps this is a colleague. Either way, you know they have come to your site because they are interested in the link they clicked through to.

The most directly informative method a user can use to access your site is through search engines. You can gather, immediately, that your user was interested in something directly related to your site. You also know your user is actively seeking something. Finally, your user told the search engine what they wanted and, subsequently, they told you.

How?

The HTTP referer. The referer is passed with every GET request and tells the server about where you have been. Don’t get ahead of yourself. The referer only informs you of the last place your user was. In our current case, a search engine.

The big four search engines, AKA Google, Yahoo, AOL and Bing (MSN), all use get arguments to store information about the current search. This makes it easy to clip the information you want, like a coupon, from the HTTP referer string.

Note: The next bit of this discussion involves a little code. If you’re not comfortable with programming in the popular language PHP or this just isn’t your job, copy and paste the following into an e-mail and send it to your developer.

In PHP, you can collect user referer information with the following line of code:

$referer = $_SERVER["HTTP_REFERER"];

Once you have the referer stored, you can test it against the big four. One way of doing this might be like the following:

$refererType = "other";
$searchEngines = array("aol", "bing", "google", "yahoo");
foreach($seachEngine as $value){
     if(preg_match("/$value/i", $referer) !== false){
          $refererType = $value;
          break;
     }
}

Now we’ve got the search engine they used and a referer string. This is prime time for extracting their search query and figuring out who your user really is. Hopefully this won’t turn into a Scooby Doo episode, where Old Man Withers is haunting your site. Let’s do some data extraction:

$queryKey = ($refererType == "yahoo") ? 'p' : 'q';
$pattern = "/(\\?|\\&)$queryKey\\=/";
$argStart = preg_match($pattern, $referer) + 3;
$argLen = preg_match("/(\\&|\\$)/",
     $referer, $argStart) - $argStart;
$arg = urldecode(substr($referer, $argStart, $argLen));
$argArray = explode('+', $arg);

Still with me? The code part is over.

Now that you have the search information and it’s been broken into happy, bite-sized chunks, you can use it to do all kinds of fun things with your user. You can check their spelling, to ensure they are in the right place. You can offer special links that relate to what they searched for. You can even adjust the page to better suit the user’s needs.

The possibilities are limitless. By knowing a little about what the user did before they arrived at your site, you can direct their journey through your site. It is in your hands to find interesting and creative uses for this information. Go and make the web a better place.

©2012 Chris Stead. All Rights Reserved.