AIM SDK

The AIM guys just announced the Open AIM SDK.  Very cool; you can do AIM Triton plugins or write your own AIM network client.

New Feature: Common Feeds Icon

Another update to Journals this week was the switchover to the Common Feeds Icon (). This is the same icon used by Firefox, and soon Internet Explorer and Opera.  Also, AOL's Favorites Plus.  It's also being adopted by web sites at an astonishing rate.

(Why a new icon to indicate feeds?  Because "RSS" doesn't exactly scream "dynamic feed of updates for this web page".  And lots of people our testing thought the tiny icon said "R55", which is even more useless.)

Rogers Cadenhead has a nice discussion here (see the comment thread too).

There's a debate over whether this icon should indicate an action (subscribe to this feed) or be a link to the feed resource (see the feed, and maybe subscribe).  I personally don't think this is a huge issue, as long as a user isn't left staring at XML source.  If an application only lets you do one thing with a feed, jumping directly to subscribing seems like a good idea.  If you can do multiple things, give a menu of some kind (like Journals does) or a preview with options... humans can figure it out given reasonable feedback.  Machines can't, but then they're not looking at the icon, they're looking at the <link rel="alternate" type="application/atom+xml" ...> markup in the page header.

Also, they're called "feeds".  Doesn't matter if they're RSS 0.91, RSS 0.92, RSS 1.0, RSS 1.1, RSS 2.0, RSS 3.0, or Atom.  And it really doesn't matter that they're in XML (well, except for RSS 3.0 :) ).  What matters is that you just look for the if you want to keep track of what's new.  Simple.

New Feature Demo: Flickr Photos

One of the little things we did for our latest update was to open things up a little bit to allow some types of iframes inside entries -- basically iframes from trusted sites.  We'll be adding to the list of allowed sites as we go forward.  Right now Flickr makes for a great demo:

Mashup Camp Concludes

Mashup Camp just concluded in the Computer History Museum.  A very nice, direct, simple mash-up -- PodBot -- won 'best mashup'; second prize went to the everyhing-you-ever-wanted-to-know-about-Chicago-crime-statistics mashup ChicagoCrime.org.  PodBot does just one simple thing but does it for data around the world; ChicagoCrime does lots of things for just one city and subject.  Also, PodBot is all about having fun and ChicagoCrime is about not getting killed.  Sort of a yin/yang thing.

The unconference itself was good.  A lot of good sessions conflicted, so I had some quandaries; but I think I made the best locally optimal choices possible.  No regrets.  The WiFi was good (better than most conferences with 250 people in a single room) but still not perfect.  But it wasn't too bad since there was little need for a backchannel.

Software Development's Evolution towards Product Design

Software Development's Evolution towards Product Design -- Danc Redmond writes a great article from the perspective of a product designer.  I agree with nearly everything he says, especially the need for small, unified, cross-functional teams.  A few minor caveats:

• Programming, done properly, is not a production activity that can easily be separated from product design.  If it could be, it's basically rote work that can and should be automated.  The non-rote work that programmers should focus on is all about figuring out how to hack the universe in order to deliver superior benefits to the customer.  Which is part and parcel of product design, which is why those small, cross-functional teams are so valuable.
  
• A big factor in game development and web design companies' successes was sheer volume and high competition.  There are plenty of terrible user experience in both camps (books have been written), but the industries have thus had a chance to learn from lots of successes and failures and iteratively improve. 
  
• Nit: The benefits summary is great -- 98% success vs. 18% success is a great statistic that can get business people to sit up and listen.  But y'know, this needs to be backed up with specific references to really pack the necessary punch.

In the past, most of the software industry has been busy creating dancing bears.  It's not how well the bear dances, but that it dances at all.  That is changing.  There will be some isolated refugia for internal corporate software, niche verticals, and bleeding-edge hardware interfaces where those clumsy dancers will survive and even thrive.  But the rest of the industry is going to start competing on more than bare functionality, and that will quickly shake out the companies which won't or can't adapt.

AOL and Dojo

Several engineers(*) at AOL had a very interesting meeting with the Dojo guys last week.  One of the results is the announcement that AOL is hosting the Dojo toolkit on our content distribution network.  The reason this is great is because the major barrier to adoption of DHTML/Ajax/etc UIs is, honestly, the download times for the Javascript code; you only pay this once but it's a major concern.  The CDN helps enormously with this since it does automatic compression, caching, intelligent routing, proper browser bug workarounds, etc.  If enough people adopt this, it would be a win for everyone (only the first application to require a library module pays anything, the rest get it for 'free').

I hope we'll be able to do some more interesting things and help contribute to Dojo as well.

(*) OK, technically I'm a manager, but they let me wear the engineer hat sometimes.

Another One on Tagging: Data on Folksonomies

This folksonomies article is good for the questions it raises, but alsofor the data it collects in one place -- lots of good statistics ondel.icio.us and flickr usage of tags in this paper:

Folksonomies: Tidying Up Tags?
"Thisarticle looks at what makes folksonomies work. The authors agree withthe premise that tags are no replacement for formal systems, but theysee this as being the core quality that makes folksonomy tagging souseful. The authors begin by looking at the issue of "sloppy tags", aproblem to which critics of folksonomies are keen to allude, and ask ifthere are ways the folksonomy community could offset such problems andcreate systems that are conducive to searching, sorting andclassifying. They then go on to question this "tidying up" approach andits underlying assumptions, highlighting issues surrounding removal oflow-quality, redundant or nonsense metadata, and the potential risks oftidying too neatly and thereby losing the very openness that has madefolksonomies so popular." Commentary by Marieke Guy and Emma Tonkin,UKOLN. [D-Lib Magazine]

(You gotta hand it to the old-school Digital Library people.)