30 December 2004

XML Pipeline status: A single picture for end-users to see the reliability of the XML-feed pipeline

Nonsense Master asks a good question:

In re reliability, how can information be provided to end-users in terms the users find meaningful?

My thought:

Graphically. Show a picture of an XML-feed pipeline from the point of entry [blogger, provider] to the end-user.


XML Feed Pipeline Components

  • Host, [blog platform, like blogger]
  • platform, [means of transmitting the feed, like Feedburner]
  • pinger, [notification]
  • validator, [feed validity, how to fix]
  • aggregator,
  • e-feed [e-mail to blog], and
  • end-user's reading component [computer, cell]


  • In terms of reliability, the end-user simply want to know "what's the probability my content is going to show up at my target-audience's eyeball?"

    The simple solution is to show along the pipeline the status of those components, as far as their reliability, limits, constraints.


    XML Feed Reliability SnapShot

    Users want: Single image of XML Pipeline Reliability

    A single picture of the XML pipeline would solve the issue of "what is the reliability of the XML-feed-pipeline", pipeline components identified and color-coded to show good to go, workarounds, delays, bottlenecks, and failures.

    Sample
    To see a java-based sample, go to NewsIsFree, and take a look at the color-coded news summary.

    Data
    Here are the sample XML-component inputs the end-user wants to see combined into a single image. The XML-feed components could use XML-feeds to self-report their status real-time.


    Showing which components are optimal for end-user tasks

    Not all components are alike. A given XML-pipeline component may have relative advantages or disadvantages. If users could quickly see [based on what they want to do] which option has the greatest payoff, this will save time.

    For example, if I want to search, it would be good if the system told me which aggregator or feed-search tool could do which types of searches, and what the holes were in the capabilities.

    Identify workarounds

    Show along the route, those methods of working around problems. Example: If a given RSS-feed reports "invalid," but it can still be read and picked up by Yahoo, that's "a workaround."

    Also, if a site that "doesn't take atom" can take a "feed that is converted from Atom to RSS using 2RSS", then that workaround should be shown as a "Green pipeline".

    The end user doesn't care that a given feed is or isn't "valid," -- what they care about is if a host like blogger can still provide content through a platform like Feedburner.

    A feed that can "still be read" by the aggregator [regardless whether it is RSS/atom "valid"] is, in the eye of the end-user "good enough."

    Components self-report status

    The overall reliability of the XML-feed pipeline would really have validity if the "status of each component" self-reported using an XML-feed to the central picture.

    Divergent perspectives

    There are two ways of looking at XML-reliability: One from the perspective of content pushed to the user; and the other way is whether the user can search the content.

    One perspective is from the provider, and the other is from the end-user who may also be a provider of content.

    My major beef with the entire XML-feed concept is that it superbly puts priority on the "push" side of the equation, but when the end-users actually want to search the content, the aggregator search engines are wanting.

    Single-step publishing

    In the end, the XML-feed-concept has a long way to go. It's not as simple [yet] like cell phones. With a cell, you buy it, and you're good to go. On the other hand, with XML, the end-user has to spend days-weeks tinkering with things to make it work. True success will be when there's a standalone-XML-product that a user can, in one step, sign-up and use.

    This means:

  • No multiple steps to create a feed;

  • One-step sign-up to get the XML-feed published to all the aggregators; and

  • Transparent publishing, whereby there are not special buttons to push for pinging the services.

    Simply, the users want to sign up for a platform like blogger, and start typing, and have the end-reader be able to read it without having to worry about validation, site submission, and buttons to place in the blog.

    Summary

    When end-users talk about XML-feed reliability, they aren't talking about the developer's notion of a "valid feed per the specifications."

    Rather, end-uses are more interested in knowing, if there is a potential bottleneck between their keyboard and the end-reader's eyes, what can be done to fix the problem and provide the content to the eye-balls. Nothing else.
  • Nonsense Master asks a good question:

    In re reliability, how can information be provided to end-users in terms the users find meaningful?

    My thought:

    Graphically. Show a picture of an XML-feed pipeline from the point of entry [blogger, provider] to the end-user.


    XML Feed Pipeline Components

  • Host, [blog platform, like blogger]
  • platform, [means of transmitting the feed, like Feedburner]
  • pinger, [notification]
  • validator, [feed validity, how to fix]
  • aggregator,
  • e-feed [e-mail to blog], and
  • end-user's reading component [computer, cell]


  • In terms of reliability, the end-user simply want to know "what's the probability my content is going to show up at my target-audience's eyeball?"

    The simple solution is to show along the pipeline the status of those components, as far as their reliability, limits, constraints.


    XML Feed Reliability SnapShot

    Users want: Single image of XML Pipeline Reliability

    A single picture of the XML pipeline would solve the issue of "what is the reliability of the XML-feed-pipeline", pipeline components identified and color-coded to show good to go, workarounds, delays, bottlenecks, and failures.

    Sample
    To see a java-based sample, go to NewsIsFree, and take a look at the color-coded news summary.

    Data
    Here are the sample XML-component inputs the end-user wants to see combined into a single image. The XML-feed components could use XML-feeds to self-report their status real-time.


    Showing which components are optimal for end-user tasks

    Not all components are alike. A given XML-pipeline component may have relative advantages or disadvantages. If users could quickly see [based on what they want to do] which option has the greatest payoff, this will save time.

    For example, if I want to search, it would be good if the system told me which aggregator or feed-search tool could do which types of searches, and what the holes were in the capabilities.

    Identify workarounds

    Show along the route, those methods of working around problems. Example: If a given RSS-feed reports "invalid," but it can still be read and picked up by Yahoo, that's "a workaround."

    Also, if a site that "doesn't take atom" can take a "feed that is converted from Atom to RSS using 2RSS", then that workaround should be shown as a "Green pipeline".

    The end user doesn't care that a given feed is or isn't "valid," -- what they care about is if a host like blogger can still provide content through a platform like Feedburner.

    A feed that can "still be read" by the aggregator [regardless whether it is RSS/atom "valid"] is, in the eye of the end-user "good enough."

    Components self-report status

    The overall reliability of the XML-feed pipeline would really have validity if the "status of each component" self-reported using an XML-feed to the central picture.

    Divergent perspectives

    There are two ways of looking at XML-reliability: One from the perspective of content pushed to the user; and the other way is whether the user can search the content.

    One perspective is from the provider, and the other is from the end-user who may also be a provider of content.

    My major beef with the entire XML-feed concept is that it superbly puts priority on the "push" side of the equation, but when the end-users actually want to search the content, the aggregator search engines are wanting.

    Single-step publishing

    In the end, the XML-feed-concept has a long way to go. It's not as simple [yet] like cell phones. With a cell, you buy it, and you're good to go. On the other hand, with XML, the end-user has to spend days-weeks tinkering with things to make it work. True success will be when there's a standalone-XML-product that a user can, in one step, sign-up and use.

    This means:

  • No multiple steps to create a feed;

  • One-step sign-up to get the XML-feed published to all the aggregators; and

  • Transparent publishing, whereby there are not special buttons to push for pinging the services.

    Simply, the users want to sign up for a platform like blogger, and start typing, and have the end-reader be able to read it without having to worry about validation, site submission, and buttons to place in the blog.

    Summary

    When end-users talk about XML-feed reliability, they aren't talking about the developer's notion of a "valid feed per the specifications."

    Rather, end-uses are more interested in knowing, if there is a potential bottleneck between their keyboard and the end-reader's eyes, what can be done to fix the problem and provide the content to the eye-balls. Nothing else.
  • " />