at dot lindsay at lindsay dot at

What to do if you’re concerned about Apple’s coming dominance with the iPad

2010-02-02T16:26:03Z

So you say you’re concerned about Apple’s hegemony with the iPad. You’re concerned that the iPad is for media consumption only, and will quash creativity. You’re concerned that it’s a power play that closes off open formats. You’re concerned that it concentrates too much power in the hands of one gatekeeper to your applications. If so, then go away.

Go to the open source world, because there’s no closed-source corporation nimble enough to catch up with Apple on their touch-based OS.

Apple has just grabbed the high ground in this scramble, and some variation of their personal, slate-like computing paradigm will dominate consumer computing’s attention for years – if not decades – to come. The computer is growing up, and Apple thinks they have the key to turning a general purpose computer into a traditional consumer electronics device.

(Incidentally, I can’t name a player in the computer industry that doesn’t share this common goal of ubiquity. Consider Google’s overt actions in the past year. Nearly every major new effort Microsoft has made for well over a decade has been in this direction.)

So, if we accept that Apple will cast a shadow as long as it has with the iPhone, what is to be done? The only alternative I can see is to work on organizing the open source world into offering an effort that could compete.

Forget the tappity-tappity of single touch alone. Reviews of existing best-of-breed single-touch devices suggest that people already demand something more. Apple owns multi-touch (as in, has key interaction modalities tied up in US Patents), and you would do well to look at something else. Pen-based computing has been around for two decades. Go and improve writing recognition. Consider previous user experience successes (such as the Newton and early PalmOS), and integrate the best of their innovations.

What does a responsive pen-based web browser look like? Can you make it swoop and glide like Apple’s offering? Maybe that’s the wrong way to go about it, but you can be sure that consumers won’t accept either long times to refresh a page each time it is moved or the one-line-at-a-time emulation of a user holding down a scroll arrow in a window.

Consider ergonomics everywhere. Apple does. Study people with a pen, clipboard, and some set tasks. How do people act when standing with the clipboard cradled in their arms? When leaning back on a sofa? When poking at it on a table top? How do these three main body positions inform software interaction modalities? Can one UI design accommodate all three? Make sure you can accommodate left-handers easily, now (and others with disabilities).

Once you’ve cracked the basic interactions, make it easy to create an application: be opinionated. There’s already too much flexibility, especially in the open-source world. When presented with a choice, offer the simpler way of doing things. What developers need is a strong vision and the building blocks for making applications. Start with the basics: navigating a hierarchy, filling out a form.

Got that? Congratulations. If you’re very, very good, you might be able to compete with usability of iPhone OS 1.0.

So you say you’re concerned about Apple’s hegemony. So go. Go and run, because Apple has a huge lead.

Music hack day

2009-06-29T09:32:47Z

I'm planning on going to the Music Hack Day in London in two weeks. I'll be waving the flag for The Echo Nest and their fabulous APIs. There's a lot being said elsewhere about it, but I wanted to send out a special welcome to French and Belgian hackers.

The hack day is being held at the Guardian's offices neat Kings Cross, London. That puts it just a couple hundred metres away from the Eurostar terminal in London. So, for precisely the price of a round-trip fare to London, you can hop on an 8am train, get fed throughout the event, housed on Saturday night, and return Sunday evening. Nothing else to worry about. Well worth considering if you're close to Lille, Paris, or Brussels. Oh boy, what I would have given for a weekend like this when I was living in Brussels...

So register right away: the spaces are now filling up fast!

And we can get up to antics like this:

(Which is just the Dissociated algorithm applied to video in synch with the audio, in the latest versions of the Echo Nest Remix API. In my opinion, it moves the image of the subject from being quirky to having serious battles with mental health.)

Twitstream

2009-06-20T22:45:09Z

Prompted by a tweet by Simon Willison on Monday, I was intrigued to hear about the Twitter real-time streaming APIs. In spare moments this week, rather than surfing the web, I found myself looking at how to get a view on the API from within Python which was… not trivial. In fact, none of the standard libraries seemed to handle the API at all: every HTTP access library waited until the stream closed, which was potentially forever.

