Niall Kennedy has a post[1] on browser history visited link sniffing. By injecting popular links using JavaScript and checking css :visited, he’s able to track where people have been and customize the user experience to suit. It has privacy implications, I can see this being used to build up user profiles without consent and target all sorts of things like phishing and advertising. Having an opt-in system in place to provide this kind of data for sites to use, on a per site basis, could be an interesting use of this data though. If users could be presented with an opt-in option on sites to use this and store this information, it could be useful and possibly bypass privacy concerns, without the need to install anything. Doing so, user profiles could be built up over time, through data-mining those popular links and content then targeted at those users. It does however require data mining potentially popular links in the first place, but should you find a history match, crawling that site for more links and then matching those to users browser history could create a nice usage pattern to mine useful context from.

Apparently this is an old issue, going back to at least 2001. I worry that in all that time XMLHttpRequests will (and are) being used without consent to brute force test a users browser history for visited links, done so while hiding the bandwidth used as a movie or flash is played, etc.

Might be time to start clearing your browsers history, or getting this Firefox plugin[2] if your worried.

[1] http://www.niallkennedy.com/blog/2008/02/browser-history-sniff.html
[2] http://www.safehistory.com/

"Take It With You" Wiki

Although this blog has been silent for a while, I haven't been idle. I was working on AJAX-based web application with transparent support for disconnected operations.

TiwyWiki is a prototype wiki that runs both online and offline without any install (besides Flash Player).

 Awesome!

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.

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.

I've been following Cameron Reilly's progress with ThePodcastNetwork for a while now. Listening to his current woes, hoping things pick up soon for him. His request for ideas had me thinking and I've decided to pitch some of my ideas in. Feel free to steal them, I have much bigger ones in the works. Anyway here are my suggestions and thought I'd publish them for all to see and debate.

I'll start by outlining the podcast hosting (or video log for that matter) business model as I see it. Advertising. With more and more services like Amazon's S3 our likely future, I see the bottom eventually falling out of mere hosting unless you make the hardware or maintain it. Still you can cream a little off the top using it if you like, but for me the future is all advertising and subscriptions with hosting a side dish unless your a data centre.

Now Cameron more than anyone knows that advertising for his medium will most likely come through embedded sponsorship in podcasts as well as targeted on his site. Thus the more listeners and distribution, the better exposure for all involved. In my mind therefore building brand reputation while building distribution channels are the key to this medium. So, first we build on those. I use Cameron's business as my case study here. So here are my suggestions:

1. Build a better distribution model.

Make it easy for anyone to access and share your data.

The first and easiest thing Cameron could do is make each and every podcast easily sharable on anyone's site with a custom and branded flash player(with fallback) they can drop in, ala Youtube.

