22 April 2005

Y!Q one step tool

Quick tip Did you know there is a Y!Q users forum?

After blogging about the Y!Q I came across the Y!Q forum, and I had some additional thoughts on what could be a solution.

As I see it the problem with "placing Y!Q in a blog" is this:

  • It is currently difficult to get all the Y!Q beta-code
  • The code is not concise; there is a long list of code to so a single task
  • There is no simple tool to translate a requested-phrase into a single line of code
  • The workarounds and hacks are a patchwork

    As I see it the primary goal of this Y!Q tool would be to make things easier in both creating the code, and in quickly integrating the similar-search-option into their webpage or blog. In short:

  • Users are most comfortable with tools that are simple

    I also thought about some analogies of other simple search platforms and support tools, and thought there might be an opportunity for the Yahoo Search Developer Network or for other developers at Yahoo like Jeremy Zawodny to look at the issue of similar searches.

    I also thought of the following analogies

  • There is a Technorati tool for creating tags
  • Altavista has a tool that translates many lines of HTML into a single line of java

    Both of these tools struck me as interesting and appropriate in relation to Y1Q for several reasons. First, these two approaches are fairly straightforward and they are familiar to the XML community. At the same time, both tools show how something that used to be somewhat complicated could get streamlined into a single step.

    With the cast of the Technorati tag-tool-creator, users simply type in their tag, and they get back a line of HTML. They place it in their blog. And then it gets indexed when they ping. Easy.

    The Alta vista tool actually does many things in a single line of code. The old way of creating a translation tool, was for platform-publishers to individually create a single HTML-link for each language translation; and then individually link a particular language option to that link. The more languages, the more links.

    What Alta Vista did was combine the HTML links for some eight [8] languages into a single java-command; and then created a large button that both showcased AltaVista, and gave users a quick way to place the command within their blog; and at the same time, each language has a separate-link within the image.

    What Alta Vista did was integrate many lines of HTML into a single line of java; and at the same time maintain the wide options and still create a tool that was easy to deploy and use. It’s as if the single tool does far more than the individual components could individually. This is ideal.

    Which leads us to the current Y!Q beta. As it currently stands, and as I already blogged about, there are many lines of code and the code doesn’t necessarily intuitively translate into a solution.

    What would be nice if there was a way to combine the applicable features of both the Technorati-tag-creator-tool, and that of the Altavista-java-tool to Y!Q.

    That’s the simple mechanism of the desirable tool at the final end. Let’s consider what this tool would actually do. Ideally, what the users would be able to do is simply show up with a phrase, enter it, and get back a single command that they place in their blog.

    The long version of this step goes like this:

    Step 1: Users enter the phrase and type of platform

  • Users would have in mind a phrase they want to get a similar search for
  • Users would enter that phrase in text at a box, tool, or platform

    Step 2: Users get back one line of Java code

  • Users would get a single java code for that phrase, and tailored to their blog time
  • Within the java-code for that custom search, there would be an indexing mechanism.

    This would be like a tag-command or “no follow” which was a code that applied to that line; but rather than be a tag or a command not to follow, this code would be a trigger mechanism for outside indexing mechanism, search platforms and clustering tools to extract this phrase and then organize it into user-defined pattern.

    Step 3: Place code in blog

  • Users would place that single line of code as a link to the platform, like an HTML tag

    Within the java-line is the embedded text for the related search. External platforms would be able to read a tag-like word in the code, and extract this to external indexes. The information contained within the java-like-one-line-code would be something that was exportable, open, and could easily be aggregated in external search platforms.

    Outside readers could find out the types of data contained within this code. And those who crate the code would have the option to keep the details private, or non-trackable, similar to a blogging device like “no follow.”

    In other words, the people who made the tag-like-command would have the option to exclude or prohibit external platforms form indexing the detailed information in the code, just as they have the option to exclude bots from their site.
    Next steps

    I’ve outlined the concept and the general modules that would accomplish this Y!Q task. The next issue becomes how to actually do this.

    Thinking out loud, there are a couple of approaches to accomplishing this.

    Platform which stored phrases and created codes

    First, what is possible is there be a PubSub-like platform where users would enter their target phrase; and the platform would then save this phrase, issue a single line of code; and the user would place this line of code into their blog.

    The drawback of this approach is that it would require a new platform or hardware support to archive all the codes. The current method would simply require the users to place the code on their own platform, and there is no indexing requirement at Yahoo.

    Thus, for sake of convenience, it would appear as though this option, although feasible, would tend to form the upper bound of what is desirable in terms of cost, hardware support, and simplicity.

    Simple code generator based on user input

    At the lower end of the complexity-spectrum is the Technorati-tag-tool-creator. This type of approach would be very simple. Applying this concept to this situation, a user would simply show up, type in their search term-phrase into the tool, and get issued back a single line of java code.

    The results would not be saved, nor aggregated. However, within the code there would be something that would allow external platforms to index and archive the phrase or terms.

    Ideally, the Yahoo search developer network would get notified of Y!Q plans in this area, and the developers would create a number of tools that would seamlessly integrate with this archiving-indexing function of Y!Q.

    This approach seems the most feasible.

    A W3 standard

    A more robust approach would be something that is a midway point between the simple-user-tool like the Technorati-tag-creator, and that of the PubSub platform.

    In this middle approach, there would be a more robust support for the platform-code, and there would be a standard phrase or code that W3 would eventually adopt. This approach, although formal would tend to be the most time consuming.

    I would imagine we might hear many debates about the appropriateness of the standards, or get into a heated discussion whether this approach is simply making longer tags.

    Let’s recall the big picture. Even if there is no formal standard created, what we are seeing is the need for more complicated tags to get both indexed and archived; and at the same time relies on these tag-commands within the HTML to do some external analysis of these longer phrases.

    The issue becomes one of will the platforms create something on their own, or will there be some sort of structure to where the complex-tags-within-Y!Q ultimately arrive.

    I’d prefer to see Y!Q simply become what is most useful, regardless the platform, indexing, or standard. Yet, in practice, if there is not wider support for the ultimate direction that Y!Q takes in terms of structure and formal integration, we may simply have new platforms creating new tools in a slightly different way.

    I would prefer that the platforms choose what they want to create, while at the same time all moving in a common direction: That of creating platforms, however different, that creates and supports an external indexing system of those specific target phrases within the Y!Q similar searches.

    Option review

    Because of the simplicity of the Technorati-like-tool, and the complexity of the PubSub-like phrase-storage, and the potentially longer-convoluted approach to W3 standard-creating in support of such a concept, I favor the simple tool.

    Put another way, I favor the easier option of creating a simple tool that would simply create the code and let the users place it into the platform.

    However, the issue is one of indexing. What method would be useful. Ideally, the approach would be transparent to the user, embedded within the code, and the users would have the option to opt-out of the search.

    At the same time, the indexing option would have to be something that was simple enough so that it was useful and didn’t require a separate platform to support; while at the same time something that was useful and robust enough to interact with the main Yahoo search engine: Providing some structure to the words; something that integrated well with the Yahoo platform; while at the same time didn’t become an entity unto itself.

    Summary

    I’ve outlined a couple of concepts on how the Y!Q could be improved. The current approach requires users to copy code and use a patchwork like approach to making the code work.

    Ideally, the Y!Q platform when it finally launches after beta would be something that is one step: Users would simply enter the phrase, and they would get a line of code they could place within their blog or webpage.

    How this is actually done remains to be decided. But recall there are some useful analogies that users are already familiar with: The Technorati tag-creator-tool; the AltaVista language translation tool-single-line; and the concept of indexing tags.

    Ultimately, what I would like to see is a simple mechanism to index these phrases, so that I as a searcher could find patterns in what people were choosing to encapsulate within Y!Q.

    At the high-cost-end of the potential solutions would be a system like PubSub that took the user phrase, exported a code, then allowed users to track these individual subscriptions. Perhaps there might be a time when a platform like PubSub would want to use this information for some sort of marketing or analysis.

    The question remains which enterprise would be willing to support such a tool; and what type of enterprise would see some additional information within this approach that they currently are unable to get through the existing search platforms.

    Perhaps this is another opportunity for the Yahoo Search Developer network to brainstorm and do some more magic. I’m confident we’ll see more interesting ideas.



    LEGAL NOTICE


    Creative Commons License

    This work is licensed under a Creative Commons License.

    You may not copy any of this work to promote a commercial product on any site or medium in the universe.

    If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

    Free to use for non-commercial uses. Link to this original blogspot and cite as .


    -- This is the end of the content --
  • Quick tip Did you know there is a Y!Q users forum?

    After blogging about the Y!Q I came across the Y!Q forum, and I had some additional thoughts on what could be a solution.

    As I see it the problem with "placing Y!Q in a blog" is this:

  • It is currently difficult to get all the Y!Q beta-code
  • The code is not concise; there is a long list of code to so a single task
  • There is no simple tool to translate a requested-phrase into a single line of code
  • The workarounds and hacks are a patchwork

    As I see it the primary goal of this Y!Q tool would be to make things easier in both creating the code, and in quickly integrating the similar-search-option into their webpage or blog. In short:

  • Users are most comfortable with tools that are simple

    I also thought about some analogies of other simple search platforms and support tools, and thought there might be an opportunity for the Yahoo Search Developer Network or for other developers at Yahoo like Jeremy Zawodny to look at the issue of similar searches.

    I also thought of the following analogies

  • There is a Technorati tool for creating tags
  • Altavista has a tool that translates many lines of HTML into a single line of java

    Both of these tools struck me as interesting and appropriate in relation to Y1Q for several reasons. First, these two approaches are fairly straightforward and they are familiar to the XML community. At the same time, both tools show how something that used to be somewhat complicated could get streamlined into a single step.

    With the cast of the Technorati tag-tool-creator, users simply type in their tag, and they get back a line of HTML. They place it in their blog. And then it gets indexed when they ping. Easy.

    The Alta vista tool actually does many things in a single line of code. The old way of creating a translation tool, was for platform-publishers to individually create a single HTML-link for each language translation; and then individually link a particular language option to that link. The more languages, the more links.

    What Alta Vista did was combine the HTML links for some eight [8] languages into a single java-command; and then created a large button that both showcased AltaVista, and gave users a quick way to place the command within their blog; and at the same time, each language has a separate-link within the image.

    What Alta Vista did was integrate many lines of HTML into a single line of java; and at the same time maintain the wide options and still create a tool that was easy to deploy and use. It’s as if the single tool does far more than the individual components could individually. This is ideal.

    Which leads us to the current Y!Q beta. As it currently stands, and as I already blogged about, there are many lines of code and the code doesn’t necessarily intuitively translate into a solution.

    What would be nice if there was a way to combine the applicable features of both the Technorati-tag-creator-tool, and that of the Altavista-java-tool to Y!Q.

    That’s the simple mechanism of the desirable tool at the final end. Let’s consider what this tool would actually do. Ideally, what the users would be able to do is simply show up with a phrase, enter it, and get back a single command that they place in their blog.

    The long version of this step goes like this:

    Step 1: Users enter the phrase and type of platform

  • Users would have in mind a phrase they want to get a similar search for
  • Users would enter that phrase in text at a box, tool, or platform

    Step 2: Users get back one line of Java code

  • Users would get a single java code for that phrase, and tailored to their blog time
  • Within the java-code for that custom search, there would be an indexing mechanism.

    This would be like a tag-command or “no follow” which was a code that applied to that line; but rather than be a tag or a command not to follow, this code would be a trigger mechanism for outside indexing mechanism, search platforms and clustering tools to extract this phrase and then organize it into user-defined pattern.

    Step 3: Place code in blog

  • Users would place that single line of code as a link to the platform, like an HTML tag

    Within the java-line is the embedded text for the related search. External platforms would be able to read a tag-like word in the code, and extract this to external indexes. The information contained within the java-like-one-line-code would be something that was exportable, open, and could easily be aggregated in external search platforms.

    Outside readers could find out the types of data contained within this code. And those who crate the code would have the option to keep the details private, or non-trackable, similar to a blogging device like “no follow.”

    In other words, the people who made the tag-like-command would have the option to exclude or prohibit external platforms form indexing the detailed information in the code, just as they have the option to exclude bots from their site.
    Next steps

    I’ve outlined the concept and the general modules that would accomplish this Y!Q task. The next issue becomes how to actually do this.

    Thinking out loud, there are a couple of approaches to accomplishing this.

    Platform which stored phrases and created codes

    First, what is possible is there be a PubSub-like platform where users would enter their target phrase; and the platform would then save this phrase, issue a single line of code; and the user would place this line of code into their blog.

    The drawback of this approach is that it would require a new platform or hardware support to archive all the codes. The current method would simply require the users to place the code on their own platform, and there is no indexing requirement at Yahoo.

    Thus, for sake of convenience, it would appear as though this option, although feasible, would tend to form the upper bound of what is desirable in terms of cost, hardware support, and simplicity.

    Simple code generator based on user input

    At the lower end of the complexity-spectrum is the Technorati-tag-tool-creator. This type of approach would be very simple. Applying this concept to this situation, a user would simply show up, type in their search term-phrase into the tool, and get issued back a single line of java code.

    The results would not be saved, nor aggregated. However, within the code there would be something that would allow external platforms to index and archive the phrase or terms.

    Ideally, the Yahoo search developer network would get notified of Y!Q plans in this area, and the developers would create a number of tools that would seamlessly integrate with this archiving-indexing function of Y!Q.

    This approach seems the most feasible.

    A W3 standard

    A more robust approach would be something that is a midway point between the simple-user-tool like the Technorati-tag-creator, and that of the PubSub platform.

    In this middle approach, there would be a more robust support for the platform-code, and there would be a standard phrase or code that W3 would eventually adopt. This approach, although formal would tend to be the most time consuming.

    I would imagine we might hear many debates about the appropriateness of the standards, or get into a heated discussion whether this approach is simply making longer tags.

    Let’s recall the big picture. Even if there is no formal standard created, what we are seeing is the need for more complicated tags to get both indexed and archived; and at the same time relies on these tag-commands within the HTML to do some external analysis of these longer phrases.

    The issue becomes one of will the platforms create something on their own, or will there be some sort of structure to where the complex-tags-within-Y!Q ultimately arrive.

    I’d prefer to see Y!Q simply become what is most useful, regardless the platform, indexing, or standard. Yet, in practice, if there is not wider support for the ultimate direction that Y!Q takes in terms of structure and formal integration, we may simply have new platforms creating new tools in a slightly different way.

    I would prefer that the platforms choose what they want to create, while at the same time all moving in a common direction: That of creating platforms, however different, that creates and supports an external indexing system of those specific target phrases within the Y!Q similar searches.

    Option review

    Because of the simplicity of the Technorati-like-tool, and the complexity of the PubSub-like phrase-storage, and the potentially longer-convoluted approach to W3 standard-creating in support of such a concept, I favor the simple tool.

    Put another way, I favor the easier option of creating a simple tool that would simply create the code and let the users place it into the platform.

    However, the issue is one of indexing. What method would be useful. Ideally, the approach would be transparent to the user, embedded within the code, and the users would have the option to opt-out of the search.

    At the same time, the indexing option would have to be something that was simple enough so that it was useful and didn’t require a separate platform to support; while at the same time something that was useful and robust enough to interact with the main Yahoo search engine: Providing some structure to the words; something that integrated well with the Yahoo platform; while at the same time didn’t become an entity unto itself.

    Summary

    I’ve outlined a couple of concepts on how the Y!Q could be improved. The current approach requires users to copy code and use a patchwork like approach to making the code work.

    Ideally, the Y!Q platform when it finally launches after beta would be something that is one step: Users would simply enter the phrase, and they would get a line of code they could place within their blog or webpage.

    How this is actually done remains to be decided. But recall there are some useful analogies that users are already familiar with: The Technorati tag-creator-tool; the AltaVista language translation tool-single-line; and the concept of indexing tags.

    Ultimately, what I would like to see is a simple mechanism to index these phrases, so that I as a searcher could find patterns in what people were choosing to encapsulate within Y!Q.

    At the high-cost-end of the potential solutions would be a system like PubSub that took the user phrase, exported a code, then allowed users to track these individual subscriptions. Perhaps there might be a time when a platform like PubSub would want to use this information for some sort of marketing or analysis.

    The question remains which enterprise would be willing to support such a tool; and what type of enterprise would see some additional information within this approach that they currently are unable to get through the existing search platforms.

    Perhaps this is another opportunity for the Yahoo Search Developer network to brainstorm and do some more magic. I’m confident we’ll see more interesting ideas.



    LEGAL NOTICE


    Creative Commons License

    This work is licensed under a Creative Commons License.

    You may not copy any of this work to promote a commercial product on any site or medium in the universe.

    If you see this work posted on a commercial site, it violates the creative commons license; and the author does not endorse the commercial product.

    Free to use for non-commercial uses. Link to this original blogspot and cite as .


    -- This is the end of the content --
    " />