A little poking and prodding, and I knew Twisted was capable of doing it. However, that seemed too heavy-weight a solution for just hacking about. I discovered asyncore, and despite the fairly thin documentation and examples online, it seemed clear that it could help. By evening I had knocked together something that worked with Twitter’s basic authentication and the proxy at work, which pretty much meant that I had to create my own basic HTTP/1.0 client. Not rocket science — I guess I had done the same thing 14 years earlier in Perl4 — but it took some trial and error, and neither the asynchat library nor any other common libraries did anything to simplify putting together an HTTP request.

I posted things up on github just to get some feedback on whether what I was doing was hopelessly misguided and reinventing the wheel, and — other than hearing it confirmed that Twisted could do this easily — it turns out no one else was doing this in Python. Cool, because they’re nifty APIs. It seems Twitter had turned into quite the target this year, with both Facebook on one hand and Google on another looking to get in on the action. I think the simplicity, transparency, and speed of the API are brilliant responses to things like Google Wave. This is very easy to work with, will keep developers around, and is pregnant with possibilities.

Oh, the speed. The fact that there is no apparent latency — a message that I send through my desktop client will appear in the stream before the miniature posting window even closes — makes this tremendously satisfying to work with.

After returning to the project like a bad rash, aided by encouraging words, github followers, and a primal pleasure in seeing words from all around the world spontaneously crawl up my screen, I’ve got a good chunk of code. It’s not brilliantly engineered, but I really enjoyed the process of it, the way it grew organically while trying it with different applications, such as a twistori clone to track (and highlight) multiple keywords in the Twitter stream.

There’s also fixreplies.py, a read-only client that mines your Friends, Followers, Favorites, and conversations to find people to track all public tweets to and from. While I think Twitter did the right thing in limiting replies, this makes for an interesting adjunct to a main, traditional twitter client. You get the feel for a lot more conversations sliding by. As it’s only text in the terminal, it feels more ephemeral, with far less of a need to catch up on everything.

Mostly as an exercise to see if it could be done, I also turned that client into a double-clickable script in Mac OS X. Click, and it opens up a terminal window, asks you for some information on your account, what sorts of users interest you, and how to find up to two hundred users’ conversations to listen in on.

I do hope that Twitter makes this available for desktop clients and the general public, because it really expands the, er, Twitterverse, and opens up new possibilities in interacting with and getting data from Twitter.

The promise of html5 and low-hanging fruit

2009-06-06T18:55:20Z

I don't have enough time in a month to get one third of what I would like accomplished. I've been brainstorming in various contexts, and I've decided to start giving ideas away wholesale. I have had no problem thinking up ideas in the past, and don't foresee any problems in the near future. I may as well start putting them out there for anyone to pick up and use.

I spent too long this afternoon browsing through the html5 working draft, and found some nice things in there, such as the pre-defined BibTeX vocabulary. At first, it's unsettling that html5 can exist in a well-formed XML, a decidedly non-XML form, and every step in between, but given the right tools, that might make for interesting opportunities.

Many forms, one document

For example, from what I understand so far, the following two documents will be identical in DOM5 html, thanks to optional tags:

<!DOCTYPE html>
<title>Sample Document</title>
<meta name=keyword content=example>
<h1>Sample Document</h1>
<p>Hello<br>World!
<table><tr><td>a<td>apple<tr><td>b<td>banana</table>
<p id=done>I'm done now.

and

<!DOCTYPE html>
<html>
  <head>
    <title>Sample Document</title>
    <meta name='keyword' content='example'/>
  </head>
  <body>
    <h1>Sample Document</h1>
    <p>Hello<br/>World!</p>
    <table>
      <tbody>
        <tr><td>a</td>
          <td>apple</td></tr>
        <tr><td>b</td>
          <td>banana</td></tr>
      </tbody>
    </table>
    <p id='done'>I'm done now.</p>
  </body>
