08 April 2005

PubSub could make the subscription's HTML-version more user-friendly

I blogged about the strange quirk in the PubSub auto-link from an aggregator.

To recap, what's happening is users are taken not to the content, but to a page in PubSub that has the link, another search box, and several subscription buttons.

This "HTML-version" of the content really isn't: It doesn't show the browser friendly version of the code; nor does the RSS-version of the subscription show the XML code.

The question is: Why is the Newsgator Online showing the "link to PubSub", when we click on the HTML-version of the subscription?

We're not really getting the HTML-version of the subscription. Nor are we getting closer to the content. Rather, we're simply getting a page with unclear intentions, more options, and little guidance.

Another look

I was thinking more about this and thought there might be some logic to it. The problem, in my view, is that the content doesn't show up right away.

Sure, the advantage of having this intermediary step is that the user can get to some links. But the problem is that this is not obvious.

Is there a specific reason why this page shows up when requesting the HTML-version of the page?

Again, I have no clue, but I think there might be a reason. I just don't think the "rest of the content and pages on PubSub" have been updated to clearly communicate what the user is seeing and why it provides the appropriate response.

Remember, your new PubSub user isn't going to have a clue about "your intention of helping htem." Rather, they simply want content if they click on HTML; and they want to see the code, if they click on RSS.

So when they see "something other than content, RSS, or what I ask for", the first thing they think is, "I don't want that." [A negative reaction].

Then we have to make a choice, and start to search. See that? Users were supposed to already make the choice, and have PubSub do searching for them. But this page makes us do it again: Rechoose, and re-select. Yet, even if we choose the available options, we still don't see the HTML-version of the subscription.

Remember...that was the original reason I made the choice...to see the HTML-version of the subscription.

Going forward

What could be done? Well, let's put aside for the moment that this is a Newsgator Online-PubSub integration issue.

Suppose for the moment [not having access to the inside of the PubSub platform] that PubSub hopes to give the users some options. In other words, it could be possible that this is a coding error; but the error is like the chocolate chip cookie -- it leads us to something better than what we originally hoped.

The problem is that the "HTML version" of the subscription doesn't say that when we arrive to the PubSub page. Rather, there's no visual cue that we've got what we wanted.

