<AttributeStatement>
<Attribute Name="urn:blood:type">
<AttributeValue>B-</AttributeValue>
</Attribute>
</AttributeStatement>
Interesting post on the lack of consistency amongst blogs on how RSS feeds are made available for subscription.
Syndication feeds have become a predictable blog feature. But finding them on a site can be a bit unpredictable
When you need to make it easy for users to find something on a page, you either stanardize where you put it and what you name it so that the users can manually 'discover' it, or you define mechanisms by which it can be auto-discovered.
The post concentrates on recommendations for the first model, i.e. where in the page to put the link to the feed, what colour the button should be, how to deal with variants, etc.
Such best practices would undeniably be useful, I've spent minutes scanning through a page or using the browser 'Search in Page' to try to find a feed link. Nevertheless, UI standards are not the only way - the burden of feed URL discovery can be removed from the user and be semi-automated on their behalf.
It's in the comments to the above post that the possibility of this automated alternative is mentioned. Don't force users to find the feed links, instead enable the browser to find them by embedding suitable code in the page. Once found, the browser can present them to the user if and when asked.
For instance, in Firefox's "Live Bookmarks" feature, when the browser comes across the following in the page HTML
<link rel="alternate" type="application/rss+xml" title="John Bokma RSS" href="/index.rss">This link is interpreted as a feed URL. The availbility of the feed is presented to the user as an icon in the address bar
Ultimately, a blog's best bet is probably to use both models for feed URL discovery, allowing users to search on their own through consistent placement of a link as well as taking advantage of automated mechanisms.
Likewise for identity discovery perhaps? Allow for both models?
Different identity systems assume differing levels of involvement from their users for the discovery of their identity attributes. Some systems presume that the user will play an active role, manually providing the address of their identity provider when asked, others place greater emphasis on automated mechanisms to match a requesting party to an appropriate identity provider, and others allowing for both options.
There will always be some users who know where every bit of their identity is distributed at any one moment, others for whom the prompt "Please indicate your Wallet Provider" would have them running to their kids for help.
Relying parties requesting identity information would receive back a standard response indicating the IRA associated with that identity data. Proceeding with the transaction would be interpreted as agreeing to abide by the IRA requirement.
This model distinguishes 3D Boxes from, oh lets see, no other social applications. You provide your friend's email, they get invited to create an account, their new account is given whatever rights you assigned them etc. Viral indeed.
Central to 30 Boxes is the concept of buddies. Basically in order to add someone as a buddy on 30 Boxes all you need to do is enter in their email address (talk about genius viral marketing). They then are sent an email inviting them to 30 Boxes and if you choose you can allow them to see your calendar, see only events tagged a certain way in your calendar (cool, tagging in a calendar app), or see none of your calendar.