</html>

On one hand, it's faintly alarming. On another, it starts to look kind of cool. (On a third hand, is it old news? I don't think html5 approaches this in quite the same way that html4 could sort of be in XML-ish form.) I could be as terse as is legal when authoring a document, then serialize it to a canonical well-formed XML document, and then use the end product in my XML toolchain of choice, whether for storage or transformation or editing.

Dear someone looking for something to do — make this tool for the world: a full html5 parser that serializes to well-formed XML. Replace all entities (except the necessary five — or even two) with their Unicode equivalents.

With that accomplished, you probably can make a big splash by also letting it output html that current browsers won't choke on and/or conversion to html4 that retains semantics by converting new elements to div and span.

I'd really love this tool if implicit sectioning elements in an outline were converted into explicit section elements. Having easily manipulable outlining sections would enable a lot more tools — or allow you to consolidate many writing tools into one.

An archive format?

Why do I care about well-formed XML? Well, did you notice the difference in sizes between the html parsing and Xhtml parsing sections in the html5 draft spec?

Working for years in MPEG made me appreciate why we should strive for data longevity. It might be merely an abstract ideal, but it's one of our primary tasks today to be kind to our future selves. If I come across a document in fifteen years, I don't want to have to look up which elements are void elements in order to parse it. But we owe it to ourselves to archive in a format with more structure than plain text, or even an enhanced text like one of countless wiki formats, Markdown, or Textile.

As I make and break websites and leave them online as a form of digital detritus, I've also been thinking a lot about the maintainability and migrability of data. I'm finding it's easier to setup a new CMS than it is to migrate an existing CMS and its data to another machine. I've even considered migrating out of various CMSes by crawling my own websites. Uck.

Influenced quite a bit by Mark Pilgrim's thoughts on The Format, I'm now considering a well-formed flavor of html5 as the format for now. It's not as complete as docbook, but the structural elements are sufficiently complete for 95% of use cases for extended text. And it's more compact. And it'll be trivially viewable.

So, the other itch I'd love someone to scratch is to create an author's profile for html5. The html5 spec describes what is essentially a delivery format. It has worked hard to separate presentation from semantics, and goes as far as it can in doing so. However, there's a lot in the spec that has very little to do with an article or group of articles connected to form a multi-page resource. I would like a canonical version of an article to carry just the data (and metadata) necessary for the article, and nothing more. It should be self-contained and portable.

From an author's point of view, I would like to concentrate on words and structuring those words. No navigation, no scripts, no unnecessary headers, footers, banners, or columns.

That is to say, the canonical format for the ages doesn't have to be the same as what the user accesses — but they could share the same syntax and semantics. If I'm going to have my work mediated by a CMS, then I want it also maintaining a canonical format for each resource, free from the navigation and eye candy that seems to be necessary to get noticed, and free from existing only in a database that creates a lot of inertia for my data. Dokuwiki, as with so many other things, seems to get this right, with its do=export_* modes.

All roads lead to...

That's starting to suggest my next itch to scratch: a CMS that embodies these principles. It can ingest data in various formats (so long as it can be rendered to html and potentially carry a little metadata so that an envelope format isn't necessary, it sounds usable to me) and via different channels (REST and some flavor of DVCS feel like my current favorites). It could render these sources lazily, only when the web server misses from a pre-rendered cache, so that most of the rendering machinery stays out of the way most of the time.

This architecture isn't miles away from how Blosxom does things, mashed up with Django's FlatpageFallbackMiddleware. The core could be small, fast, and flexible, working with varied storage solutions and template languages. Really, it seems like the core code for this involves routing, knowing when to render, and how to ingest from diverse sources, and very little else.

This final idea obviously doesn't rely upon html5, but thinking about data longevity and what a webpage is naturally leads me back down this road. Ooh. How original. Yet another CMS. Well, yes. But right now, I have to shelve the idea for later anyway — or hope somebody comes along and makes this exactly how I imagine it to be.

