24 March 2005

Bizarre mystery revealed: Feed skins, iPod support, and FeedBurner

-->
FeedBurner has feed skins. You can apply them to your feed. But a feed skin designed for a browser is not the same as a feed skin designed for an aggregator.

This note goes into a discussion of the FeedBurner skins, and discusses the apparent constraints in integrating text-feed constraints in aggregators to those feed skins that are designed to support iPod feeds in browsers.

Note: This is a follow-up to this origial blog, here


Abstract


There are a number of constraints that relate to feeds. Some constraints apply to the browsers. Others constraints apply the feeds. Some constraints apply to only the feed-skins in the browsers, other constraints apply to the feeds as they appear in the aggregator.

Not all constraints universally apply to all other constraints. Some constraints that relate to text-based feeds do not integrate with a feed-skin that is designed for a browser. In turn, those feeds that are using an iPod-skin do not accept constraints related to text-based feeds.

This note outlines the new feed skins, identifies the nature of the decisions driving users to use various options, and hopes to outline a basis to integrate the text and iPod feed-related constraints into a single logic array.


Feed Skins


FeedBurner has these browser friendly skins. One new browser friendly skin is devoted exclusively to iPod support They work with the iPods. I like the layout and design of these browser friendly skins. I like to call them feed-skins.

Skins are nice. They customize a feed. And they add something. Feed skins can be applied to either the subscription-end [FeedBurner-supported] or to the publication end [content-creator-added].

