Gordon Weakliem references Patrick Logan who references Philippe Bossut who references Alex Russell’s OSCON talk on AJAX. The little tid-bit that gets me excited is the quote “Best data type to return: JavaScript instead of XML”. I want to add an emphatic “yes!” to that. Only a crazy fool manipulates XML on the client-side when manipulating Javascript is so much easier. And, yes, I also want add another link to this long chain of attributions.
If you’re a Lisp head, like us at Untyped, when you look at Javascript you get an itch to add back all the parentheses (and fix its silly scoping rules, but that’s another post). Unsurprisingly we’re not the only ones. There is this Lisp to JavaScript Compiler I found via LtU, and also ParenScript. These are pretty cool. Of the two ParenScript is more practical, though the translation remains fairly direct. I’d like to see these languages go further and add features not present in Javascript. I think ParenScript gets the scoping rules correct, so next on my list would be coroutines to make coding animations easier.
I see via Ditchnet.org that IE 7 Beta 1 is out, and support for CSS 2.1 is in the works. For comparison, see what Deer Park Alpha 2 (the next version of Firefox) includes. It looks like IE 7 is going to be a good browser for 2004, and an ok browser for today. This is still good news for web developers, because IE 6 is a terrible browser for today.
Podcasting is going to save the world … if only we could find something to listen to!
Tyler Cowen writes on Marginal Revolution:
The key question is what kind of aggregators will take off … The relative returns to “portal podcasts” will be lower than for portal blogs. Glenn Reynolds can read and process material faster than most people, but no one can hear a two-minute comedy routine in much less than two minutes … So you won’t find good podcasts through other podcasts to the same degree, since it is harder to serve as an effective portal. The sorting will work less well, and the categories will be harder to describe and communicate. Advertising will matter more, and institutions such as iTunes will have more influence over selection and content. Podcasting will be more in hock to MSM than are blogs.
The two most prominent podcast portals are Odeo and iTunes. Unfortunately they’ve got it wrong. Both iTunes and Odea organise podcasts into categories, but as Tyler points out the categories aren’t that useful. For example, let’s say I want to listen to some new music. Right now there are only 692 channels under the Odea music tag. That is a few too many to listen to. If I try to be more specific and go to the Indie tag there are 92 channels. This is better but still not great; the term indie covers everything from whiny boys with guitars to stuff I might be interested in hearing. So perhaps Tyler is right and podcasts are doomed.
Or perhaps not. As I posted earler, implicit feedback is much better than explicit categorisation. If you want to see how great implicit feedback can be in the music arena, look no further than last.fm. If I like, say, Mouse on Mars then last.fm correctly guesses I like Plaid, Autechre, and Aphex Twin. All is takes for last.fm to work is a little plugin that tells the site what music you’re listening to. Could the same technology work with podcasts. Of course! Problem solved.
Tom Evslin writes a great post on the importance of pricing, and in particular not under-pricing oneself:
I won an argument with an IBM SE on the very
good grounds that I was more expensive than him; my
recommendations for system changes were implemented
(grumpily) and some of them worked. We got a much bigger
consulting job after that which I’ll probably blog about
some day because it’s an interesting story.The moral for today is one that every maker of luxury
goods already knows: price can create a perception of value.
As a consultant, you need high perceived value or no one
will give you the time of day let alone their watch. And,
if you don’t have the respect you need to get information or
to have your recommendations tried, you can’t succeed.
It’s a good point. Particularly when starting out, and
overheads are low, it is very tempting to sell on the basis
of price. We’ve done so in the past and the results have
been bad: the client hasn’t respected our time and
has given us the run-around.
If you’re in this situation you’re probably thinking
“if I raise my prices all lose all my
clients!” Particularly in fields such as web
development, where there is so much competition, this is a
valid concern. So what to do about it? Well let’s think
about why high prices work. As Tom says, it is because of
the perception of value they create. Which is to say it
seems to the client that your high-priced service is better
than the competition’s lower-priced one. There are many
other ways to give the client this impression. For example,
you can write articles that show the breadth and depth of
your learning. As you’ve probably guessed, Untyping is just
such as effort. Management gurus call this differentiation,
and the more competitive the market the more essential it
is.
So there it is. You can’t charge high prices if the
client thinks they’ll get the same service from your
lower-priced competitors. You must differentiate yourself.
Paradoxically price indeed is one way to do this, but in
many cases not the best way, and can be deterimental if you
haven’t already established a reputation in other ways.
Go to Yahoo and you’ll see a riot of news stories, links to services such as Yahoo Messenger, and right at the bottom of the page… a link to the service that launched the company, the Yahoo Directory. It is laughable now to think that a human maintained directory could keep pace with an powerful search engines and exponentially growing web, but for a long time Yahoo’s directory was the web’s best way to find information.
Early search engines considered only the text of a web page when searching. They could find all the pages that contained the words you were looking for, but they could not tell you which ones were important, leaving you to sift through the hundreds or thousands of results. In this situation going to Yahoo’s directory was a short-cut to finding the most important pages on any topic. It might take you six or seven clicks to drill down through the hierarchy but you’d get there in the end.
Then along came Google. Enter some keywords and Google will give you the all pages that match those keywords, ordered by importance. In most cases, Google is sufficient. The key innovation in Google is that recognises that people indicate the pages they consider important by linking to them. Google uses that information to rank pages via the PageRank algorithm. With millions of web pages individual variations don’t count for much, and what you end up with is the pages generally considered best.
There is a big idea behind the PageRank algorithm, which is that people implicitly tell you what is important to them. The Yahoo model was to explicitly ask people what is important to them. This doesn’t scale. Implicit measures scale better, and in fact perform better as size grows, as noise in the measurements cancels out.
Fast-forward to today. One of the hottest things on the web at the moment are services like del.icio.us that asks people to tag pages or assign ratings to them. This is another example of explicit feedback. You don’t have to look long at the most popular tags on del.icio.us to see that the demographics are skewed heavily towards the geek end. Now explicit feedback is great if you can get it, but while you can expect obsessive-compulsive geeks like myself to meticulously organise their links, but you can’t expect the man-on-the-street to do the same. What is needed is implicit feedback.
For services like del.icio.us that aggregating pages on
a common theme, there are a number of algorithms that
will apply PageRank in a topic-sensitive manner (for
example, the aptly named topic-sensitive PageRank). For services that maintain rating of pages, there has
been quite a lot of work on implicit ratings, collated in
this excellent recent survey. Several studies show that reading time is correlated
with interest. If you run a web site, this is one
statistic you can easily gather, and one that the
Attention.XML
spec includes. If you write web browsers there are bunch of other
measurements you can gather, such as scrolling and bookmarking.
Of course for most of us these measurements are out of reach!
Explicit measures have one advantage: they are much easier to get started with. If I rate a blog post as “good”, the meaning is unambiguous. If I spend 30 seconds reading it you need some sort of model to convert that into a rating, and to build that model you need a fair amount of data, knowledge of machine learning techniques (we can help), and probably some beefy hardware to handle large numbers of users. For small services this may be too much, but for large services it is the way forward.
Untypers keep their eyes on a number of weblogs; one of them isLemondoor, a LISP-related weblog maintained by jjwiseman. In this post, he points us at Fluxus, a very cool looking real-time coding and live-performance engine for sound and visual effects.
http://www.pawfal.org/Software/fluxus/
We don’t like to blow our own horn too hard, but around untyped we do pretty well with a number of languages, and Scheme is a favorite; we have a number of open-source projects written in Scheme, and it drives some of our own research projects as well. Fluxus looks like the kind of platform that we might be able to do some very fun and exciting things with.
I just read about an interesting library for using CSS selectors to apply Javascript behaviours, courtesy of a link from Ajaxian. The idea is simple: use CSS selectors in Javascript code to specify DOM nodes that Javascript event handlers should be bound to. This abstracts the event handling code away from the HTML. This gives cleaner code, though I’m not sure how useful it will be in practice, for two reasons:
However I don’t want to give a negative view of this
library. I think it is really neat, and it has interesting
similarities to Aspect-orientedprogramming (AOP). In AOP you change code by specifying
places to add extra functionality. This library is
changing HTML by specifying places to add extra
functionality. If you squint the right way HTML and
Javascript merge into one, so there seems to be a
relationship here. I don’t know enough about AOP to know
if this analogy opens up any interesting new directions,
but I know people who do, and I hope they’re going to
comment on this. 