Twitter

2009-05-13T15:25:24Z

Twitter's currently ablaze with talk about the recent change to how @replies are handled on twitter. (Actually, as of this writing, it's ablaze with a shocking number of "RT this if you disagree with Twitter's decision to hide replies to people you don't follow. #fixreplies" messages that cause a massive facepalm.)

While I agree with the change (because for most of my multiple use cases, that's how twitter works best), I feel for the people who didn't use Twitter this way. Their whole way of looking at the social web has been taken away by the elimination of an application preference. That's surely upsetting, and I can't hope to change their minds. But I can try to get them out of their heads and see how the change makes sense for a lot of Twitter scenarios.

I operate a bot, @recomme (which is currently in the shop for maintenance due to another API change that Twitter made with no warning — so my above empathy is real) that feeds on @ replies: send recomme a message, and it tweets back to you, also in the public stream. If you keep your tweet stream private, you must follow @recomme, and it must (auto-)follow you back. The same follow requirements happen if you want to send private messages and receive them back.

This seemed like a reasonable model when I designed it because to me, the sensible way of managing replies was to see only replies to those people you follow and have asserted that you found interesting. @recomme has nearly 4000 followers now. For those people who have kept their settings on receiving replies to people they're not following, that's a lot of eyeballs to reach, especially when anybody can trigger a message from the bot. Fortunately, this has not been noticeably abused by any of the thousands of users. Unfortunately, because of the existence of the all-replies setting, the bot receives nowhere near the number of tweets you would expect from the number of users, I suspect because the social cost of sending tweets to and from the bot are big.

Now, if Twitter stays with hiding replies to people you don't follow, then my vision of an "emergent social network" can happen. People can happily tweet the bot, knowing that people who don't care about music recommendations won't see those tweets or those replies. The people who do care about you and music recommendations do see those tweets, and I think that's a nifty way of opening conversations.

For my own tweets, I struggle with keeping the number of people I follow down, and I have a tough time refusing to read tweets. The "@ replies to people I'm following" setting was an effective filter. Actually, there's a core of twitter users who I know in real life, and I am more keen on seeing all their tweets. (And did so with a secondary account that saw all replies.)

But the real reason why I'm in favor of the recent change is because of new users. Techcrunch actually showed some insight after their typically incendiary headline:

Before tonight I never paid much attention to this train of thought - after all, on Twitter, I can just follow the people I care about and ignore those I don’t. But it’s clear that Twitter is concerned with appealing to a more mainstream audience, and if that takes making a very simple service even more simple, then by golly, that’s what they’re going to do.

Well, yes. Exactly. My pride as an early adopter is far outweighed by the desire to have more close friends and family come to Twitter.

What does a new user see after adding a few friends and "recommended users"? Some tweets, but a lot of decontextualized half-conversations. This is confusing and off-putting. I feel guilty some days when I use Twitter as an open IM/IRC channel, having long threads of conversation. For those who follow all of my tweets, I must seem incredibly boring, geeky, trivial and somewhat profane. That's accurate, but it's not what I like to remind people.

I think that seeing this chatty, focused, decontextualized side of Twitter is not a very gentle introduction for newcomers. It might be useful for comfortable users who have been around for a while but follow dozens of people (or for very prolific users who skim or otherwise filter their tweet stream but don't pay particular attention to any users in particular). But for introducing users to Twitter while fighting concerns that it is "trivial," it's a pretty important step to take.

Some ideas that were thrown at me were improving the experience:

Carr0t: I would prefer it on a per-user basis. So I could say ignore @replies from @stephenfry, but get them from @daagaak.
daagaak: It would be nice for API users, bots, etc to be able to specify if a tweet should act like that. I just dislike the list of discovery.

...in other words, make the control more fine-grained, whether it be push or pull. Well, changing the granularity would be welcome from my selfish point of view. I could zoom in on some users, and not on others. I can see the appeal of the push-control, too. I would have welcomed making @recomme more private, if that had been an option.

But the truth is, that's all too fiddly. It makes a degree of sense to a "power user" like me, but from a user standpoint, it's a disaster. Too many things to control. The point of the change was to simplify a hard to understand option, something that I stand behind on principle.

On the other hand, Anne said, "Never take options away from a user." Those are also wise words. My gut instinct to make as many people happy as possible would be to grandfather in the feature: keep the option for those who have changed from the default, make it disappear for all others. This creates two tiers of users, though, which is untenable in the long term, especially from the social aspect: these exceptional users have a view on Twitter that is fundamentally different from others, and are likely to use it differently. As such, I think the feature should be phased out. Leave it to clients to support an expanded view of the greater twitterverse.

There's a Twitter truism that's been floating around: "Anyone who tells you how Twitter should be used is wrong." I've tried not to fall afoul of that here, but it's a fine line.

Launchpad, Github, Bitbucket

2009-05-07T21:41:15Z

I'm not a programmer. I don't harbor dreams of writing elaborate code that gets lots of users and has lots of programmers follow my lead. But once I get into it, I enjoy hacking on code, and am happiest to have just a few lines of minimal and/or clever code that a few other people with odd tastes might also enjoy making use of. I like to share.

I've been thinking a lot about distributed revision control and online code hosting lately. I've stirred up a few conversations on twitter because of these thoughts, and wanted to lay them out here.

I tried with Git. And I got far enough with it to get into trouble. I eventually made a mess of a few commits on a public (SVN) repository. Since I couldn't make distributed revision control work with subversion, then I ended up learning subversion better (and rsyncing between my private, local branch and the mainline). From the start, I found git to be too far from my own mental model, and too optimized for situations I didn't value (huge code bases, distributed teams of mergers, fast performance and in-place context switching). So I didn't try very hard. That's fine. There were other choices in distributed revision control.

I liked Bazaar from the start, largely on its stated values (easy model, one repo is one directory, concentrate on getting it right before making it fast), and that it got me up and running quickly. It wasn't only from the out-of-box experience, but the excellent documentation on different prototypical users and their workflows, and the fact that there was an easy path to push repositories to a remote server using only sftp .

When I was looking at these solutions, I set Mercurial aside, because it didn't seem to have a lot mindshare at the time, and I had difficulty installing it on the Mac the first time. (Actually, I had problems recently, until I realized that using the Makefile was far less effective than using my oft-incanted 'python setup.py install'.)

It's a bit over a year and a half later, and some of the sheen has definitely gone off bzr for me. There are some little annoyances that have built up over time:

The admirable striving towards "getting it right" has resulted in many updates to the repository format since I got started, and countless updates to the mainline program. This commitment to keeping the project up to date is admirable, but it's annoying to chase.
My dependency on the rspush command (I like to have a working copy of my most important repositories on remote machines, and not have to rely on installing bazaar if something goes horrifically wrong) means that I must always install the BzrTools plugin, which multiplies the annoyance of the development churn.
bzr-svn was extremely unsuccessful for me.

I could deal with these small issues easily, but the big issue is becoming hard to ignore: if I want to share my repositories with other people, then I don't have a clear way of doing it.

Yes, I know about Launchpad. I've even hosted a now-abandoned project on it. It's an impressive bit of engineering and a wonderful, completely free service. There are numerous interesting projects with a home there . I just don't think any of my near-future projects could have a home there.

As a dilettantish coder , I am drawn to the sorts of odd little projects that one sees on Github. I can easily bookmark a project for later inspection, and do so often. Github's prolific social model clearly works. It knows that its users are developers, and makes every part of its interface geared towards that. I feel comfortable enough with git that I might branch, modify, and push back existing code, but I don't feel comfortable using it to organize a project of my own doing.

Launchpad's hosting, by contrast, feels "heavy." In fact, it feels like a SourceForge clone, where it hides the code away, and concentrates on end users. That's great for users, and sounds very appropriate to the user-centric focus Canonical has. But I don't need a bug reporter and project planning and translations and a knowledge base. I want programmers to see my code and to get my code if they want. I want to provide some context in the form of a README. That's more or less all I need to publish.

On Launchpad, giving a context involves writing text in a web form that's half the size of the form that you are given for telling people how to report bugs. Nothing is integrated with the excellent revision control system other than the code itself — and the code is consistently four (non-obvious) clicks away from the project home page.

I have devised a crude way of making a permanent note of a project's code I want to remember, but it's a multi-step process (involving "subscribing" to a code repository, but disabling all email notices of changes) that I keep forgetting how to do. I'm not saying Launchpad isn't usable: it's not easily usable by me, who likes using the developer-as-user-centric Github model.

(Google Code, as an aside, is nice. It's unobtrusive interface has a nice set of features, and they get out of your way when they're not needed. It's not instant to – for example – assess how fresh a project is from the date of its last commit, but that information is a couple consistent clicks away. I just don't want to initiate a project using subversion, knowing that, given my history, it will reach some state of abandonment eventually: if I'm the only developer, then the SVN repository is essentially locked away in an immutable state forever. I'd rather let people discover my code three years down the line and branch freely.)

So, what am I thinking about now? Despite some encouraging words I heard from a local developer who's on the LP team, I'm very dubious about the prospect of Launchpad bending to my will. It would involve de-emphasizing the work of half a dozen teams in the web interface, all in the interest of Making Things Nicer for Adam. However, building something new up from something minimal might work well. It wouldn't be that hard to expand Loggerhead, the core Bazaar repository-view web app, to include basic social web features. It's a foolish thought for me to have at this time (when I need to put all my available energy into the thesis).

On the other hand, Bitbucket looks like a pretty reasonable Github clone, and from my experience, hg's model is not too far from bzr's. Right now, barring any further developments, I'm considering publishing future projects there. Yes, it would involve changing to hg (Snej's Murky makes that a bit more inviting.) On one level, that's mad, to change my revision control system on account of an social web application (that's an unapologetic clone of a different, wildly successful service). But that's what's important to me right now: if I want to share with the world, I want enough people to see my code and take it home with them. I want it to be easy for me to manage changes and evolve the code for as long as it engages me, then set it free.

