Check it out here

This entry was prompted by Tim Bray and Dare and the discussion on comment updates.

Now I absolutely hate it when entries appear in my reader as updated when comments are added to them! Even with "Ignore Updates" in bloglines, I still get some showing. I don't have a problem with atom:updated etc, so long as it's not used to push comment additions as updates. Comments should be opt-in. I subscribe to specific authors with my reader, not every joe commenter.

Anyway, should a user opt-in to comments on an entry, here's how I'd like to see that happen:

Opting-in to comment updates opts-in for that entries updates if they've been set to ignore updates for that feed as default. This is because some people comment inside they're own entries and so the reader knows what comments are referring to. While I'm at it, entry updates should have the option to be highlighted in some way in readers so users can quickly distinguish changes.

Now, anytime a new comment comes in, a users reader would then display the entry with; changes highlighted, the number of comments listed, and how many new entries there are in that comment feed. Using the Atom Threading Extension to achieve all this, entries in the reader display something like this:

My Entry Title

My firstsecond entry content.

2 Comments (+Expand) | 1 New (+Expand) | Subscribe(d) to Comments

Entry Comments:

1. ( ) Julie
   Woot, I popped your comment cherry!
2. ( ) Joe
   Number 2 - this comment is new.

Select ( ): All, New
Mark these comments as: Ignore, Spam

Add Comment

• Clicking the total comment number jumps to the actual blog entry at the start of the comments.
• Clicking "1 New" jumps to the beginning of the new comment on the actual blog entry.
• Clicking Subscribe alerts a users reader to display this entry as updated when new comments come in or changes happen on the entry.
• Clicking (+expand) on total comments expands all comments in the area below the entry in the users reader. New comments are highlighted. After expanding, clicking on "1 New" could serve a dual purpose and take you to that new comment in your reader.
• Additionally/Alternatively clicking (+Expand) after the "1 New" only expands those new comment entries, not existing ones. The news reader could then have default settings for displaying results users subscribe to, only displaying those new comments beneath the entry by default.
• Users could opt to filter out specific users in comment updates. Don't like a commenter? Filter them by name and address(if they're consistant) on a per entry/per feed basis or globally using a drop down. Add "Report as Spam" and checkboxes next to items. Think "Askimet" for in reader comments. Nearly every comment feed I subscribe to has spam in it at the moment. I need a spam filter on top of their spam filters…
  I can see this same spam or splog marking happening for tag aggregators like technorati in the future.
• Last of all an "Add Comment" link or text area could then go after the comments to enter them at the site or in the reader.

The beauty of all this to me is that would allow reading and commenting inside of mobile devices easily all from the one interface. I don't know if there are any readers out there as of yet that will let me expand and read comments in my reader and optionally choose to subscribe to updates of those, but thats what I want. The Atom threading extension comes to mind to enable all of this.

While I'm on updated entries, another pet peeve of mine is occasionally when I also get updated entries appearing multiple times in my reader. Doc Searls (radio userland) feeds annoys the hell out of me for that reason the way bloglines handles it. Updates seem to be given new unique ID's and I get repeat but slightly varying updated entries one after the other. That totally bites. End whinge.

Tim talk's where the action is at!

