Make it as easy as possible for the customer to buy, not as hard as possible.

Today I discovered and wanted to buy a sticker to put on my mail box, to stop junk mail from being delivered.

Here’s the shopping cart.

So far so good.

Then they wanted me to fill out this form for a $1.00 purchase.

Needless to say, they lost my $1.00.

It’s easier to write my own sticker.

My Gmail is on one Google account, and my other things like Google Analytics, AdSense, etc., are on different Google accounts. Till now I’ve had to log out of Gmail and log in to the other Google Accounts to access those other Google services. Then log back into Gmail when I’ve done what I wanted to do in the other services.

Now I run Gmail in the Google Chrome browser, which is ideal because Gmail is resource intensive with all the Javascript and Ajax that it uses. I would assume that Chrome would be optimized to run Google applications.

Memory usage of Chrome, compared with FireFox, appears to be far better optimized. Google Chrome uses less than 70MB, while FireFox consumes 250MB+. It might only be my imagination, but it looks as if Gmail is running a little faster and smoother in Chrome.

Google Chrome won’t replace FireFox in my day-to-day work for some time to come.

I’m heavily dependent on several FireFox add-ons, such as RoboForm (can’t live without it), AdBlock, and Web Developer Toolbar, to name just a few.

Until such time that those add-ons are available on Chrome, I’ll just let Chrome do what one expects it would excel at, and that’s running Gmail.

Oh wait, I haven’t mentioned Internet Explorer. Ugh. I use it only to check if it correctly displays my web sites, which it often doesn’t do.

After having experienced several crashes of FireFox 3 in rapid succession, I dove into the configuration settings and discovered where to disable the random crash behavior of FireFox.

Don’t try this at home. It’s serial geek stuff.

Judging from the responses (see below), most folks would probably return to Twitter.

When using XML-RPC for PHP, you get a very weird error back on some hosting platforms when you’ve given the XML-RPC interface an invalid domain.

With the XML-RPC debug level set to 3, here’s what I’ve been getting back in return.

---SENDING---
POST /xmlrpc.php HTTP/1.0
User-Agent: XML-RPC for PHP 2.2
Host: http://www.example.com:80
Accept-Encoding: gzip, deflate
Accept-Charset: UTF-8,ISO-8859-1,US-ASCII
Content-Type: text/xml
Content-Length: 276
 
<?xml version="1.0"?>
<methodCall>
<methodName>metaWeblog.getCategories</methodName>
<params>
<param>
<value><string>1</string></value>
</param>
<param>
<value><string>userid</string></value>
</param>
<param>
<value><string>password</string></value>
</param>
</params>
</methodCall>
---END---
 
xmlrpcresp Object
(
    [val] => 0
    [valtyp] => 
    [errno] => 5
    [errstr] => Connect error: Success (0)
    [payload] => 
    [hdrs] => Array
        (
        )
   [_cookies] => Array
        (
        )
    [content_type] => text/xml
    [raw_data] => 
)

Notice the “Connect error: Success(0)? That tells you absolutely nothing.

If you’re experiencing that error, there are two possible reasons for it.

Scenario One: The domain (http://www.domain.com:80) is invalid, and the XML-RPC interface can’t connect to it.

Scenario Two: One of the parameters you pass to the XML-RPC interface is the host. This parameter must not include the “http://” part. If you include that with the parameter you’re passing to the XML-RPC interface, the above is the error it generates. It’s very tough to figure out, because, as you’ll see in the debug output, it looks as if your parameters were processed just fine.

An easy way to extract just the domain from an URL in PHP is as follows:

<?php
    $url = 'http://www.domain.com';
    $url_array = parse_url($url);
    $domain = $url_array['host'];
    echo $domain;
?>

The above code will output “www.domain.com”.

After having used FriendFeed for a little while, I’ve discovered that FriendFeed comments (and likes) wield nearly the same power, albeit not as direct as Twitter @name replies.

On FriendFeed, if you want to catch the attention of high-profile users like Robert Scoble or Louis Gray, assuming they’re not subscribed to you, here’s how to do it.

Step One: Post an entry that will be of interest to the person.

Step Two: Wait for someone they do subscribe to, to either like or comment on your entry.

When that happens, your entry is shown in their feeds as “So-and-so (friend of so-and-so)…”.

From your perspective it’s obviously less exact than the Twitter approach, but, it has the advantage that your entry is shown to them as having been endorsed by someone they subscribe to, which adds credibility to your entry.

From their perspective it’s actually a better solution because they only see entries that were endorsed by folks they trust and follow. So, for them the exposure to @name reply spam is virtually none.

However, they count on the fact that the majority of blog owners don’t pay close attention to the comments that are made on their blogs. This happens due to lack of time, lack of knowledge about spam, and sometimes disinterest.

Hence, a one-time effort by comment spammers can harvest them many backlinks from many different blogs, which remain on those blogs for a very long time, if not forever.

With that as backdrop, here is the true power of Disqus in fighting blog comment spam.

Strike One: Disqus Replaces Blog Comments (on WordPress at least)

With Disqus installed on your WordPress blog, there’s no WordPress comment form that spammer scripts can find and manipulate.

Strike Two: You Can Block Spammers in Disqus

When spammers try to post their spam via Disqus, you as blog owner have the power to block them from ever commenting on your blog again.

I assume that, once blocked, all the past comments made by the blocked entity are also removed from one’s Disqus comment system.

Strike Three: Removal From Disqus Destroys All Their Comments

This is the real “kick in the teeth” that Disqus can hand out to spammers.

When Disqus removes a spammer’s account from their system, all their comments automatically disappear from all the blogs that they defaced with their comment filth.

In other words, all their efforts are erased in one fell swoop, and that gives one that “poetic justice” feeling, doesn’t it?

This holds true regardless of whether the blog owner is diligent or indifferent about the comments posted on his/her blog. The only requirement is that they use Disqus as their commenting system.

One thing that’s sorely lacking, is the ability to follow conversation threads in Twitter. Some folks have tried to create applications to do that, but it’s hit and miss, because tweet matching must currently occur either on keywords, or time proximity, or both.

Twitter can open a new world of Twitter conversation threading by doing the following:

Step One — On each reply, record and store the tweet number of the original entry that’s being replied to.

When someone clicks the reply icon, record the original tweet number:

Step Two — Make the replied-to tweet number available on the record of a tweet in the API, as well as a list of tweet numbers that are replies to this tweet.

Step Three — Provide an API call to retrieve the details of a specific tweet.

These three simple steps will enable third-party developers to create awesome applications to show how threaded conversions occur and evolve within Twitter.