Well, I think I've said some fairly dismissive things about just about anyone's favorite tool and/or service. I'm opinionated, but I'm ready to learn from those who like to inform and engage politely and productively. I'm not, however, interested in zealots.
So. Thoughts?

What would you pay?

2009-05-06T23:54:28Z

Would you pay $849 for a new MacBook? - Apple 2.0:

According to AppleInsider's Kasper Jade, Apple sees the cuts — which could come in the next month or two — as an 'interim solution' to the growing popularity of netbooks, those sub-compact laptops that Steve Jobs once dismissed as 'a piece of junk' but which are flying off the shelves at $299 to $349 apiece.

Another round of wishful thinking via rumour, but I just wanted to point out that what's key with watching Apple here is not the bottom price points, but the interlocking matrix of price points. Over the years, led by their iPod business, Apple has mastered the art of the upsell through models with additional features. I think the turning point was the introduction of the iPod mini, at $249. For 'just' $50 more, you could get a full-sized iPod with nearly four times the capacity.

Take a look at the Mac portable and desktop, consumer and professional lines, and see that the jump from one product to the next is about the same as the jump between models within a product line. Really, spend some time at store.apple.com, and see that the price matrix is just as precise and artful as the company's engineering. The question is not "how low can Apple go?" but rather, "what shift in the prices of existing products will suggest more models in another product down the line where an upsell to the current cheapest product is an easy jump to make?" (Easy, eh?)