Atom (APP)
Dynamic Scripting Languages (Python's my favorite)
Concurrency (Whee Twistedmatrix)
Stevey talks up Javascript and Rails

I like his points about JSON. Makes me think about YAML and the recent talk of the Semantic Web failures. I keep thinking of a not-well-thought-out queriable JSON datastore.

Rails may well be all that, but it ain't it all. Personally the Ruby syntax sucks enough for me to avoid it until I have to use it. Performance and libraries feel lacking.

Thinking out loud.

JSON > Content Repository > JSON > Client

SQL > Content Repository > JSON > Client

XML > Content Repository > JSON > Client

Binary > Content Repository > Client

XMPP > Content Repository > XMPP > Client

XMPP > Content Repository > Bayuex > Client

Increasingly I find myself discussing the future of where decentralised technologies are headed. Increasingly I find myself discussing User Experience - my loathe for it with many of the current technologies.

With layer upon layer being added to the technology front, and tools such as those for rapid development taking steps to easing the burden on web developers, user experience is emerging as increasingly important to me.

Applications and user interfaces are becoming increasingly complex, cramming feature after feature into smaller spaces, and now with mobile techology really taking flight, increasingly I see the need for seamless user experience development environments.

Creating a seamless layer between application developer and application designer will become evermore imporant.

I've been reading a lot about REST lately, REST being at the heart of how I see decentralised systems evolving. The first step in the process towards what Rohit Khare calls AR+REST+ED Development(PDF). Asychronous, Routed, Representational State Transfer, Estimated, Distribution. I can't help but mention the WAKA protocol Roy T. Fielding has published some thoughts on here. What a cool name for a protocol.

What has occurred to me is the connector based approach of such a system. As standards emerge and are pushed, asychronous technologies such as the Bayuex Protocol and Comet for ajax, XMPP for messaging. JCR170 & JCR283 for Content Repositories, XML, RDF, Atom and many others. It has occured to me how much of a pivotal role user interfaces will have in tieing all of these technologies together in a manner that becomes a seamless experience for application designers in rapid appication environments. The technolgy is increasingly becoming transparent, accessed through universal connectors allowing increased productivity and creativity, its the interfaces that can take these to the next level.
This for me is the future of the internet. Creating seamless User Experiences in aide of augmenting humans. A lot of pioneering work in the area being done by Doug Englebart. The mother of all demo's a must see. As is Hyperscope.

It's creating that layer of seperation that has me excited as to where things are headed for ease of use and wide-spread adoption of technologies that allow users to communicate their ideas with like-minded others effectively. Creating connections and meaning in the process.

An area I'm been working on recently has to do with storing my own personal attention data in a way that affords me ease of management through a centralised event history.

It works in a way that is much like Dave Winers concept of a river of news. The newest events appearing at the top of the list, an area I like to call "the event horizon." Recently I read Dave's interpretation on Mobile Rivers and it had me thinking. Thinking; "thats only partly how I want to do things."

Here's an excerpt from his example:

How mobile Rivers work

A scenario
Here's a scenario. Taking a trip. The plane lands, out comes the Blackberry. Check the voicemail, check email, then… What's next? For me it would be to check the news, find out if anything happened while I was in the air. Did a scandal break? Another terrorist attack? Any interesting Apple rumors?

Not how I want to do things because if infers seperation between my attention data (phone, email, news) and their alert interfaces. I want them all in one interface. Increasingly I've begun to curse my email reader, news reader, and other seperation. The sheer volume of information to wade through is becoming unmanagable. What with the 10's of mailing lists I'm now subscribed to in addition to the feeds I read in my news reader - jogging back and forth between email, mailing lists, news, SMS, missed calls is becoming a pain to manage. I want it all in one. The problem is how to manage it together.

Increasingly I find myself gravitating to my feed reader in a river of news fashion for consuming as much of my attention data as I can. This has me thinking about the interface a lot and what I really need in there. What information is important to me and how best to present it.

The more I think about the idea of an Event Horizon extending my news reader, the more I like it.

Here's how it works.

All of a users attention data is aggregated into a single event history feed. Recent email, news feeds, missed phone calls, identity requests for link contracts, calender appointments, todo events, bill payment alerts. All in a river of news format. Newest events at the top of the list in the event horizon.

Events could be made sticky by type based on filters, additionally event types could be filtered by type through tags. eg. only listing recent email. With personal meme engines (like Sam Rubys) integrated as types of data streams and given event horizon priority aswell. Not to mention other statistical information aggregation based upon ones personal attention data should the user want that.

I see something like this integrating as a central point with a users identity broker. A users event horizon stickying recent requests for identity link contracts. An interface for sharing certain private data using Identity Rights Agreements.

The beauty for me with this system is that users could access their news reader, emails, missed calls, identity information all through the one prioritised river of news or the filters. All on a mobile device if they so choose to.

Want to approve a purchase and trust your credit card to someone whether it be a retailer or online service? Simply tell them your digital identity, an example being an i-name;

=firstname.lastname

(if only XRI would have native browser support soon

Their identity broker then sends your identity broker a payment details request that appears in your event horizon allowing you to use either your mobile device or a terminal to approve/disprove your credit card details transaction. Creating a link contract in the process based upon an Identity Rights Agreement

Perhaps using your thumbprint on a device that your identity broker has approved for thumbprint authentication.
By clicking on differnet types of requests in your aggregator, you could be either diverted to the appropriate client for that type of event, whether that be your email client, news reader, calender or Identity Rights Agreement broker. Personally I'd like them all integrated in an Ajax style interface manner whereby I click reply to reply there and then in my river of news to an email thats just come in, or an SMS that has. Or to expand to read comments on a post and reply. I'd like to see the latter done using something like Atom's Threading Extension and the Atom Publishing Protocol to post those comments.

This all requires a way to send XML data securely across networks. On that topic, Jason Kolb has been discussing his future of the internet, a discussion I have been following with interest. He has the idea of using XMPP as the messaging protocol between identity servers. It will be interesting seeing how this can be done securely. i-names, XDI is doing something silimar as I understand it, and something I'd like to understand better.

When it comes to security, I can't help but think that data-mining will surely play a role here.

In conclusion, I want one interface for events, an interface to action those events important to me.

The Event Horizon.

Jeff Croft writes about whether CSS belongs in RSS feeds.

I just went round-and-round with Brian Livingston, an editor at WindowsSecrets.com, about his article entitled CSS Support is Poor in RSS Feed Readers. Brian believes that we web producers should be using CSS in our RSS feeds to make our content more readable — he talks about colors, typefaces, sizes, etc.

Interesting discussion. While I'd rather CSS and feed content were kept seperate, issues like Jason raises in embedding objects, in his case microformats into posts and feeds that he later parses and displays using javascript, has me questioning this logic. While I'm sure there are ways around issues like his example raises, like external sytlesheets(where supported ahem), etc. I still see that inevitably some users and developers will want to be able to do more and interact and share more than just static content in feeds, and to do that options need to be there to carry this out.

You only need to look at any systems where there have been mass amateur uptake of them to see of potential benefits to allowing the free-for-all. People are attracted to glitz and glam. The more people, the more innovation and resulting technology exposure allowing it to flourish, and who knows what that may bring us next. (see this interesting videocast of Ben Hammersley for more)

For me a feed is all about sharing <em>information</em>. It shouldn't matter what that information is. Apart from security issues with certain style attributes, I don't see a problem including CSS inside it so long as it's function is defined and preferably not as styling. I believe in external styling wherever possible, that way the end user can then being presented with the option to use that styling or not. However styling critical to function as in many AJAX apps are now using, seems reasonable to include. Though ideally it too should be referenced externally should it be deemed dynamic. Often however it seems pointless to do so with such settings vital to operation that are unlikely to change over time. eg. display:none; on Jason's example. The problem as I see it, is there is no standard that I know of tells parsers what external CSS may be vital for functioning. Maybe we need standards of "safe" styling?

Saying all that and wanting to allow freedoms, the last thing I want my feed reader preventing me doing is reading because of some designers like for flashing objects and other heinous crimes. But then I'd probably just unsubscribe from those feeds…
I'm sure there are ways in which the best of both worlds can be accomodated. Seems to me counter-productive to just just say flatly that; no CSS shouldn't be in feed content.

As an aside, there's been an interesting discusson at Clinton DeWitt's blog thats worth reading in regards to RSS and ATOM placing interesting items in feeds.