Optionally, a player, that on mouse hover or excerpt button click, displays either a text excerpt or transcript of the cast. (I've heard anecdotal evidence that transcripts next to casts improve listens by up to 225%.) Note: I'd do it with display:none javascript, not ajax to help the search engines find it. Let's hope RSS readers of the future support display:none or some other safe means of embedding metadata, aye. (Comments on alternative methods welcome)

So for easy copying and pasting I see the implemenation best done through and interface something like Live Clipboard's.

Thus we display Live Clipboard scissors on objects considered sharable. With our podcast example, on hovering those scissors would display your options for that content. In this case clicking Copy simply copies a piece of HTML to the users clipboard containing an object element marked up. ie. the podcast player <object> with podcast uri and description.

Note: This example doesn't utilise the 'Live' of Live Clipboard, but you get the idea. BTW, to anyone looking to implement Live Clipboard, please, on selecting a method of an object the user should be presented with something like a tooltip instructing them what has just happened! eg. "Success! HTML Object copied to your operating system clipboard. Now, go paste it somewhere!" or "Success! Live Clipboard XML Object copied to your operating system clipboard. Perhaps on hovering objects the type of content to be copied is displayed. eg. replace Copy (CTRL-C) in the figure above with Copy HTML Object (CTRL-C) or Copy Live Clipboard Object (CTRL-C)

Now, back to distributing our podcasts.

I'd also suggest branded widgets of feeds copied and pasted in similar fashion.

Taking this further an open API service for database access to casts and their metadata as well as data processing services. This however requires infrastructure and one central content management and hosting system. So build one(if and when you can afford to!). And Cameron, I know I'd have a 2web widget on my blog if you had one.

Next for distribution, another interesting path I see this model taking is with distributed metadata creation services. Check out what the blip.tv guys are working on with mirrorplay (not up yet) and read about video vertigo (user and password are in the popup authentication) and where metadata sharing for distributed media is headed.

There's an opportunity here for someone to build an open API that lets developers build podcasting software into their own, have those podcasts hosted on the API providers servers and allow collaboration with advertisers through it. Or just a service that streams the process of adding ads to the media and then to the clients servers. It's complicated to explain but if your interested, have a look at the eventful aka EVDB model. I think it's kinda similar but in their case used for events and I hear purchasing tickets.

And BTW, while your at it creating widgets, don't forget to add digg and delicious buttons to each! And comments… You could even include an area in the widget for displaying tags and tagging that very podcast using AJAX! No need then for mirrorplay? Maybe. Maybe not. Something worth considering is that not everyone lets you embed scripts… alternative: flash… *grumble*

Additionally you should write or purchase rights or licensing to podcast aggregating software for downloading content locally and consumuing it and feeding the playlist back to your database. Don't forget to brand it all.

Don't forget to bundle your service with other hardware. Mobile devices especially are the media players of the future.

2. Build a solid brand image.

Produce quality content under your logo stamp. Seek out existing podcasters(or vloggers, whatever floats your boat) with a proven track record and bring em aboard your stamp. Podtech did this with Scoble, Scoble did this with GETV…

Make podcasts about the people. Interviews, exclusives… I love those. Encourage that in your producers. Everyone loves to hear from experts in their field. Experts market themselves, experts therefore market you if you can get em.

3. Design and marketing.

Now I'm basing this off Camerons site and his homepage is a little bland. Get a good designer Cam, make it fun and build upon the brand in the design. In Camerons case, get rid of the whitespace at the top and make the TPN logo stand out. Add some mr.sheen polish to it and develop a 'look & feel' synonymous with TPN. Make play buttons using the logo to use there and in widgets? Something with personality…

Add a "featured show(s)" section with clips and play buttons. Add a short playable promo clip for all the shows and latest shows on there so people can get a feel for the hosts quickly. We're all time poor so please don't make me listen through ads or fancy long intros on those promo clips. Make the search feature and categories more visible. Make the site fun and idiot proof.

Maybe add sound effects on hovering items. Make promo's automatically play on hovering… Grab people's attention. Just never play music on page loading! That's a heinous usability crime! I curse you myspace.

Also add features that will entice people back. Let people tag and mark casts as favorites for later referral. Capture that attention data on what each user plays/tags/does on your site. Create a social network of tags and "who tags like me", "who likes listening to what I do" network ala last.fm. Create widgets of this data for the users. Use the data to recommend other items, including advertising. Create widgets for those.
Ultimately, you'll be reaching your users through distribution channels. Get that right. Make it so that people can easily find your content on your site to help it go viral. Add feeds and widgets on everything. Even categories, peoples listening lists, top downloaded… basic SEO.
4. Education

Drive traffic through education. Create a podcasting tutorial blog(and cast) to educate people. Let the TPN producer crew write it, everyone has a howto podcast story right? Call it the Digital Podcasting School ala Darren Rowse and his Digital Photography School.

5. Advertising

First, create some. Your own! Build a service that can attach advertising automatically to media. Create your own advertising first for podcasts in your network to test the system and attract advertisers that listen. Add an advertise with us option to your widgets. Failing those, hire someone to find you advertisers. Or something. Advertising hurts my brain.

6. Product Affiliates

Create a "cool audio tool" directory using amazon and other affiliates who'd like to advertise their wares to podcasters/users through you. This would fit well on the education blog and next to podcasts. Include hardware/software recommendations, reviews, etc. Track it all with stats.

7. Service Affiliates

"Advertisment FREE" podcasts for paying clients or subscribers.

8. Statistics

Watch them and learn.

9. Brainstorm

Put all the content producers on a mailing list if they're not already. Bounce ideas in it with them all. Create a community wiki to document all those ideas. They'll want to help, they're making a cut of the money for producing the content…

10. Get good developers to build it all

So you can sit back, feet in the air and let someone else stress out. I should also talk about networking, blah, blah, but I'm no good at that. Just do it. You'll figure it out with all that traffic and attention you'll be getting from people.

In conclusion:

• Build an API
• Build your own service on top of that API
• Open your API and service to the Public

The future is in API's and widgets(smart widgets and apps that talk back to your server with attention data).

I've been reading up a lot about dojo, a fantastic javascript toolkit that allows developers to make spiffy web applications without the hassle of worrying too much about things like browser compatibility. dojo takes care of most of the hard work for you and comes with loads of widgety goodness.

I wrote my first line of code today. In writing my first line of code I ran into problems. Windows. It's moments like this I miss my Gentoo box and the larry the cow forum humour. moo.
Anyway, in my wisdom, I decided to base my first app on an existing widget test, so I copied that test into my new projects directory. In doing so I knew I'd have to tell the script where to find dojo relative to where I'd moved the test. Herein lay my problem. I wanted to be able to freely move tests about without having to worry about directory relativity.

Here's the default source reference out of SVN:

<script type="text/javascript" src="../../dojo.js"></script>

and here's what I had hoped would work but didn't:

<script type="text/javascript" src="/htdocs/svn/dojo/dojo.js"></script>

instead, after looking through documentation and pulling out my hair, here is what I had to use:

<script type="text/javascript" src="file:///c:/htdocs/svn/dojo/dojo.js"></script>

note the three slashes. thankyou windows. :/

Thankgod for Editplus' abiilty to search and replace text in multiple open files! Whee. God, where would I be without that… *cringes*

Now, my test is back to it's full functional best, and I can play away. Yay!

Next I have to decide whether or not I want to use a framework with my new found dojo love. Python or PHP even Ruby… To django or not to django. Z.end perhaps. RoR what a decision.

PHP probably, app markets widest appeal it be. :/

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.