So let's speculate irresponsibly. If the current white MacBook model goes down to $849 (which is already a leap because Apple doesn't cut prices lightly, as they know it's hard to turn back), as the linked article proposes, then it would support netbooks at $749 and $649. Or maybe "MacBook Minis" at $599, $699, and $799. Adding one product line doesn't get you close to the mythical $349 that people are wishing for.

Wait, should that be "MacBooks Mini"?

Writing on remix

2009-03-24T00:33:31Z

I haven't been writing on this blog. Never mind why not. I have, however, been writing on this site, trying to fill in the CMS's content a little more.

I wrote a couple pieces on work I have done with The Echo Nest Remix API. It wasn't planned, but it ended up being a good way out of a writing logjam I had found myself in. It was prompted, of all things, by a tweet by a colleague. Was there a place that explains it all? Actually, no, there wasn't.

It's not the finest literature, but I hope that my overview at least communicates my enthusiasm for the project. I've been talking about the principles behind Remix for years and years, but never found quite the right framework for giving those ideas shape. Why, yes, of course multimedia descriptions can be used to drive changes to the underlying media.

My favorite way of thinking of Remix is that it makes each song its own API: each song offers queries into its own features, and can return any number of transformed versions of itself, all of which are sensitive to the original song’s musical features

That sentence wasn't written off the cuff: it distills the essence of my current personal research.

