06 April 2005

XML Pope search: How do the XML search platforms compare?

It's interesting to see how different search platforms showcase different results.

If you load up the RSS feeds to Newsgator Online, you'll notice that in the subscription list, you'll see the HTML and RSS buttons.

Curiously, not all the platforms provide the same results--not all buttons are alike.

Blogdigger's HTML-button in Newsgator provides the HTML of the search; while PubSub's HTML-button in Newsgator provides the browser-friendly-version of the PubSub website, not the browser-friendly search result.

If you use PubSub, you have to know to then click on the next button in the Subscription Stack. In other words, if you want a faster route to your output, currently you're better off to use Blogdigger.

Going further, if you press RSS-button in Newsgator Online, you generally get the XML-code. Blogdigger does this. However, PubSub doesn't show the code; it gives you the browser friendly version of the code.

Work arounds: What to do to read the PubSub RSS feed

If you're using Newsgator Online, go to subscriptions.

The way to get the search result for PubSub isn't to use the HTML as you do with BlogDigger; rather the solution is to press the RSS-button in Newsgator.

Also, if you are directed to the PubSub website, and not the feed, simply press on the "My Subscription Stack"-box on the left hand side. Look for your subscription request. You'll need to notice what you have looked for. Click on that.

Question

Why does the PubSub RSS-selection in Newsgator go to the main PubSub Site, and not directly to the RSS-feed result?

I see no advantage to introducing this new step.

It remains to be understood whether the intermediate step was added for a particular reason, or whether it is a coding error. Regardless, it is new.

Users' supervisors and trainers

It would be good for your employees to know the differences in the search results: To know whether which platforms provide faster, more streamlined outputs, and which results are more difficult to showcase. That way, you'll be able to guide them to making appropriate subscription-search requests, and then be able to figure out why their search results do not match across platforms.

XML: Know whether the search is superior to traditional search engines

Anyone should be able to type in the word "Pope" at this juncture in history and get a direct result, and not be taken on a convoluted trail that may or may not link with content.

The idea of XML was to save time, and bring the results to the public. What's noteworthy is that the public also has to know the subtle differences between the search platform results. That means the public has to simply do the search, then know enough about the inconsistencies in the system to know that not all search platforms produce the same types of results.

Now the public gets to look at both the outputs [that may not show or appear], and then do a cross-platform check across platforms to then verify whether the search results are correct in both content and display.

This isn't my idea of making things easier. It's annoying.

The customer is being asked to, once again, know the platforms better than the developers, in order to make informed decisions about which platform is most appropriate to use; and to then know enough to dig into the results to know that a given output isn't making sense when it should be.
It's interesting to see how different search platforms showcase different results.

If you load up the RSS feeds to Newsgator Online, you'll notice that in the subscription list, you'll see the HTML and RSS buttons.

Curiously, not all the platforms provide the same results--not all buttons are alike.

Blogdigger's HTML-button in Newsgator provides the HTML of the search; while PubSub's HTML-button in Newsgator provides the browser-friendly-version of the PubSub website, not the browser-friendly search result.

If you use PubSub, you have to know to then click on the next button in the Subscription Stack. In other words, if you want a faster route to your output, currently you're better off to use Blogdigger.

Going further, if you press RSS-button in Newsgator Online, you generally get the XML-code. Blogdigger does this. However, PubSub doesn't show the code; it gives you the browser friendly version of the code.

Work arounds: What to do to read the PubSub RSS feed

If you're using Newsgator Online, go to subscriptions.

The way to get the search result for PubSub isn't to use the HTML as you do with BlogDigger; rather the solution is to press the RSS-button in Newsgator.

Also, if you are directed to the PubSub website, and not the feed, simply press on the "My Subscription Stack"-box on the left hand side. Look for your subscription request. You'll need to notice what you have looked for. Click on that.

Question

Why does the PubSub RSS-selection in Newsgator go to the main PubSub Site, and not directly to the RSS-feed result?

I see no advantage to introducing this new step.

It remains to be understood whether the intermediate step was added for a particular reason, or whether it is a coding error. Regardless, it is new.

Users' supervisors and trainers

It would be good for your employees to know the differences in the search results: To know whether which platforms provide faster, more streamlined outputs, and which results are more difficult to showcase. That way, you'll be able to guide them to making appropriate subscription-search requests, and then be able to figure out why their search results do not match across platforms.

XML: Know whether the search is superior to traditional search engines

Anyone should be able to type in the word "Pope" at this juncture in history and get a direct result, and not be taken on a convoluted trail that may or may not link with content.

The idea of XML was to save time, and bring the results to the public. What's noteworthy is that the public also has to know the subtle differences between the search platform results. That means the public has to simply do the search, then know enough about the inconsistencies in the system to know that not all search platforms produce the same types of results.

Now the public gets to look at both the outputs [that may not show or appear], and then do a cross-platform check across platforms to then verify whether the search results are correct in both content and display.

This isn't my idea of making things easier. It's annoying.

The customer is being asked to, once again, know the platforms better than the developers, in order to make informed decisions about which platform is most appropriate to use; and to then know enough to dig into the results to know that a given output isn't making sense when it should be.
" />