It would be nice if there was the following:

  • A confirmation message that "this page that we are looking at is, in fact, the HTML-version of the page we requested." [In my view, it is not, but let's put that aside for the moment]

  • A better indication of what can be done on this page. Specifically, if it is PubSub's intention that this "HTML-version page of the subscription" in fact provide various options to look at that content, then so state: "You have selected the HTML version of the content. This page gives you the option to see that content using these three options:

    [a] The Subscription stack [From the box on the left];
    [b] The URI for the bookmark [That can be copied]; or
    [c] The option to see that content in your aggregator [that you can see if you click this link]

    What is annoying is that I, as the user, have already made these choices when I both created the subscription and placed the subscription in my aggregator.

    The new user doesn't need to get confused any more than we already are.

    What would be ideal

    To have the HTML-version of that subscription show up as requested; and to include clear statements in a stripped down version of the responses that PubSub thinks we might want to see.

    But remember to give us what we ask for, not what you think we might be interested in and then, falling down by not giving us access to what we actually asked for and giving more choices to make.

    If PubSub wants to have the same page with the box on the left and the subscription options, I see no advantage of having the search box.

    The search box: Why is it there when requesting the "HTML-version" of the subscription?

    I'm still not clear what the intent of showing the search-box [without the subscription terms]. What do we do with this box . . .update the search terms to get a new subscription? PubSub doesn't currently support this feature, although that would be nice, yet is outside the scope of this link from Newsgator Online.

    However, if the real goal is to ensure that users who have access to the subscription can also modify it, then it would be nice if the original subscription could be modified with this search box.

    Yet, I see nothing that would allow the existing search-terms to both display, and then get modified, and then issue a new subscription against this revised term.

    Also, when we click on "HTML" in the Newsgator Online subscription list, we don't get the "HTML Version of that Subscription" nor is there anything related to that subscription auto-posted to the subscription box. There could be, but we're not there yet.

    In my view, if PubSub and Newsgator Online want to leave things as they are [in displaying the PubSub homepage when we choose HTML], then why not update the auto-linked page with some features that new users can understand:

  • Better indications of what is going on
  • Clearer ways to get access to "what is next"
  • A stripped down version of the PubSub site, with a summary list of links
  • And an easy way to both auto-post the subscription-request into the box, with the option to modify that subscription.

    Again, this final option may be the chocloate chip cookie: That the HTML-version-error might actually lead us to a better PubSub search-support--giving users the ability to quickly modify a subscription-code they got from a third source, other than PubSub or their own search.

    Either way, is fine with me. But right now, I'm not getting the same results that I am getting with other similar requests in the list.
  • I blogged about the strange quirk in the PubSub auto-link from an aggregator.

    To recap, what's happening is users are taken not to the content, but to a page in PubSub that has the link, another search box, and several subscription buttons.

    This "HTML-version" of the content really isn't: It doesn't show the browser friendly version of the code; nor does the RSS-version of the subscription show the XML code.

    The question is: Why is the Newsgator Online showing the "link to PubSub", when we click on the HTML-version of the subscription?

    We're not really getting the HTML-version of the subscription. Nor are we getting closer to the content. Rather, we're simply getting a page with unclear intentions, more options, and little guidance.

    Another look

    I was thinking more about this and thought there might be some logic to it. The problem, in my view, is that the content doesn't show up right away.

    Sure, the advantage of having this intermediary step is that the user can get to some links. But the problem is that this is not obvious.

    Is there a specific reason why this page shows up when requesting the HTML-version of the page?

    Again, I have no clue, but I think there might be a reason. I just don't think the "rest of the content and pages on PubSub" have been updated to clearly communicate what the user is seeing and why it provides the appropriate response.

    Remember, your new PubSub user isn't going to have a clue about "your intention of helping htem." Rather, they simply want content if they click on HTML; and they want to see the code, if they click on RSS.

    So when they see "something other than content, RSS, or what I ask for", the first thing they think is, "I don't want that." [A negative reaction].

    Then we have to make a choice, and start to search. See that? Users were supposed to already make the choice, and have PubSub do searching for them. But this page makes us do it again: Rechoose, and re-select. Yet, even if we choose the available options, we still don't see the HTML-version of the subscription.

    Remember...that was the original reason I made the choice...to see the HTML-version of the subscription.

    Going forward

    What could be done? Well, let's put aside for the moment that this is a Newsgator Online-PubSub integration issue.

    Suppose for the moment [not having access to the inside of the PubSub platform] that PubSub hopes to give the users some options. In other words, it could be possible that this is a coding error; but the error is like the chocolate chip cookie -- it leads us to something better than what we originally hoped.

    The problem is that the "HTML version" of the subscription doesn't say that when we arrive to the PubSub page. Rather, there's no visual cue that we've got what we wanted.

    It would be nice if there was the following:

  • A confirmation message that "this page that we are looking at is, in fact, the HTML-version of the page we requested." [In my view, it is not, but let's put that aside for the moment]

  • A better indication of what can be done on this page. Specifically, if it is PubSub's intention that this "HTML-version page of the subscription" in fact provide various options to look at that content, then so state: "You have selected the HTML version of the content. This page gives you the option to see that content using these three options:

    [a] The Subscription stack [From the box on the left];
    [b] The URI for the bookmark [That can be copied]; or
    [c] The option to see that content in your aggregator [that you can see if you click this link]

    What is annoying is that I, as the user, have already made these choices when I both created the subscription and placed the subscription in my aggregator.

    The new user doesn't need to get confused any more than we already are.

    What would be ideal

    To have the HTML-version of that subscription show up as requested; and to include clear statements in a stripped down version of the responses that PubSub thinks we might want to see.

    But remember to give us what we ask for, not what you think we might be interested in and then, falling down by not giving us access to what we actually asked for and giving more choices to make.

    If PubSub wants to have the same page with the box on the left and the subscription options, I see no advantage of having the search box.

    The search box: Why is it there when requesting the "HTML-version" of the subscription?

    I'm still not clear what the intent of showing the search-box [without the subscription terms]. What do we do with this box . . .update the search terms to get a new subscription? PubSub doesn't currently support this feature, although that would be nice, yet is outside the scope of this link from Newsgator Online.

    However, if the real goal is to ensure that users who have access to the subscription can also modify it, then it would be nice if the original subscription could be modified with this search box.

    Yet, I see nothing that would allow the existing search-terms to both display, and then get modified, and then issue a new subscription against this revised term.

    Also, when we click on "HTML" in the Newsgator Online subscription list, we don't get the "HTML Version of that Subscription" nor is there anything related to that subscription auto-posted to the subscription box. There could be, but we're not there yet.

    In my view, if PubSub and Newsgator Online want to leave things as they are [in displaying the PubSub homepage when we choose HTML], then why not update the auto-linked page with some features that new users can understand:

  • Better indications of what is going on
  • Clearer ways to get access to "what is next"
  • A stripped down version of the PubSub site, with a summary list of links
  • And an easy way to both auto-post the subscription-request into the box, with the option to modify that subscription.

    Again, this final option may be the chocloate chip cookie: That the HTML-version-error might actually lead us to a better PubSub search-support--giving users the ability to quickly modify a subscription-code they got from a third source, other than PubSub or their own search.

    Either way, is fine with me. But right now, I'm not getting the same results that I am getting with other similar requests in the list.
    " />