I had meant to write about some further examples, but instead got sidetracked and spent some time looking at automatic documentation methods. It turns out that epydoc is pretty useful software. I had never used the reStructuredText markup language before, either. Although I found it to be a bit heavy on the "ant turd tokens," it was surprisingly usable, especially for code documentation.

So the second release I made last week was of the API documentation. I'm not completely comfortable with where it's hosted, but I did design the URL to be stable and long-lived, if it needs to be. In editing and polishing the documentation, it definitely helped me understand things better, and appreciate that this is turning out to be one formidable bit of software.

The third release was the one I had been planning from the beginning. I had hoped to let the world at all in one go, but the enthusiasm behind them (my own and from the people to whom I showed early versions) was too great for things to wait for my explanation of the Dissociated Mixes.

I knew I wanted to tell people about these mixes after the surprising results I got from writing a code example that illustrated what a sorting operator could do. A bit of thought, and the card metaphor came about. I wanted to make it as accessible as possible to a general audience, but also give enough detail to people who were technically minded—whether about technology or about music. Although the other documentation has gotten some attention from developers, I'm really enthusiastic about this piece for a general audience. It also approaches a silly topic with a fairly straight face. Sounds familiar…

RIP DFW

2008-09-14T08:44:42Z

David Foster Wallace is an author who means a lot to me. I just woke up and learned (via Twitter) that he died by his own hand yesterday. "Infinite Jest" is my desert island book: I've read it at least three times, and will continue to return to it for the rest of my life. So much of his more recent work lays bare his constant struggles to write in the face of the internal critic, so that theme is particularly bracing right now as I work through my PhD thesis.

In other, far more trivial news, the blog (and domain) is back. It disappeared for too long because of some nic.at mixup, probably as unforeseen fallout from my transfer between domain registrars.

I'm everywhere

2008-07-08T21:51:14Z

I've taken another step in Lifestreaming (as I think they call it nowadays). I took an immediate liking to soup.io as an online RSS aggregator and blog. I had collected most of my content from around the web in the "lindsay.at/everywhere" link ("Preoccupations" on my home website's menu). The problem was that it didn't work so well all the time, and was often down. By redirecting to my soup page, I can now get a better-looking, more reliable stream of the content I excrete onto the web.

I also took an immediate liking to Posterous, a blog-by-mail site. The site isn't particularly pretty or customizable yet, but it handles email input fairly deftly. I'm now treating it as a tumblelog, a receptacle for interesting and amusing links that I send to friends. With a simple CC, I can stick links on my site with trivial amounts of effort. When I get an iPhone, I can easily imagine it handling mobile blogging as well.

These two sites are also worth a mention in their very easy, no-commitment, no-password-or-signup approaches to enticing new users. Posterous simply asks for an email: they'll auto-generate a URL for you. Soup similarly gently leads you down a garden path, asking for no personal data, simply for addresses to import. Well done, and it's something that other sites will do well to emulate.