Leslie Rohde . com - Profession category

"...Google will determine..."? Not on my site!

Wed, 24 Sep 2008 20:49:00 GMT

In the StomperNet forums today I responded to a member who noticed a Google post here. Reproduced here is my acidic response.

That was the most useless, vague, non-actionable and *irresponsible* post I have EVER seen from Google. It looks like something from webmasterworld or the warrior's forum. The examples used are just plain stupid and the sweeping generalization they make about Google somehow figuring out URL parameters is dangerously silly.

No one would consider rewriting a (so-called) dynamic url into a "static" one while retaining the session id. I mean DUH! If you are smart enough to even be able to enable mod_rewrite how could you not know to turn off session ids when serving content to bots? Ridiculous example that serves to paint all rewriting as somehow dangerous. Worst still, why would anyone rewrite like the example shown? That's plain stupid.
" ... Google will determine which parameters can be removed ..." -- You have got to me Sh*t**g me! Is there anyone who can spell S-E-O that would like to just simply trust Google to "determine" what URLs should be the same and which should be different?? Not me thanks. My site. I'll decide. If they get it wrong, you get flagged with widespread duplicate content and they don't tell you about it.
They leave completely unanswered the OBVIOUS (just look at SERPs) problems they have today with session ids -- not so good at "determining" after all, eh? At every single StomperNet Live event we've held, I have reviewed at least one site that had pages indexed at Google showing multiple different session id values. This is a widespread problem for sites that serve session ids to bots and for Google to publicly post about "dynamic" URLs and sweep this under the rug while vaguely claiming to handle it borders on misrepresentation.
They also don't say a damn thing about parameter order -- another place they fail COMPLETELY to "determine". Example: p1=v1&p2=v2 leads to the same content as p2=v2&p1=v1 and this is a REQUIREMENT of the HTTP spec (named parameters are NOT positional so may appear in any order) but Google treats these as different URLs and will ignorantly and incorrectly index both URLs as different pages. This problems appears in several CMSs today, Endeca in particular has it bad.

McAfee Revisited

Sun, 03 Aug 2008 19:40:29 GMT

UPDATE: So I'm a bit out of touch on this one, but McAfee actually backed away from what they were doing, in no small measure it seems from the stink she rasied. :-) Read the full story at Cresta's blog.

Oh, and I've restored the image to commerce websites.

I promise to just let this go — soon as I get this bit of satire posted!

For everyone who still wants to use the McAfee seal, here's a logo providing "Full Disclosure" of what the ScanAlert "service" really means.

Enjoy. ;-)

LEGAL NOTICE to McAfee: This is satirical commentary covered by Fair Use. If you don't like it, tough shit. Maybe you should have thought of that before pillaging your customers' traffic.

SEO Trick - Sub-Domains vs. Directories

Sun, 03 Aug 2008 16:12:27 GMT

Two SEO questions I get asked a lot:

How important is the URL to ranking and
Which is better, sub-domains or directories

In general, both have only minor impact on ranking (I think they are important to click-through) but I just saw an example of the latter that is worth some thought.

In searching for "swing treeview" (a Java thing) at Google, the top two results are treeview-java-swing.qarchive.org and java-treeview.qarchive.org and Google did NOT do the second as an indented listing which they would do if these were treated as being from the same domain.

If the same content were served via pages or directories at the root domain, the best this site would get is an indented listing, and even that is open to question.

This is likely a generally applicable result. Look at the results for searching for "blogspot" for example. Predictably, there are pages and pages of blogspot sub-domains. The previous example is no different.

The lesson here is that sub-domains really are different domains (which we knew).

The action item is to find out which is easier to get:

Multiple listings from sub-domains or
An indented listing from a single domain

I'll let you know what I find.

HackerSafe? Not Now. Now It's HackerSOURCE. Yikes!!

Sun, 03 Aug 2008 15:10:21 GMT

McAfee has done something with the HackerSafe logo that I think totally crosses the line. Thanks to Cresta's Blog post and subsequent Tweet
for pointing this out to me.

Today, I am pulling the seal off of my sites; disabling all the domains in the ScanAlert control panel; and penning a nasty ass message to McAfee. Why you ask?

The change they made is to the page you get when someone clicks your the McAfee seal on your site. Right in the middle of the page is a link "Attention Shoppers" that leads to http://secureshopping.mcafee.com/. Excuse me!! WTF do they think they are doing?? I'm paying them for the seal AND giving them traffic?? I don't think so.

This demonstrates a really disturbing lack of understanding on McAfee's part. So bad in fact, I'm not interested in even discussing the point with them. Any partner of mine that could let something this brain-dead-stupid ever see light, simply can not be trusted.

Portals vs. Mashups

Sun, 13 Jul 2008 21:35:00 GMT

A critical Information Technology objective for most mid and larger companies these days is the integration of disparate business systems. The reasons are several, but Business Intelligence (BI) is a decent overarching label for all of it.
The JSR-168 and related WSRP standards are intended to facility this but are they too late?
Something old ... new again
Once upon a time, way back when a big disk was just M's and RAM was merely K's, our stone age solution to "integration" was to get different applications to at least run on the same terminal -- and even that was rough. I don't remember that we even had a name for that. Fast forward about 20 years and we call it "integration at the glass".
Of course, it's more than just glass.
The real deal is that we now have a common UI framework (HTML/Javascript) and network communication standards(HTML) that allow even the oldest and crufty'st legacy apps [mostly] to appear together in harmony on the same desktop. So why build a portal when you already have a browser?
Granted, that is something of a simplification. There's still some tricky stuff to work out, like common authentication and inter-app state synchronization to name two, but those are arguably as easy to solve near the desktop as they are on the server -- the network connection is simply not the barrier it once was. We no longer are looking at making the binary choice between thin-client and thick-client, but instead can spread application functionality almost arbitrarily across what was once the "great divide".
The choice is where you do your mashing.
If you mash using WSRP, we call the result a portal, but if you mash in the browser, you're suddenly a Web2.0 social app -- and likely with a better valuation too. ;-)
Now, I do think there is an unanswered technology question here and that is the life cycle cost of these semi-thin clients -- our tools are simply better and more mature for server style implementation approaches. This is changing.
A real test case
An application we recently built at StomperNet is split in just this way. It is composed of two user facing components implemented in Firefox that wrap local functionality as well as remote services hosted by a PHP server. There were some lessons learned, both positive and not, but on balance our approach provided solution features that would have been very difficult to provide any other way. With the maturation of XULRunner we can expect this type of application partitioning to become even easier.