Ok So Who Cares?

Well the concern amongst the community right now is that this acquisition went down and it instantly broke any old Summize API requests due to the new URL redirect.  No warning was given and it just kinda happened.  With things starting off in this way, it’s no wonder that the community was feeling a little burned, spewing comments such as “RIP Summize” and other similar statements.  Feeling the heat, Alex Payne asked those following him to @reply with any concerns about the API changes as a consequence of this acquisition (http://twitter.com/al3x/statuses/859262626).  The community eagerly awaits that blog post.

Any Real Reason for Concern?

Looking at things right now?  No.  Twitter has been improving and Summize functions just as it used to (except for the broken API requests and new theme).  There is a great potential for the two services to feed off one another since Summize improved upon Twitter and without Twitter there is no Summize.  There is the obvious concern that having Summize under Twitter control will somehow destroy the great up-time, speed, and reliability of the searching service, but at the same time it might be possible for Twitter to take in the technology used in Summize and adapt it to make the mother service even better.

As a developer that uses Twitter for a number of different things, I hope we see the API for Summize largely untouched and also see the API for twitter enhanced to utilize a lot of the Summize functionality.   This will make developing applications that use Twitter much simpler.  There is an inherent risk though – if this integration does not go smoothly it has the potentional to ruin Summize and also provide Twitter no gain for their $15 million.  Let’s all hope that it works out with a great deal of improvement for everyone.

Alex Payne’s Twitter: here
Search.Twitter Query for Summize: here
Twitter Blog Post on the Aquisition: here

The Problem – Why You Should Care

Other sites that you pull content from are not always going to be reliable.  They could be down, running slow, or some other possible problem.  If you are using something like twitter to display your status on your site but you have a lot of other content you want people to see then it would be wise to use client-side scripting to get the content.  You might be saying in your head “Oh but I have this sweet PHP script that does that for me.” but you should tell that voice in your head to shut up and just listen.

The Solution…

When you use server-side scripting then the server that is dishing out your website needs to go to the other (possibly) slow website.  If it’s waiting for this content then your user is waiting for your site to finish being generated server side and then sent to their browser.  This was a problem when twitter was doing its thing with the “fail whale” on a regular basis and was generally taking forever to display tweets.  This in turn was making my site very slow.  Realizing the problem, I took out the PHP widget that I had and replaced it with my own little creation that utilizes javascript and a tiny bit of PHP.

Let’s take a look at how to do that…

First thing you’re going to want to do is make a little div with some static text in it that gets killed when your stuff finishes loading.  You can make it kinda like this:

<div id=”twit_text”>
<ul id=”twitter_update_list”><li>Waiting for Twitter.com to reply.  Please hold.</li></ul>
</div>

The ul in there will be replaced by the script which actually sits right on twitter’s servers.  This is pretty simple and basic stuff.  It is advisable to put some static content in there so that users know that something else is going to happen and you don’t have a blank spot on the page.  There is one other piece of magic that actually uses a little bit of PHP but not for the same purpose the other scripts use it for…

<?
$currURL = currPageURL();

if (($currURL == “http://www.patricktulskie.com/”) || ($currURL == “http://patricktulskie.com/”))
{
echo “<script type=\”text/javascript\” src=\”http://twitter.com/javascripts/blogger.js\”></script>”;
echo “<script type=\”text/javascript\” src=\”http://twitter.com/statuses/user_timeline/PatrickTulskie.json?callback=twitterCallback2&count=1\”></script>”;
}
?>

This goes in the footer of the page to only load the javascript if the page you’re looking at is the index page.  You can modify the PHP to load on different pages but for my purposes I only want you to see the status on the index.  You can’t easily do this with a plugin because plugins are loaded entirely as the page loads.  The PHP above is in the very footer of the page and it only kicks off the javascript IF we’re on the index of the site AND after everything else on the page has already loaded.

One Other Thing…

I use this function to get the URL of the page.  You can put it in your wordpress theme’s functions or you can put it wherever you need it on your site.  It’s fairly reusable too.

function currPageURL()
{
$pageURL = ‘http’;
if ($_SERVER["HTTPS"] == “on”) {$pageURL .= “s”;}
$pageURL .= “://”;
if ($_SERVER["SERVER_PORT"] != “80″)
{
$pageURL .= $_SERVER["SERVER_NAME"].”:”.$_SERVER["SERVER_PORT"].$_SERVER["REQUEST_URI"];
}
else
{
$pageURL .= $_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
}
return $pageURL;
}

I Hate Twitter

Well thats fine.  I’m sure it doesn’t like you much either.  Regardless, this is a really basic usability concept that many people don’t seem to grasp or even think about when creating a website.  Say you want to pull news feeds from a Digg category using an RSS parser on your page.  You have other stuff on the page but this Digg box is in your sidebar.  If you don’t think about where the script is going to execute in relation to your page loading, then you’re going to have problems when Digg is running slow or is down.  For those of you who don’t want to get into a full blown ajax setup, or simply don’t know how to then this is a great work around that uses really minimal coding.

What I did was I made most of the fonts on the page black, but this had some negative affects in terms of not being able to read the text on some of the black spots on the page.  I’m working on it, I know.  Just want to let everyone know I’m aware.

One of the other things that was pretty annoying was the slow page load time when my twitter status is loading.  I handled that with some PHP to verify the URL of the page you’re looking at and I also moved the javascript to the very bottom of the site before the end of the body tag.  This makes sure that only pages where the twitter status is shown will actually load the javascript AND it also makes sure that the rest of the page loads in a timely manner so you don’t need to wait around for my status if you want to read something else.

Just some usability metrics that I had to handle and I thought I’d mention them.  I’ll be doing another article on the PHP used to handle the twitter status probably later on this week.