They can also be applied in the aggregator. The goal is customizing the flavor of the feed. There are three different types of groups that will choose the skin-selection-decision:


  • 1. the publisher-content-creator,
  • 2. feed-subscriber, or
  • 3. the content-searcher-consumer


  • One day, I imagine that there will be a specialized enterprise that can create custom feed-skins. Just as we have today custom skins for instant messengers and browsers, so too will there be a day when we have custom skins for not only feeds but aggregators.

    Not all feed skins are alike. Some are designed to integrate with only the browser. Other skins can integrate with the aggregator.

    Publishers and content-searchers like feed-skins because they are interesting to look at.

    Content consumers, at the tail end of the pipeline, also like skins in their aggregator. They can customize a platform.


    Constraints on subscriptions


    The other reality of subscribing to feeds is that not all people are able to download the subscription mechanism. In other words, despite the name, the USM is not universal. It does not necessarily download behind a firewall; nor are local IT departments necessarily interested in http-tunneling and workarounds. The flat-out answer is ‘no downloads’.

    Thus, the workaround is to assign the subscriptions to the Amphetamine links. This gives users the option to subscribe to a feed through their chosen aggregator, without having to work with the FeedBurner skin.

    At the same time because I like the iPodder-feed-skin [browser friendly version], but it doesn’t have any buttons for text-aggregators, I’m in a quandary.

    How do I showcase my feed with the iPodder-skin, while still giving my readers the tools to download and subscribe to my feed without having to download the software for the USM?

    The answer is: Two links: The first link goes to the iPod-skin [which shows off the feed]; and the second link goes to the Amphetamene link that has a list of all the aggregators.

    At this juncture, one would think that there would be a way to combine both the fancy iPod-skin with the non-USM-subscription options, and at the same time give those who are behind a firewall a way to subscribe.

    It appears that using two-links is the only way to do this.

    So, there appears to be an area of potential enterprise: Create new skins for other feeds that are just as snazzy as the iPodder-browser-friendly skin; and at the same time develop a feed-skin that supports the text-aggregators; and at the same time ensure that these feed skins work with those subscribers who cannot download the USM.

    Consider more broadly who the non-XML-users are: They are approximately 95% of the population, according to the Pugh Center for Research. Most people who do not subscribe to feeds, and are not into XML generally use their internet connection from work; and these people generally are behind firewalls.

    Bluntly, it appears as though the way to tap into this non-XML community is to create some neat skins that invite them to subscribe, and at the same time make it easy for them to subscribe despite being behind a firewall.

    The solution, in my view, is not to create another subscription tool. But to advertise the existing links at Amphetamine, and then allow publishers a way to show off their feed to the new XML-users in a way that attracts their interest.

    Feed burner’s iPod-skin does this. And the Amphetamine-links do this. However, the two are not integrated.

    The iPod skin is designed for browsers. The Amphetamine links are designed for feeds. In the middle, are two sets of commands in FeedBurner. One is related to the browser-friendly skin, and the second set of commands is related to the feed-content length.

    Again, the purpose of this note is to explore the apparent firewall between the iPod browsers skin and the feed-support tools for aggregators.


    Apparent dual track development


    It appears as though the two feed-support options in FeedBurner are similarly not integrated. In other words, it appears as though there are two development channels at work here.

    On one hand, we have the iPod-skins for browsers, but these don’t integrate with the text-aggregators; and we also have the USM-development, but these are not supportable behind firewalls; and we have two options in FeedBurner on how to tailor both the browser and a feed, but these choices also do not integrate back and forth between the text-in-browser and feed-in-aggregator.

    Even though I choose in the browser-friendly-version to have both titles and full content, these choices do not integrate with the later choices in the summary burner. I can choose to limit the number of characters, but this choice only applies to the non-iPod skins.

    Specifically, it appears as though if I want to choose an option in the browser-friendly burner [and I want any content to show up] I have to choose full titles and full content. Based solely on the options, this appears to be the only way to get any content to show up.

    In the broad perspective, it appears as though there is some room for some cross-platform integration. I’m not suggesting that there be a new tool designed.

    I am suggesting that there is an opportunity for designers to create feed-friendly-skins; and at the same time develop some skins that support both iPods and text; and that the constraints-parameters in FeedBurner should also be integrated so that [a] browser-friendly options integrate with [b] the options related to content length in the feeds and aggregator.


    Publisher interest in limiting feed content length


    At the same time, if we consider the notion of feeds, one goal of FeedBurner is to monitor the number of readers for the feed. If publishers limit the length of their content to something less than the full content, it is more likely that an interested reader will click on the feed-link, and the publisher will know who is using that content.

    So, when I choose in the browser-friendly option the following: Full title and full content [with the hopes that the content be truncated by the later constraints in the summary feed, to only five [5, not 50] characters], then I as the publisher hope to do a couple of things:


  • A. Limit the length of the content in my feed
  • B. Rely on the FeedBurner to show full titles, and full content, and then have that content length constrained by the number of characters in the summary feed to only 5 characters.


  • But that’s not what is happening. I choose full content and titles in browser-friendly-option; and then below I limit the number of characters to only 5 so that I can get my readers to click on the feed, and then I’ll know who is reading my content.

    Again, this is not what is happening.

    I’ve chosen full content and full titles in the browser-friendly-feed with the hopes that my content length in my feed will be limited to only 5 characters by the summary feed-options; and at the same time I’m using the iPodder skin to show off the feed to the potential new subscribe in the browser; and then relying on the Amphetamine link for the non-iPodders to subscribe to the text-feed.

    Oh, and here’s the surprise. Despite going out of my way to read the instructions, and carefully follow the detailed comments I get back: Guess what, I choose full content and full titles [in the iPod-skin]; and then choose 5 characters [in the summary feed]…but guess what happens?

    Despite those limitations in the summary feed to only 5 characters, I still get the full feed content showing up in my feed when it is displayed in the aggregator.

    Who cares? Well, one of the selling points of the ‘limit the characters in the content’ to the feed was that my readers would have to click on the site to see the rest, and this click through would get registered.

    However, if the full content is shown [despite my limiting it only to 5 characters], then there’s no reason for anyone to click the link, and no way for me to know [who is or is not] reading the full feed-contents.

    In other words, my effort to add an iPod-feed to a text-only subscription, and at the same time have a way for people behind a firewall to subscribe, gets thwarted:


  • My constraints as I intended to apply to the feed aren’t accepted;
  • The full feed shows up;
  • The constraint in option two [in re summary feed] doesn’t mesh with the only apparent options I have in the first choice [at the browser friendly feed].


  • This is what we know going into the discussion. Let’s review the comment from FeedBurner, from Matt Shobe:.


    FeedBurner Note


    Hey there, It sounds like we've created a bit of a usability monster. let me see if i [stet] can untangle this a bit.

    The two "commands," or Feed Services, you're referring to appear to be our Browser-Friendly and Summary Burner services.

    Browser-Friendly specifically affects the visual display of the feed in a browser (especially XSLT-capable browsers, such as Mozilla foundation products and IE 5.5 and later). Browser-Friendly changes the visual appearance of a feed (in web browsers only), but not its actual content; you can choose to have content item titles and bodies, titles only, or no content items at all appear when the feed is viewed in a browser. The underlying XML source code of the feed is unaffected in every case, so the display of content items in an RSS aggregator would be complete and unaffected.

    Summary Burner, meanwhile, truncates the actual body content of content items in the feed to the character length you specify when setting up that service. Its purpose is to allow you to create a "summary only" version of another full-content feed quickly. Feeds with Summary Burner applied do appear to be truncated in RSS aggregators.

    Both services work together without overlap or conflict.

    . . . break in FeedBurner comments . . .

    Response-COMMENT

    This is not correct. The two services do not work together, and there is a conflict. I’ve chosen full titles and content for my iPod feed; and I’ve limited my content in the summary feed to 5 characters.

    Small problem. The full feed shows up. That is a conflict. That is not working together.

    If there was no conflict, my decision to limit the number of characters in the feed that reports to the aggregator, would also apply to the iPod skin, even though one is for a browser and the other is for the aggregator.

    We don’t have that. Thus, although you are saying they are integrated and there is no conflict, there is, in factno cross over of data and user-options from the iPod-bowser-skin-feed to the feed-content length in the aggregator.

    . . . continuing with FeedBurner comments . . .

    Feedbuner

    If you apply both to a feed, the "Browser-Friendly" view of that feed when displayed in Mozilla or IE will reflect your chosen options; content items will display their titles and text content, titles only, or will not display at all.

    . . . break in FeedBurner comments . . .

    COMMENT

    This is where the divergence occurs. Notice FeedBurner is focusing on the browser. I’m looking at both the browser and the aggregator.

    I want to be concerned with the browser for my potential subscribers when they look at my iPod skin. I also want to be concerned with the aggregator so that my subscribers are going to my feed, but just enough so that I can monitor who is reading the detailed content.

    Again, I don’t care only about a browser. I also care about the aggregator. When I choose to see full titles and content in the first option [for the iPod skin], but limited to 5 characters for the summary feed], then I am hoping that the aggregator will limit the length of the feed. That way my readers who subscribe using the amphetamine link, will see just a summary of the feed in their aggregator, and click through to my full content so that I can track them with FeedBurner.

    That isn’t working. In my view, this is a conflict between the browser-friendly setting [full titles, and content] and the full feed settings [limited content]. What needs to happen is recognize that the publishers who are using browser-friendly-iPod-skins also want to have the ability to limit the number of words in the iPod-feed.

    Clearly, the problem is that iPod is for iPod [sound, and a browser feed]; while the text-related-options are aggregator-related decisions [for text, not sound in the aggregator].

    …continuing the FeedBurner comments….

    FeedBurner

    Meanwhile, in the _underlying feed XML source code_, Summary Burner will have shortened the text content of the body to the character length you have specified.

    . . . break in FeedBurner comments . . .

    Response- COMMENT

    I hear what you are saying. The source code gets shortened. If that is true, why is the full comment feed showing up in the aggregator?

    Answer: Despite choosing the summary feed to be only limited to 5 characters, this choice of number of characters in the summary feed [that relates to the aggregator] has no impact on the choice I have for the IPod skin [which is related to the browser]

    Question: How do I give my readers a taste of my text-comments using the IPOD skin selections?

    Answer: There needs to be away for the content-length numbers [selected in the summary feed] to also apply to the iPod-skin selections. Currently , this does not appear to be working.

    Despite what FeedBurner is saying about what should be happening, I’m not getting that.

    You say that when applying both to a feed, the “browser-friendly view” will be displayed. OK.

    A. I chose titles and text content in browser friendly, for the iPod skin in the browser.

    B. At the same time in Summary Burner, I chose 5 characters, for the feed appearance in the aggregator.

    If what FeedBurner is saying is true, that means that when I combine both options together, I should see the comment feed with detailed comments, and that content truncated to only 5 characters.

    Here’s the rub: I didn’t get that. I go the opposite. I got full content in the aggregator ~despite~ choosing/limiting the content in Summary Burner to only 5 characters.

    Based on what little I know, it looks like the Browser-friendly version and summary versions are doing exactly the opposite of what I want:

  • Content length

    I chose to limit the content to 5 characters; the feed that showed up in the aggregator showed the full content.

  • Feed appearance in aggregator not shortened

    I chose to have titles and full content in the browser friendly option, with the hopes that my second selection in the Summary Burner would integrate with the browser-friendly selection. Again, this did not appear to work. Rather, I got a feed-reported-to-the-aggregator that appeared to report full titles and content [as selected in the browser option], but not affected by the Summary Burner [full content, despite the goal of reducing the visible content to a fraction of the overall feed].

    If the summary burner-option-selection-choice did have any impact, then I should’ve gotten a feed that had full titles, and was truncated by the second-command in the summary burner. That did not appear to work.

    In my view, what should’ve happened was the following:

    When I chose in browser-friendly-option to have full content and titles, my choice about content should have integrated with the summary burner. Specifically, browser-friendly option of full content and title, should be truncated by the number of characters selected in the summary version options.

    Again, I got the full-feed-content in the aggregator. This is not what I want. Nor what I thought I told the summary feed.

    Thus, I conclude that the browser-friendly version of the feed appears to have greater weight and emphasis during the coding and display. Again, it looks as though what is happening is that because both options were independently developed along parallel development efforts, that there wasn’t a meshing back of the results after the deployment of the iPod skins.

    . . . continuing with the remarks from FeedBurner . . .

    FeedBurner

    For example, you would notice in a Browser-Friendly feed that has the "Don't List Items" setting applied that the original XML source still contains every feed item (they're not actually removed from the feed, just from its display in the browser via XSLT instructions).

    . . . break in FeedBurner comments . . .

    Response-COMMENT

    Excellent! Now you understand what I am saying. But let’s keep focused. I’m not talking about the number of items in the feed. I’m talking about the number of characters that appear in an individual feed-item.

    Let’s not confuse feed-length with comment-length. One applies to the number of items in a feed. That is not the same as the number of characters that appear in an individual item that appears in my aggregator.

    Let’s get back to the options in FeedBurner. Rather than choosing ‘don’t list items’ I chose to list both titles and full content, with the hopes that the summary-burner would truncate what appeared in the comment feed. I was hoping that the total number of characters that appeared in the given feed-spot-item in the aggregator would be a fraction of the total number in a given item in the original published feed.

    Again, this did not occur. Rather, despite choosing full title and content in the browser-friendly-feed, my content was not truncated by the summary-burner selections.

    Again, I’m not talking about the number of items in the feed; I’m talking about the number of characters in an individual feed-comment.

    Question: How do I get the iPod skin feed to show only a portion of the text-content? Answer: Nobody thought of this because the iPod skin was not designed for text, it was designed to display a short comment about the IPod feed.

    But that’s not what your users are doing.

    Your users are stuck with a Pod-skin [that they want to use], and they also have to link to a non-USM-link for their potential subscribers to use [who may be behind a firewall and can’t download the USM].

    Your users are actually doing this: They are using the IPod-skin and they want to also have the text content on the IPod skin limited to a defined number of words so that their text-readers have a reason to click into the content, and the publisher [me] will have a way to know which content is getting attention; and which content is getting ignored.

    This currently is not working. Why? Because the feed-content-length is in one set of instructions and it relates to an aggregator; while the iPod skin is a second set of commands and it relates to the appearance in the browser.

    Two commands. Two different functions. One for aggregators. Another for browsers.

    But your users want them to be mixed. So that they can use an iPod skin, and then have that iPod skin deliver the feed to the aggregator, and then have that reported feed truncated so that the readers will then go back to the original platform so that the publisher will know who is or is not reading a particular spot.

    . . . continuing with the FeedBurner comments . . .

    FEEDBURNER

    If that same feed also had Summary Burner applied to it, and the 'maxmimum [stet] content length' was set to 50 characters, only whole words that fit within the 50 character limit would appear in both the displayed feed and source code -- FeedBurner definitely shortens the items in its version of your original source feed.

    . . . break in FeedBurner comments . . .

    Response-Comment

    Indeed, you have well articulated the constraints that apply to the aggregator and the feed that appears in the aggregator.

    At the same time, what I would like is the option to apply these constraints in re content length of an individual feed-item to the iPodder skin that gets wrapped around my feed.

    To be blunt, you’re making my point: The number of characters can be limited to something less than the full length of that individual spot. But the goal here is not to simply apply that constraint to a text-based-feed. Rather, the goal is to apply these text-based-constraints-for-an-aggregator also to the iPod skin that integrates with the browser.

    If the iPod skin-feed that shows up in my aggregator was truly integrated, then what should be happening is that I would be able to define the number of characters that would appear in an individual spot for the aggregator, and have these constraints apply to the iPod skin.

    This not what is actually happening. What you say should be limited, is not getting limited. The feed-parameter related to the aggregator does not also apply to the feed-parameter of an iPod skin primarily designed for a browser.

    That is a sign of things not working together.

    In theory, if the ‘maximum content length’ was set to 5 [not 50, but 5] characters, then the number of whole words that fit into that length should be limited to just 5 characters or nothing.

    Again, I got the opposite.

  • Despite limiting the number of characters for the feed in the aggregator, I got the full content; and

  • Despite choosing only 5 characters in the ‘maximum content length’, I got the full content of the comment. So, it does not appear as though the browser-friendly-options and the summary-options are integrating.

    . . . FeedBurner continues . . .

    FEEDBURNER

    I hope this helps clarify the outcome a bit. Our upcoming revision to the FeedBurner user interface incorporates a considerable amount of user feedback and is intended to make much more apparent how applied services interact to transform a feed. Thanks for posting these detailed observations!

    . . . break in FeedBurner comments . . .

    COMMENT:

    Yes, you’ve clarified what should be happening. But my point is that despite your clear instructions on your platform, and your remarks above, what is happening is not matching what one would think is happening.

    When I go into browser-friendly-option and choose titles and full content for the browser-friendly-version [which I like to call a feed-skin], I am expecting that the two commands in both the browser-friendly-options and the summary-burner options to integrate.

    This does not occur. I can constrain the number of characters for a comment feed that appears in the aggregator; but this constraint does not appear to apply to the iPod skin.

    This makes sense. The iPod skin is designed for the browser. The second set of commands in the FeedBurner related to content appearing in the aggregator.

    But I want to do something else. I want to use the iPod skin to show off my feed; and then have the content-constraints [that were designed for an aggregator-text-feed] also to apply to the iPod skin that was designed for a browser.

    I want to use the iPod skin designed for sound to also support text-based-feeds in that when I input constraints to FeedBurner in re content-length in the aggregator, then FeedBurner should also apply those constraints to the iPod skin.

    What I am looking for

    You have explained the terminology well. I understand what should be happening You are very clear on that. I am not clear that what I have said [that the two options do not appear to be correctly integrating] is getting through.

    All I need to read from you is, ‘yes, we understand what should be happening; we hoped to design the system so that the summary burner and the browser-friendly burner’ are integrated.

    ‘Yes, we understand that the two commands should be reasonably integrated, but they are not.

    ‘Yes, we understand that you followed the directions, and chose full content and tiles [in the browser friendly version], with the expectation that the content of the feed be truncated by the summary burner [to only 5 characters, not 50, but 5, as in five]…but in a practice…the actual content of the feed was not truncated, as directed by the summary burner.

    ‘Yes, we understand that the two functions should be working together; and that the browser-friendly-options should be integrating with the selections in the summary feed. A reasonable person might conclude that the number of characters chosen in summary feed would affect the view in the browser-friendly-version.’

    ‘Yes, we understand that the reasonable person could attempt to have chosen both a browser-friendly version [ to display the nice feed-skin], and at the same time directed their subscribers to subscribe to a feed URL at Amphetamine, making the issue of what was actually on the iPodder skin irrelevant to what was appearing in the aggregator.”

    iPod skins and subscriptions without USM

    Here’s the deal. I like the iPodder feed-skin. At the same time I also like the fact that I can [or should be able to] modify my summary feed to a number of characters.

    Because I want to use both the summary feed constraints [limiting the number of characters to 5], I thought that I could choose both the browser-friendly-option [iPod skin] to showcase the feed; and then use the amphetamine-link for my readers to actually subscribe.

    When the iPodder-skin first came out, there was some discussion about subscribing to the feeds. In my view, the nice choice was that I could showcase my feed with an iPodder skin; and at the same time, although there remains no way to subscribe to the feed in a non-iPodding platform, I could always use the amphetamine links as a subscription link.

    The solution is twofold: How to showcase my feed using the IPodder-skin; and at the same time use the amphetamine-link for the actual subscriptions.

    I’d like to be able to use both the iPodder feed-skin [browser friendly version] even though there is no link on that to any XML-aggregators for non-iPods [like bloglines]. My goal is to showcase my feed with the iPodder skin; and then use the amphetamine link for the actual subscriptions so that the readers can link to their text-aggregators.

    Why would someone want to use the amphetamine link for a subscription? Well, surprise! Many people who are non-RSS users are behind firewalls. It makes no sense to have a download requirement under the subscription mechanism when my new subscribers are behind a firewall.

    At the same time, I’d like to have a simple subscription-mechanism using a link. So, I’m forced to choose to work with what I have: Showcase the feed with the iPod-skin [browser friendly version that has only iPod links, which I don’t’ want]; then link the actual subscription to the Amphetamene links.

    I was assuming that many people were relying on both IPod-skins and the non-USM-subscription; meaning: That most people would already know that there had to be a relationship-linkage between the feed-skin [for iPodders, browser friendly], and the summary feed [which integrates with the selections related to content].

    In my view, because the feed-skin does not link directly to a text-reader aggregator, that would mean that people would know to use two options: One option being the IPodder-friendly-feed [iPod-skin, browser friendly feed], and at the same time link to the USM.

    In other words, I was assuming that because people were using an IPod skin with a non-USM subscription link, that there would also be a parallel relationship between the browser-friendly-options and the summary feed options about content.

    Clearly, I am not correct.

    Here is what I would like:

  • There be the option to have more skins like the iPodder skin
  • The ability to have a subscription mechanism that currently exists with Amphetamine
  • The ability to subscribe to a feed with any of the feed-skins
  • The ability to input my feed-commands in the browser friendly feed [for the IPod=skin] and have those constraints integrate-synchronize-work with the constraints I assign to the summary feed [in re the number of characters].

    At this juncture, I’m not clear that I can rely on the ‘number of characters in the summary feed’ as a way to limit the number of characters that actually shows up in the aggregator.


    Conclusions


  • 1. The iPod skins are not compatible with text-limiting constraints. iPod-skins were designed to appear in the browser. The constraints applying to feed-appearance-in-the-aggregator are not currently also applied to the iPod skin, which is currently simply just a browser-based tool for non-text feeds. The only text that is constrained is in the comment for the iPod feed; but this comment is not affected by the constraints affecting the length of the text-feed in the aggregator.

  • 2. The subscription tools have diverged: One supporting iPods and another support Text.

    To subscribe to a text-feed we can use either a direct subscription tool like Amphetamine, a button tool like Newsgator, or the USM. USM is not an option for those behind a firewall.

    At the same time publishers who want to showcase their feed with an iPod skin are not able to limit the length of the text appearing in the aggregator. By choosing to have the full title and content appear in the browse overrides the publishers’ choice to have that content also limited in the aggregator.

  • 3. The subscription options have also diverged: One set supports text-based feeds, and another set affects pod-skins.

    Right now publishers have to make a choice that they do not want to make:

  • showcase their content with the iPod skin,
  • limit the length of their content for purposes of tracking content-popularity; or
  • providing tools to support users unable to use USM.

  • 4. The subscription tools do not integrate: Users who cannot work with USM because they are behind a firewall, are similarly limited in their ability to use a flashy skin in conjunction with a text-based feed

    Ideally, the publisher should be able to enter a single command on content length that equally applies to both the aggregator and browser displays for any feed, regardless whether that subscription tools and content appears in the aggregator or the browser.

  • 5. Aggregators will display a full text-feed for the iPod-skin, even when users have chosen to limit the number of characters in the text-based feed

    If users choose to limit the length of a text-comment-feed in their aggregator, they have to use the non-iPod skin.

  • 6. Users are not distinguishing between Pod-skins and text based feeds

    Users would like to have the option to have text-based-constraints intended for aggregators to also apply to constraints on the iPodder skin. Users would also like the option to use the iPod skin, even though they are not issuing an audio-feed. iPod does have a text reader.

    Text-publishers would like to be able to limit the total number of characters in the FeedBurner feed so that iPod-users who read the text-feed have an incentive to read the full feed; and at the same time the iPodders who are using this text-reader in their iPod only get a snippet of the entire feed.

    Think of the iPod skin as something that text-publishers can use to attract iPod-text-readers to text content. Think of aggregator-content-constraints as something that publishers would like to also apply to the text-comments in the iPod skin so that readers reading text in their iPod get a fraction of the total feed-comment.

    This will save the iPodders from getting jammed with full-feeds; and at the same time, ensure that the iPodders-reading-text can still get access to the full text if they want to read more; and publishers will know whether the content there are providing on this iPod skin is getting read or not.

  • 7. Users want tools that let them make text-related constraints to feed choices that are focused on iPod feeds

  • 8. iPod skin feeds are not effectively integrated with the text-based constraints

    Publishers would like the constraints that apply to text-feeds-in-aggregators to also apply to the iPod skin that was originally designed for just browsers. Content publishers would like the ability to seamlessly have their text-length-constraints that apply to feeds-in-aggregators to also apply to those fancy iPod skins, regardless the original intent to only use the skin in a browser.

  • 9. Text based constraints in browsers are not the same as text based constraints for aggregators

    When we talk about constraints in the FeedBurner, there are two tracks. One applies to the browser-based-iPod skin; and a second track applies to the feed-content-appearing in the browsers. Currently, publishers who want to limit the number of characters appearing in the aggregator and apply this constraint to the iPod skin are not able to do so.

  • 10. Aggregator-friendly, browser-friendly, and publisher-friendly skins are not one in the same

    Publishers would like to have a single set of commands that seamlessly get applied to all feed-skins regardless whether those skins are primarily designed for aggregators, browsers, or some other display option. Publishers would like the option to have their feed showcased using a custom-skin. Currently, the only fancy skin is the iPod skin. However, this skin is designed for browsers. It was not designed to support the objective of limiting the number of words in an aggregator.

    If publishers want to limit the number of words that appear in an individual feed-spot that is then showcased in the aggregator, publishers currently have to make a choice: Do they go with the plain vanilla skin, or the fancy one.

    Either way, neither option supports those subscribers who are unable to download the USM because they are behind a firewall. Thus, for publishers to showcase their feed to new subscribers, publishers are currently asked to choose between a skin that doesn’t integrate with text; or a skin that only works with USM.

    I have chosen a middle ground. To use the Amphetamine subscription link, and then also showcase my feed with the iPod skin. By making that choice, I have chosen to let the entire feed-content appear, thereby defeating the objective of having a content-summary and tracking the total number of subscribers linking on a particular feed-spot.


    Current User Constraints that could be Eliminated


    FeedBurner has some nice iPod skins. The users are using these to show case non-IPOD feeds. Users who are behind a firewall are also stuck with a subscription tool that cannot be downloaded. Users, in order to support those subscribers who cannot use USM, are forced to use the Amphetamine links or something else.

    In order to show off their feed, some users may choose to showcase their feed with the IPOD-skin [browser friendly], while at the same time linking their potential subscribers to the Amphetamine links.

    In order to user the iPod skins, and still support users who have no way to download USM, the publisher has to use two feed settings: One with the iPod-skin [browser friendly option], and then give a link to the subscribers to amphetamine.

    If users are using text-based feeds with the iPod skin, then they cannot rely on the FeedBurner’s summary feed option to limit the number of words on the content. If users want to use the IPOD skin for a text-feed, the options in the second-set-of-options [summary feed] that limit the number of characters, will not work.

    In practice, the full feed gets shown in the aggregator. Whether or not the feed gets shown in the browser is not relevant to those who are viewing the actual subscription content in their aggregator.

    Publishers want to make sure their content is displaying properly so that their readers are clicking through to the detailed content. The goal of the publisher is to limit the number of characters in the feed so that the interested reader will click through and register a hit, that way the publisher is able to determine which content is getting looked at, and which content is getting a pass.

    Publishers also want to make their feeds visually more attractive. One option is to use the iPodder skin. However, this is designed for a browser; and the constraints in the summary feed will not affect the iPodder skin, and do nothing about limiting the feed appearance in the aggregator.

    Rather, the constraints in the summary feed [when one is using the iPodder skin] only are designed to work with text-based feeds. If users want to constraint the number of words in a feed that report to the aggregator, the summary feed option related to characters does not support these choices.

    Rather, the user has to currently make a choice: Do they want to

  • A. Have an iPod-skin to show off their feed, and give up their ability to limit the number of words in the feed that reports to the aggregator; or
  • B. Do they want to forego the flashy iPod skin, in the hopes of limiting the number of characters in the feed as it appears in the aggregator.


  • Because both options do not work, there is not merit to say that both services are fully integrated. If they were integrated, users would be able to adjust the number of characters in the summary feed, and have these options affect the iPod-skin as the text reports in both the browser and aggregator.

    Currently, the constraints are focused on only the existing channel: iPod skins as they appear in the browser; or text-based feeds as they appear in the aggregator.

    FeedBurner does not currently support the following third mix: iPod skin reporting limited text in an aggregator

    At this juncture the iPod feeds are not integrating with the constraints related to content-text-feeds in re aggregators.


    User tips: Workarounds have failed


    If someone wants to limit the number of words in an iPodder skin, so that the total content in their feed as reported in the aggregator is small so as to attract the reader to click on the link, the current FeedBurner options do not support this.

    Translation: A publisher can showcase their feed in the browser using the IPOD-skin; but their goal is to have the content-length truncated by the second set of options in the summary feed, and have those options apply to the feed displayed in the aggregator.

    If you want to show off your feed and want to support readers who cannot download USM, and still track the number of readers who are clicking through to your content, you may have to wait. FeedBurner currently will give you the option to subscribe to a feed, but the feed-length-options are not integrating with the feed-skin options.

    If you want to track your subscribers and clickthroughs by limiting content to a small fraction of your feed, you cannot use the Podcasting skin. If you choose the iPod skin, something in the FeedBurner platform overrides your choices in the summary feed, and even if you pick 20 characters, the FeedBurner will still show the entire feed content in your aggregator.

    However, this is not a nice thing. For those publishers who know their potential pool of subscribers is not interested in code, these new subscribers are more likely to be interested in a feed if it has flashy feed skins. But it is unfortunate that despite a flashy feed skin, I cannot also click on another option in the summary feed that will limit the number of words displayed in the iPod-compatible feed.


    Users would like to be able to, among other things:


  • Input the content-length they want to see in their comment-feeds, and have those constraints apply to any skin.

  • Input constraints that apply to content in the aggregator-feed, and have those constraints apply to the iPod skin, even when the publishers is not using audio, but only a text-based feed.

  • Input a single set of characters and constraints into a single panel. FeedBurner would then appropriately apply the constraints to both the browser-skin-text and the aggregator-content;

  • Use the iPod-skin for a text-feed;

  • Have the option to use other colorful feed-skins;

  • Load and subscribe to feeds even if they are behind a firewall;

  • Use workarounds and backups in cases where FeedBurner' subscription skins are not working;

  • Apply a single-click subscription to link from a colorful skin designed for browsers and also use that platform to showcase feeds that may or may not be related to text, audio, or visual; and

  • Use other skins to support and can be tailored to user specifications to a variety of medium, not limited to text or audio, but also visual-feeds that we may get in Flicker.


  • Next Steps

    It remains to be seen whether FeedBurner adopts these changes, other enterprises emerge to provide these services, or whether there is a combination of the two.

  • FeedBurner has feed skins. You can apply them to your feed. But a feed skin designed for a browser is not the same as a feed skin designed for an aggregator.

    This note goes into a discussion of the FeedBurner skins, and discusses the apparent constraints in integrating text-feed constraints in aggregators to those feed skins that are designed to support iPod feeds in browsers.

    Note: This is a follow-up to this origial blog, here


    Abstract


    There are a number of constraints that relate to feeds. Some constraints apply to the browsers. Others constraints apply the feeds. Some constraints apply to only the feed-skins in the browsers, other constraints apply to the feeds as they appear in the aggregator.

    Not all constraints universally apply to all other constraints. Some constraints that relate to text-based feeds do not integrate with a feed-skin that is designed for a browser. In turn, those feeds that are using an iPod-skin do not accept constraints related to text-based feeds.

    This note outlines the new feed skins, identifies the nature of the decisions driving users to use various options, and hopes to outline a basis to integrate the text and iPod feed-related constraints into a single logic array.


    Feed Skins


    FeedBurner has these browser friendly skins. One new browser friendly skin is devoted exclusively to iPod support They work with the iPods. I like the layout and design of these browser friendly skins. I like to call them feed-skins.

    Skins are nice. They customize a feed. And they add something. Feed skins can be applied to either the subscription-end [FeedBurner-supported] or to the publication end [content-creator-added].

    They can also be applied in the aggregator. The goal is customizing the flavor of the feed. There are three different types of groups that will choose the skin-selection-decision:


  • 1. the publisher-content-creator,
  • 2. feed-subscriber, or
  • 3. the content-searcher-consumer


  • One day, I imagine that there will be a specialized enterprise that can create custom feed-skins. Just as we have today custom skins for instant messengers and browsers, so too will there be a day when we have custom skins for not only feeds but aggregators.

    Not all feed skins are alike. Some are designed to integrate with only the browser. Other skins can integrate with the aggregator.

    Publishers and content-searchers like feed-skins because they are interesting to look at.

    Content consumers, at the tail end of the pipeline, also like skins in their aggregator. They can customize a platform.


    Constraints on subscriptions


    The other reality of subscribing to feeds is that not all people are able to download the subscription mechanism. In other words, despite the name, the USM is not universal. It does not necessarily download behind a firewall; nor are local IT departments necessarily interested in http-tunneling and workarounds. The flat-out answer is ‘no downloads’.

    Thus, the workaround is to assign the subscriptions to the Amphetamine links. This gives users the option to subscribe to a feed through their chosen aggregator, without having to work with the FeedBurner skin.

    At the same time because I like the iPodder-feed-skin [browser friendly version], but it doesn’t have any buttons for text-aggregators, I’m in a quandary.

    How do I showcase my feed with the iPodder-skin, while still giving my readers the tools to download and subscribe to my feed without having to download the software for the USM?

    The answer is: Two links: The first link goes to the iPod-skin [which shows off the feed]; and the second link goes to the Amphetamene link that has a list of all the aggregators.

    At this juncture, one would think that there would be a way to combine both the fancy iPod-skin with the non-USM-subscription options, and at the same time give those who are behind a firewall a way to subscribe.

    It appears that using two-links is the only way to do this.

    So, there appears to be an area of potential enterprise: Create new skins for other feeds that are just as snazzy as the iPodder-browser-friendly skin; and at the same time develop a feed-skin that supports the text-aggregators; and at the same time ensure that these feed skins work with those subscribers who cannot download the USM.

    Consider more broadly who the non-XML-users are: They are approximately 95% of the population, according to the Pugh Center for Research. Most people who do not subscribe to feeds, and are not into XML generally use their internet connection from work; and these people generally are behind firewalls.

    Bluntly, it appears as though the way to tap into this non-XML community is to create some neat skins that invite them to subscribe, and at the same time make it easy for them to subscribe despite being behind a firewall.

    The solution, in my view, is not to create another subscription tool. But to advertise the existing links at Amphetamine, and then allow publishers a way to show off their feed to the new XML-users in a way that attracts their interest.

    Feed burner’s iPod-skin does this. And the Amphetamine-links do this. However, the two are not integrated.

    The iPod skin is designed for browsers. The Amphetamine links are designed for feeds. In the middle, are two sets of commands in FeedBurner. One is related to the browser-friendly skin, and the second set of commands is related to the feed-content length.

    Again, the purpose of this note is to explore the apparent firewall between the iPod browsers skin and the feed-support tools for aggregators.


    Apparent dual track development


    It appears as though the two feed-support options in FeedBurner are similarly not integrated. In other words, it appears as though there are two development channels at work here.

    On one hand, we have the iPod-skins for browsers, but these don’t integrate with the text-aggregators; and we also have the USM-development, but these are not supportable behind firewalls; and we have two options in FeedBurner on how to tailor both the browser and a feed, but these choices also do not integrate back and forth between the text-in-browser and feed-in-aggregator.

    Even though I choose in the browser-friendly-version to have both titles and full content, these choices do not integrate with the later choices in the summary burner. I can choose to limit the number of characters, but this choice only applies to the non-iPod skins.

    Specifically, it appears as though if I want to choose an option in the browser-friendly burner [and I want any content to show up] I have to choose full titles and full content. Based solely on the options, this appears to be the only way to get any content to show up.

    In the broad perspective, it appears as though there is some room for some cross-platform integration. I’m not suggesting that there be a new tool designed.

    I am suggesting that there is an opportunity for designers to create feed-friendly-skins; and at the same time develop some skins that support both iPods and text; and that the constraints-parameters in FeedBurner should also be integrated so that [a] browser-friendly options integrate with [b] the options related to content length in the feeds and aggregator.


    Publisher interest in limiting feed content length


    At the same time, if we consider the notion of feeds, one goal of FeedBurner is to monitor the number of readers for the feed. If publishers limit the length of their content to something less than the full content, it is more likely that an interested reader will click on the feed-link, and the publisher will know who is using that content.

    So, when I choose in the browser-friendly option the following: Full title and full content [with the hopes that the content be truncated by the later constraints in the summary feed, to only five [5, not 50] characters], then I as the publisher hope to do a couple of things:


  • A. Limit the length of the content in my feed
  • B. Rely on the FeedBurner to show full titles, and full content, and then have that content length constrained by the number of characters in the summary feed to only 5 characters.


  • But that’s not what is happening. I choose full content and titles in browser-friendly-option; and then below I limit the number of characters to only 5 so that I can get my readers to click on the feed, and then I’ll know who is reading my content.

    Again, this is not what is happening.

    I’ve chosen full content and full titles in the browser-friendly-feed with the hopes that my content length in my feed will be limited to only 5 characters by the summary feed-options; and at the same time I’m using the iPodder skin to show off the feed to the potential new subscribe in the browser; and then relying on the Amphetamine link for the non-iPodders to subscribe to the text-feed.

    Oh, and here’s the surprise. Despite going out of my way to read the instructions, and carefully follow the detailed comments I get back: Guess what, I choose full content and full titles [in the iPod-skin]; and then choose 5 characters [in the summary feed]…but guess what happens?

    Despite those limitations in the summary feed to only 5 characters, I still get the full feed content showing up in my feed when it is displayed in the aggregator.

    Who cares? Well, one of the selling points of the ‘limit the characters in the content’ to the feed was that my readers would have to click on the site to see the rest, and this click through would get registered.

    However, if the full content is shown [despite my limiting it only to 5 characters], then there’s no reason for anyone to click the link, and no way for me to know [who is or is not] reading the full feed-contents.

    In other words, my effort to add an iPod-feed to a text-only subscription, and at the same time have a way for people behind a firewall to subscribe, gets thwarted:


  • My constraints as I intended to apply to the feed aren’t accepted;
  • The full feed shows up;
  • The constraint in option two [in re summary feed] doesn’t mesh with the only apparent options I have in the first choice [at the browser friendly feed].


  • This is what we know going into the discussion. Let’s review the comment from FeedBurner, from Matt Shobe:.


    FeedBurner Note


    Hey there, It sounds like we've created a bit of a usability monster. let me see if i [stet] can untangle this a bit.

    The two "commands," or Feed Services, you're referring to appear to be our Browser-Friendly and Summary Burner services.

    Browser-Friendly specifically affects the visual display of the feed in a browser (especially XSLT-capable browsers, such as Mozilla foundation products and IE 5.5 and later). Browser-Friendly changes the visual appearance of a feed (in web browsers only), but not its actual content; you can choose to have content item titles and bodies, titles only, or no content items at all appear when the feed is viewed in a browser. The underlying XML source code of the feed is unaffected in every case, so the display of content items in an RSS aggregator would be complete and unaffected.

    Summary Burner, meanwhile, truncates the actual body content of content items in the feed to the character length you specify when setting up that service. Its purpose is to allow you to create a "summary only" version of another full-content feed quickly. Feeds with Summary Burner applied do appear to be truncated in RSS aggregators.

    Both services work together without overlap or conflict.

    . . . break in FeedBurner comments . . .

    Response-COMMENT

    This is not correct. The two services do not work together, and there is a conflict. I’ve chosen full titles and content for my iPod feed; and I’ve limited my content in the summary feed to 5 characters.

    Small problem. The full feed shows up. That is a conflict. That is not working together.

    If there was no conflict, my decision to limit the number of characters in the feed that reports to the aggregator, would also apply to the iPod skin, even though one is for a browser and the other is for the aggregator.

    We don’t have that. Thus, although you are saying they are integrated and there is no conflict, there is, in factno cross over of data and user-options from the iPod-bowser-skin-feed to the feed-content length in the aggregator.

    . . . continuing with FeedBurner comments . . .

    Feedbuner

    If you apply both to a feed, the "Browser-Friendly" view of that feed when displayed in Mozilla or IE will reflect your chosen options; content items will display their titles and text content, titles only, or will not display at all.

    . . . break in FeedBurner comments . . .

    COMMENT

    This is where the divergence occurs. Notice FeedBurner is focusing on the browser. I’m looking at both the browser and the aggregator.

    I want to be concerned with the browser for my potential subscribers when they look at my iPod skin. I also want to be concerned with the aggregator so that my subscribers are going to my feed, but just enough so that I can monitor who is reading the detailed content.

    Again, I don’t care only about a browser. I also care about the aggregator. When I choose to see full titles and content in the first option [for the iPod skin], but limited to 5 characters for the summary feed], then I am hoping that the aggregator will limit the length of the feed. That way my readers who subscribe using the amphetamine link, will see just a summary of the feed in their aggregator, and click through to my full content so that I can track them with FeedBurner.

    That isn’t working. In my view, this is a conflict between the browser-friendly setting [full titles, and content] and the full feed settings [limited content]. What needs to happen is recognize that the publishers who are using browser-friendly-iPod-skins also want to have the ability to limit the number of words in the iPod-feed.

    Clearly, the problem is that iPod is for iPod [sound, and a browser feed]; while the text-related-options are aggregator-related decisions [for text, not sound in the aggregator].

    …continuing the FeedBurner comments….

    FeedBurner

    Meanwhile, in the _underlying feed XML source code_, Summary Burner will have shortened the text content of the body to the character length you have specified.

    . . . break in FeedBurner comments . . .

    Response- COMMENT

    I hear what you are saying. The source code gets shortened. If that is true, why is the full comment feed showing up in the aggregator?

    Answer: Despite choosing the summary feed to be only limited to 5 characters, this choice of number of characters in the summary feed [that relates to the aggregator] has no impact on the choice I have for the IPod skin [which is related to the browser]

    Question: How do I give my readers a taste of my text-comments using the IPOD skin selections?

    Answer: There needs to be away for the content-length numbers [selected in the summary feed] to also apply to the iPod-skin selections. Currently , this does not appear to be working.

    Despite what FeedBurner is saying about what should be happening, I’m not getting that.

    You say that when applying both to a feed, the “browser-friendly view” will be displayed. OK.

    A. I chose titles and text content in browser friendly, for the iPod skin in the browser.

    B. At the same time in Summary Burner, I chose 5 characters, for the feed appearance in the aggregator.

    If what FeedBurner is saying is true, that means that when I combine both options together, I should see the comment feed with detailed comments, and that content truncated to only 5 characters.

    Here’s the rub: I didn’t get that. I go the opposite. I got full content in the aggregator ~despite~ choosing/limiting the content in Summary Burner to only 5 characters.

    Based on what little I know, it looks like the Browser-friendly version and summary versions are doing exactly the opposite of what I want:

  • Content length

    I chose to limit the content to 5 characters; the feed that showed up in the aggregator showed the full content.

  • Feed appearance in aggregator not shortened

    I chose to have titles and full content in the browser friendly option, with the hopes that my second selection in the Summary Burner would integrate with the browser-friendly selection. Again, this did not appear to work. Rather, I got a feed-reported-to-the-aggregator that appeared to report full titles and content [as selected in the browser option], but not affected by the Summary Burner [full content, despite the goal of reducing the visible content to a fraction of the overall feed].

    If the summary burner-option-selection-choice did have any impact, then I should’ve gotten a feed that had full titles, and was truncated by the second-command in the summary burner. That did not appear to work.

    In my view, what should’ve happened was the following:

    When I chose in browser-friendly-option to have full content and titles, my choice about content should have integrated with the summary burner. Specifically, browser-friendly option of full content and title, should be truncated by the number of characters selected in the summary version options.

    Again, I got the full-feed-content in the aggregator. This is not what I want. Nor what I thought I told the summary feed.

    Thus, I conclude that the browser-friendly version of the feed appears to have greater weight and emphasis during the coding and display. Again, it looks as though what is happening is that because both options were independently developed along parallel development efforts, that there wasn’t a meshing back of the results after the deployment of the iPod skins.

    . . . continuing with the remarks from FeedBurner . . .

    FeedBurner

    For example, you would notice in a Browser-Friendly feed that has the "Don't List Items" setting applied that the original XML source still contains every feed item (they're not actually removed from the feed, just from its display in the browser via XSLT instructions).

    . . . break in FeedBurner comments . . .

    Response-COMMENT

    Excellent! Now you understand what I am saying. But let’s keep focused. I’m not talking about the number of items in the feed. I’m talking about the number of characters that appear in an individual feed-item.

    Let’s not confuse feed-length with comment-length. One applies to the number of items in a feed. That is not the same as the number of characters that appear in an individual item that appears in my aggregator.

    Let’s get back to the options in FeedBurner. Rather than choosing ‘don’t list items’ I chose to list both titles and full content, with the hopes that the summary-burner would truncate what appeared in the comment feed. I was hoping that the total number of characters that appeared in the given feed-spot-item in the aggregator would be a fraction of the total number in a given item in the original published feed.

    Again, this did not occur. Rather, despite choosing full title and content in the browser-friendly-feed, my content was not truncated by the summary-burner selections.

    Again, I’m not talking about the number of items in the feed; I’m talking about the number of characters in an individual feed-comment.

    Question: How do I get the iPod skin feed to show only a portion of the text-content? Answer: Nobody thought of this because the iPod skin was not designed for text, it was designed to display a short comment about the IPod feed.

    But that’s not what your users are doing.

    Your users are stuck with a Pod-skin [that they want to use], and they also have to link to a non-USM-link for their potential subscribers to use [who may be behind a firewall and can’t download the USM].

    Your users are actually doing this: They are using the IPod-skin and they want to also have the text content on the IPod skin limited to a defined number of words so that their text-readers have a reason to click into the content, and the publisher [me] will have a way to know which content is getting attention; and which content is getting ignored.

    This currently is not working. Why? Because the feed-content-length is in one set of instructions and it relates to an aggregator; while the iPod skin is a second set of commands and it relates to the appearance in the browser.

    Two commands. Two different functions. One for aggregators. Another for browsers.

    But your users want them to be mixed. So that they can use an iPod skin, and then have that iPod skin deliver the feed to the aggregator, and then have that reported feed truncated so that the readers will then go back to the original platform so that the publisher will know who is or is not reading a particular spot.

    . . . continuing with the FeedBurner comments . . .

    FEEDBURNER

    If that same feed also had Summary Burner applied to it, and the 'maxmimum [stet] content length' was set to 50 characters, only whole words that fit within the 50 character limit would appear in both the displayed feed and source code -- FeedBurner definitely shortens the items in its version of your original source feed.

    . . . break in FeedBurner comments . . .

    Response-Comment

    Indeed, you have well articulated the constraints that apply to the aggregator and the feed that appears in the aggregator.

    At the same time, what I would like is the option to apply these constraints in re content length of an individual feed-item to the iPodder skin that gets wrapped around my feed.

    To be blunt, you’re making my point: The number of characters can be limited to something less than the full length of that individual spot. But the goal here is not to simply apply that constraint to a text-based-feed. Rather, the goal is to apply these text-based-constraints-for-an-aggregator also to the iPod skin that integrates with the browser.

    If the iPod skin-feed that shows up in my aggregator was truly integrated, then what should be happening is that I would be able to define the number of characters that would appear in an individual spot for the aggregator, and have these constraints apply to the iPod skin.

    This not what is actually happening. What you say should be limited, is not getting limited. The feed-parameter related to the aggregator does not also apply to the feed-parameter of an iPod skin primarily designed for a browser.

    That is a sign of things not working together.

    In theory, if the ‘maximum content length’ was set to 5 [not 50, but 5] characters, then the number of whole words that fit into that length should be limited to just 5 characters or nothing.

    Again, I got the opposite.

  • Despite limiting the number of characters for the feed in the aggregator, I got the full content; and

  • Despite choosing only 5 characters in the ‘maximum content length’, I got the full content of the comment. So, it does not appear as though the browser-friendly-options and the summary-options are integrating.

    . . . FeedBurner continues . . .

    FEEDBURNER

    I hope this helps clarify the outcome a bit. Our upcoming revision to the FeedBurner user interface incorporates a considerable amount of user feedback and is intended to make much more apparent how applied services interact to transform a feed. Thanks for posting these detailed observations!

    . . . break in FeedBurner comments . . .

    COMMENT:

    Yes, you’ve clarified what should be happening. But my point is that despite your clear instructions on your platform, and your remarks above, what is happening is not matching what one would think is happening.

    When I go into browser-friendly-option and choose titles and full content for the browser-friendly-version [which I like to call a feed-skin], I am expecting that the two commands in both the browser-friendly-options and the summary-burner options to integrate.

    This does not occur. I can constrain the number of characters for a comment feed that appears in the aggregator; but this constraint does not appear to apply to the iPod skin.

    This makes sense. The iPod skin is designed for the browser. The second set of commands in the FeedBurner related to content appearing in the aggregator.

    But I want to do something else. I want to use the iPod skin to show off my feed; and then have the content-constraints [that were designed for an aggregator-text-feed] also to apply to the iPod skin that was designed for a browser.

    I want to use the iPod skin designed for sound to also support text-based-feeds in that when I input constraints to FeedBurner in re content-length in the aggregator, then FeedBurner should also apply those constraints to the iPod skin.

    What I am looking for

    You have explained the terminology well. I understand what should be happening You are very clear on that. I am not clear that what I have said [that the two options do not appear to be correctly integrating] is getting through.

    All I need to read from you is, ‘yes, we understand what should be happening; we hoped to design the system so that the summary burner and the browser-friendly burner’ are integrated.

    ‘Yes, we understand that the two commands should be reasonably integrated, but they are not.

    ‘Yes, we understand that you followed the directions, and chose full content and tiles [in the browser friendly version], with the expectation that the content of the feed be truncated by the summary burner [to only 5 characters, not 50, but 5, as in five]…but in a practice…the actual content of the feed was not truncated, as directed by the summary burner.

    ‘Yes, we understand that the two functions should be working together; and that the browser-friendly-options should be integrating with the selections in the summary feed. A reasonable person might conclude that the number of characters chosen in summary feed would affect the view in the browser-friendly-version.’

    ‘Yes, we understand that the reasonable person could attempt to have chosen both a browser-friendly version [ to display the nice feed-skin], and at the same time directed their subscribers to subscribe to a feed URL at Amphetamine, making the issue of what was actually on the iPodder skin irrelevant to what was appearing in the aggregator.”

    iPod skins and subscriptions without USM

    Here’s the deal. I like the iPodder feed-skin. At the same time I also like the fact that I can [or should be able to] modify my summary feed to a number of characters.

    Because I want to use both the summary feed constraints [limiting the number of characters to 5], I thought that I could choose both the browser-friendly-option [iPod skin] to showcase the feed; and then use the amphetamine-link for my readers to actually subscribe.

    When the iPodder-skin first came out, there was some discussion about subscribing to the feeds. In my view, the nice choice was that I could showcase my feed with an iPodder skin; and at the same time, although there remains no way to subscribe to the feed in a non-iPodding platform, I could always use the amphetamine links as a subscription link.

    The solution is twofold: How to showcase my feed using the IPodder-skin; and at the same time use the amphetamine-link for the actual subscriptions.

    I’d like to be able to use both the iPodder feed-skin [browser friendly version] even though there is no link on that to any XML-aggregators for non-iPods [like bloglines]. My goal is to showcase my feed with the iPodder skin; and then use the amphetamine link for the actual subscriptions so that the readers can link to their text-aggregators.

    Why would someone want to use the amphetamine link for a subscription? Well, surprise! Many people who are non-RSS users are behind firewalls. It makes no sense to have a download requirement under the subscription mechanism when my new subscribers are behind a firewall.

    At the same time, I’d like to have a simple subscription-mechanism using a link. So, I’m forced to choose to work with what I have: Showcase the feed with the iPod-skin [browser friendly version that has only iPod links, which I don’t’ want]; then link the actual subscription to the Amphetamene links.

    I was assuming that many people were relying on both IPod-skins and the non-USM-subscription; meaning: That most people would already know that there had to be a relationship-linkage between the feed-skin [for iPodders, browser friendly], and the summary feed [which integrates with the selections related to content].

    In my view, because the feed-skin does not link directly to a text-reader aggregator, that would mean that people would know to use two options: One option being the IPodder-friendly-feed [iPod-skin, browser friendly feed], and at the same time link to the USM.

    In other words, I was assuming that because people were using an IPod skin with a non-USM subscription link, that there would also be a parallel relationship between the browser-friendly-options and the summary feed options about content.

    Clearly, I am not correct.

    Here is what I would like:

  • There be the option to have more skins like the iPodder skin
  • The ability to have a subscription mechanism that currently exists with Amphetamine
  • The ability to subscribe to a feed with any of the feed-skins
  • The ability to input my feed-commands in the browser friendly feed [for the IPod=skin] and have those constraints integrate-synchronize-work with the constraints I assign to the summary feed [in re the number of characters].

    At this juncture, I’m not clear that I can rely on the ‘number of characters in the summary feed’ as a way to limit the number of characters that actually shows up in the aggregator.


    Conclusions


  • 1. The iPod skins are not compatible with text-limiting constraints. iPod-skins were designed to appear in the browser. The constraints applying to feed-appearance-in-the-aggregator are not currently also applied to the iPod skin, which is currently simply just a browser-based tool for non-text feeds. The only text that is constrained is in the comment for the iPod feed; but this comment is not affected by the constraints affecting the length of the text-feed in the aggregator.

  • 2. The subscription tools have diverged: One supporting iPods and another support Text.

    To subscribe to a text-feed we can use either a direct subscription tool like Amphetamine, a button tool like Newsgator, or the USM. USM is not an option for those behind a firewall.

    At the same time publishers who want to showcase their feed with an iPod skin are not able to limit the length of the text appearing in the aggregator. By choosing to have the full title and content appear in the browse overrides the publishers’ choice to have that content also limited in the aggregator.

  • 3. The subscription options have also diverged: One set supports text-based feeds, and another set affects pod-skins.

    Right now publishers have to make a choice that they do not want to make:

  • showcase their content with the iPod skin,
  • limit the length of their content for purposes of tracking content-popularity; or
  • providing tools to support users unable to use USM.

  • 4. The subscription tools do not integrate: Users who cannot work with USM because they are behind a firewall, are similarly limited in their ability to use a flashy skin in conjunction with a text-based feed

    Ideally, the publisher should be able to enter a single command on content length that equally applies to both the aggregator and browser displays for any feed, regardless whether that subscription tools and content appears in the aggregator or the browser.

  • 5. Aggregators will display a full text-feed for the iPod-skin, even when users have chosen to limit the number of characters in the text-based feed

    If users choose to limit the length of a text-comment-feed in their aggregator, they have to use the non-iPod skin.

  • 6. Users are not distinguishing between Pod-skins and text based feeds

    Users would like to have the option to have text-based-constraints intended for aggregators to also apply to constraints on the iPodder skin. Users would also like the option to use the iPod skin, even though they are not issuing an audio-feed. iPod does have a text reader.

    Text-publishers would like to be able to limit the total number of characters in the FeedBurner feed so that iPod-users who read the text-feed have an incentive to read the full feed; and at the same time the iPodders who are using this text-reader in their iPod only get a snippet of the entire feed.

    Think of the iPod skin as something that text-publishers can use to attract iPod-text-readers to text content. Think of aggregator-content-constraints as something that publishers would like to also apply to the text-comments in the iPod skin so that readers reading text in their iPod get a fraction of the total feed-comment.

    This will save the iPodders from getting jammed with full-feeds; and at the same time, ensure that the iPodders-reading-text can still get access to the full text if they want to read more; and publishers will know whether the content there are providing on this iPod skin is getting read or not.

  • 7. Users want tools that let them make text-related constraints to feed choices that are focused on iPod feeds

  • 8. iPod skin feeds are not effectively integrated with the text-based constraints

    Publishers would like the constraints that apply to text-feeds-in-aggregators to also apply to the iPod skin that was originally designed for just browsers. Content publishers would like the ability to seamlessly have their text-length-constraints that apply to feeds-in-aggregators to also apply to those fancy iPod skins, regardless the original intent to only use the skin in a browser.

  • 9. Text based constraints in browsers are not the same as text based constraints for aggregators

    When we talk about constraints in the FeedBurner, there are two tracks. One applies to the browser-based-iPod skin; and a second track applies to the feed-content-appearing in the browsers. Currently, publishers who want to limit the number of characters appearing in the aggregator and apply this constraint to the iPod skin are not able to do so.

  • 10. Aggregator-friendly, browser-friendly, and publisher-friendly skins are not one in the same

    Publishers would like to have a single set of commands that seamlessly get applied to all feed-skins regardless whether those skins are primarily designed for aggregators, browsers, or some other display option. Publishers would like the option to have their feed showcased using a custom-skin. Currently, the only fancy skin is the iPod skin. However, this skin is designed for browsers. It was not designed to support the objective of limiting the number of words in an aggregator.

    If publishers want to limit the number of words that appear in an individual feed-spot that is then showcased in the aggregator, publishers currently have to make a choice: Do they go with the plain vanilla skin, or the fancy one.

    Either way, neither option supports those subscribers who are unable to download the USM because they are behind a firewall. Thus, for publishers to showcase their feed to new subscribers, publishers are currently asked to choose between a skin that doesn’t integrate with text; or a skin that only works with USM.

    I have chosen a middle ground. To use the Amphetamine subscription link, and then also showcase my feed with the iPod skin. By making that choice, I have chosen to let the entire feed-content appear, thereby defeating the objective of having a content-summary and tracking the total number of subscribers linking on a particular feed-spot.


    Current User Constraints that could be Eliminated


    FeedBurner has some nice iPod skins. The users are using these to show case non-IPOD feeds. Users who are behind a firewall are also stuck with a subscription tool that cannot be downloaded. Users, in order to support those subscribers who cannot use USM, are forced to use the Amphetamine links or something else.

    In order to show off their feed, some users may choose to showcase their feed with the IPOD-skin [browser friendly], while at the same time linking their potential subscribers to the Amphetamine links.

    In order to user the iPod skins, and still support users who have no way to download USM, the publisher has to use two feed settings: One with the iPod-skin [browser friendly option], and then give a link to the subscribers to amphetamine.

    If users are using text-based feeds with the iPod skin, then they cannot rely on the FeedBurner’s summary feed option to limit the number of words on the content. If users want to use the IPOD skin for a text-feed, the options in the second-set-of-options [summary feed] that limit the number of characters, will not work.

    In practice, the full feed gets shown in the aggregator. Whether or not the feed gets shown in the browser is not relevant to those who are viewing the actual subscription content in their aggregator.

    Publishers want to make sure their content is displaying properly so that their readers are clicking through to the detailed content. The goal of the publisher is to limit the number of characters in the feed so that the interested reader will click through and register a hit, that way the publisher is able to determine which content is getting looked at, and which content is getting a pass.

    Publishers also want to make their feeds visually more attractive. One option is to use the iPodder skin. However, this is designed for a browser; and the constraints in the summary feed will not affect the iPodder skin, and do nothing about limiting the feed appearance in the aggregator.

    Rather, the constraints in the summary feed [when one is using the iPodder skin] only are designed to work with text-based feeds. If users want to constraint the number of words in a feed that report to the aggregator, the summary feed option related to characters does not support these choices.

    Rather, the user has to currently make a choice: Do they want to

  • A. Have an iPod-skin to show off their feed, and give up their ability to limit the number of words in the feed that reports to the aggregator; or
  • B. Do they want to forego the flashy iPod skin, in the hopes of limiting the number of characters in the feed as it appears in the aggregator.


  • Because both options do not work, there is not merit to say that both services are fully integrated. If they were integrated, users would be able to adjust the number of characters in the summary feed, and have these options affect the iPod-skin as the text reports in both the browser and aggregator.

    Currently, the constraints are focused on only the existing channel: iPod skins as they appear in the browser; or text-based feeds as they appear in the aggregator.

    FeedBurner does not currently support the following third mix: iPod skin reporting limited text in an aggregator

    At this juncture the iPod feeds are not integrating with the constraints related to content-text-feeds in re aggregators.


    User tips: Workarounds have failed


    If someone wants to limit the number of words in an iPodder skin, so that the total content in their feed as reported in the aggregator is small so as to attract the reader to click on the link, the current FeedBurner options do not support this.

    Translation: A publisher can showcase their feed in the browser using the IPOD-skin; but their goal is to have the content-length truncated by the second set of options in the summary feed, and have those options apply to the feed displayed in the aggregator.

    If you want to show off your feed and want to support readers who cannot download USM, and still track the number of readers who are clicking through to your content, you may have to wait. FeedBurner currently will give you the option to subscribe to a feed, but the feed-length-options are not integrating with the feed-skin options.

    If you want to track your subscribers and clickthroughs by limiting content to a small fraction of your feed, you cannot use the Podcasting skin. If you choose the iPod skin, something in the FeedBurner platform overrides your choices in the summary feed, and even if you pick 20 characters, the FeedBurner will still show the entire feed content in your aggregator.

    However, this is not a nice thing. For those publishers who know their potential pool of subscribers is not interested in code, these new subscribers are more likely to be interested in a feed if it has flashy feed skins. But it is unfortunate that despite a flashy feed skin, I cannot also click on another option in the summary feed that will limit the number of words displayed in the iPod-compatible feed.


    Users would like to be able to, among other things:


  • Input the content-length they want to see in their comment-feeds, and have those constraints apply to any skin.

  • Input constraints that apply to content in the aggregator-feed, and have those constraints apply to the iPod skin, even when the publishers is not using audio, but only a text-based feed.

  • Input a single set of characters and constraints into a single panel. FeedBurner would then appropriately apply the constraints to both the browser-skin-text and the aggregator-content;

  • Use the iPod-skin for a text-feed;

  • Have the option to use other colorful feed-skins;

  • Load and subscribe to feeds even if they are behind a firewall;

  • Use workarounds and backups in cases where FeedBurner' subscription skins are not working;

  • Apply a single-click subscription to link from a colorful skin designed for browsers and also use that platform to showcase feeds that may or may not be related to text, audio, or visual; and

  • Use other skins to support and can be tailored to user specifications to a variety of medium, not limited to text or audio, but also visual-feeds that we may get in Flicker.


  • Next Steps

    It remains to be seen whether FeedBurner adopts these changes, other enterprises emerge to provide these services, or whether there is a combination of the two.

    " />