furia furialog · Every Noise at Once · New Particles · The War Against Silence · Aedliga (songs) · photography · other things
13 March 2006 to 5 March 2006
Even the most movie-addicted people I know don't usually take the time to re-watch movies with the DVD commentary track on. I do, but I was a filmmaking major in college, and have a really high tolerance for obsessive introspection in any format.  

But if you haven't seen the movie Spy Kids, go watch it, especially if you haven't seen it because it's a kids' movie and you aren't a kid. It is a kids' movie, but in a way that you should still be a kid.  

And then, if you haven't seen Spy Kids 2, go watch that, especially if you haven't seen it because it's a kids' movie (see above), and especially if you haven't seen it because it's a sequel. It is a sequel, but it's the kind of sequel that the first movie makes wonderfully possible, not cynically expedient.  

And then watch Spy Kids 2 again with Robert Rodriguez's commentary on. It's not laborious annotation, it's an accidental evangelist's 97-minute exhortation to creativity and experimentation and simplicity and complexity, and not only makes me love the movies more, but makes me happier and more excited about art, craft, technology, freedom and everything I haven't tried yet.
Anyone who wants to have more reason to feel involved with arbitrary MLS games this year should go sign up for MFLS, the best and longest-running MLS fantasy league.  

The roster deadline for week 1 is 3pm Eastern, April 1 (and remember that Daylight Saving Time starts on April 2 this year).
"I've been sad with my magnitude lately, what and you."  

I know what it's insinuating, of course, but sometimes poetry writes itself into our deceits while we aren't watching them closely enough. Our powers are so great, and yet here we are, lately as ever, sad with our magnitudes.
I'm not sure I've seen more than a dozen music videos in my life that seemed to me like independently worthwhile demonstrations of human creativity. As a field of marketing ingenuity and technical innovation, music video is astonishingly rich, but as an art it's a horrific disaster. At this point the most I really hope to get out of a video is some more visceral impression of how an artist from some culture other than mine fits into theirs, and/or crosses out into mine.  

But I just watched HIM's DVD of 1997-2003 videos, in search of little more than some shots of their Finland, and am adding "Right Here in My Arms" to my not-formally-compiled but I'm sure pathetically short list of internally brilliant music videos. It's brilliant enough that I can tell you what's brilliant about it without you having seen it. Structurally it's mostly a performance video, staged inside and outside of a room whose walls are one-way mirrors transparent from the outside in. The band is inside the room. A girl is outside. She is watching the band, and sees them watching her back. They see and are watching nothing but themselves. She presses herself against her side of the glass, while Ville Valo writhes against his reflection. He doesn't know she's there, and she doesn't know he doesn't know.  

Thus her contact is a delusion, and an artifice, but her experience of her contact is real. The band's performance is a ballet of narcicism, but it is narcicism as a proxy for empathy. The box is how art works. The box is, in fact, what differentiates art from conversation.
As I organize my job opportunities and meta-opportunities I've inevitably found myself writing a large number of variations on the same basic summary sentences about my professional interests and experience. The most succinct explanation of my "field" I've been using is "social information systems", which I like for its deliberate ambiguity as to whether I mean information systems with social components or systems for explicitly social information, since in general I'm more interested the more data and the more people involved, and most interested when there's an apparently unmanageable overload of both.  

The problem with a compact and expressive phrase like "social information systems" is that if you use it confidently enough, anybody who doesn't already think they know what it means will assume it means something specific that they don't like (otherwise obviously they would know about it already). You have to be able to put everything in some context you can count on your audience knowing, knowing they know, and knowing they like. So I end up talking a lot about "information technology", on the theory that anybody I'm likely to work for or with knows what "information" and "technology" are and thinks they're important. The "technology" part conveys that I'm not looking for a job as a data proofreader, and the "information" part helpfully suggests that I don't know anything about metallurgy or processor cooling.  

The problem with "information technology" as a phrase, however, is that it's so similar to "Information Technology", which has come to refer exclusively to that subset of information-related technology that can be hoarded by gnomes and used to build dank, gloomy catacombs where information nobody wants goes to molder and hide from the sad people who are cursed to need it. This is not exactly my niche. And worse, perhaps, information technology is not a goal, it's at best a genre of tool, and if I think goals are more important than tools, I should have some better way of talking about what I think the information technology is for, or should be. Plus I've been reading a lot of bravely humane Theodore Sturgeon stories, and I think he'd say that displacing the oppressively dreary IT, as an acronym, is worth a quest in itself.  

The main thing I'm after, always, is understanding. And since understanding is usually a process, not a point, it's more accurate to say that my preoccupation is understanding-seeking. This is probably not a usable resumé phrase in the current software business, as it sounds dubiously spiritual, and this is an audience spooked by Faith-Based Initiatives and Creationism into taking "spiritual" as the opposite of "rational". And "rational" is the same as "logical", and obviously software is quintessentially logical.  

But then, churches aren't built by devoutly instantiated reverence, they're nailed together with hammers like anything else. The difference between good software (when it ever so occasionally exists) and bad software (the rest of the time) is not usually in execution, but in inspiration. Design, as I use the word "design", is at most 20% rational (and "usability" is rarely more than 20% of that). The rest of it is spiritual, or moral, or conceptual, or whatever you want to call the part of the process in which you decide what kind of story you are helping people tell themselves about themselves, or tell others about how we share the burdens and potential of our nature.  

So I'd love to see a world where I could write in my resumé that I do US, and have people know that Understanding-Seeking is a real and definitively pragmatic discipline. I'd love to not have to explain that nudging widgets into line is a part of the software creation process I sometimes do personally in the same way that an architect who really cares about a building will still be there the day they're putting the sinks into the bathrooms, trying to think of an even better spot on the wall to hang the hand-dryers: not because that's what "architecture" means, but because if the architecture was done well, by the time you're doing the bathrooms the hand-dryers are the largest problem that wasn't already solved long ago, and it's the architect's job to keep working on the largest remaining problems until the building is done. I'd love to not have to explain to anybody that "fixing our usability" is a way of saying "we're too committed to our big mistakes to dream of anything better than doing our bad job a fraction more efficiently". I'd love to feel like I can say to a VP of Engineering that design is a moral act, and know that I'm just reiterating something they already know, that of course engineering is the art of our holding actions against entropy, and US is why it's worth so much elaborate effort to buy ourselves these moments of time in which to live.
A conversation, from the point of view of any one participant, has these three elements:  

- the source: the other participants, either as individuals or as some collective they form for the purpose of this conversation  

- the context: as simple as an explicit topic, as subtle as an implicit one, as complex as a network of human relationships  

- your role: sometimes you are yourself, sometimes you are acting in a defined capacity, sometimes you participate in a conversation as part of a collective (like an audience)  

All conversations have these same fundamental elements. At the moment, our electronic conversations are subdivided and segregated according to ultimately trivial subclasses (personal email, IM, mailing lists, newsletters, feeds, web sites themselves, innumerable other variations on alerts), and the useful tools for managing conversations are scattered across similarly (arbitrarily) segmented applications.  

The conversation tool I really want will be built on the structural commonality of conversations, instead of the disparities. I want to apply email rules to RSS feeds, feed mechanics to mailing lists, contact lists as view filters, identities as task organizers, Growl formats as cell-phone notification styles. I want my email correspondence with my mom to be at least as rich as my soccer "correspondence" with the MLSnet front page, and I want my conversation with MLSnet to be as malleable as my own iTunes song status.  

I want, I think, for all my conversations to be structurally equal. I want to be able to look at them organized by any of those elements: by source, by context or by my role, and by the unions and intersections thereof. I want to see conversations in context when there's context, and I want there to more often be far more context than a list. I want to be able to understand my side of my conversations in aggregate, and for the memberships of my conversations to be effortlessly expandable, and for my computers to remember things my head forgets, even when I can't remember whether I knew them to begin with.  

I want, of course, the whole internet redesigned with this desire at its core, but I also want approximations of this in the meantime. I want Apple Mail or GMail to stop acting like somebody invented "mailing lists" and "address books" yesterday morning. Or I want Shrook or BlogBridge to speak POP3 and IMAP as fluently as RSS and OPML. Or I want Safari to look like Apple solving a problem from their own principles rather than letting somebody else define the form of the answer, or Flock aspiring to be a social application rather than just a browser with a few extra menu commands. I want Agenda and Magellan back now that I finally have enough information to justify them.  

I want us to have the conversations we could have if we didn't spend so much time just trying to keep track of what morbidly little we've already managed to say.
The main human information goal is understanding. Or wisdom, depending on your precise taxonomy. But either way, searching is plainly a means, not an end, and the current common incarnation of Search, which involves arbitrarily flattening a content space into a set of independent and logically equivalent Pages and then filtering them based on the presence or absence of words in their text, not only isn't an end, but is barely even a means to a means. This form of two-dimensional, context-stripping, schema-oblivous, answer-better-already-exist-somewhere searching is properly the very last resort, and it's a grotesque testament to the poverty of our information spaces that at the moment our last resort is often our only resort.  

The first big improvement in searching is giving it schema awareness. I doubt the people behind IMDb spend much time thinking about themselves as technology visionaries, but IMDb Search is a wildly instructive model of what is not only possible but arguably almost inevitable if you know something about the structure of your data. IMDb presents both the search widgetry and the answers in the vocabulary of the data-schema of movies and the people who work on them, not in "keywords" and "pages", and understands intimately that in IMDb's information-space search exists almost exclusively for the purpose of finding an entry point at which to start browsing. You go to Google to "look for something", you go to IMDb to "look something up"; the former phrase implies difficulty and disappointment in its very phrasing, the latter the comfortable assumption of success.  

On the web at large, of course, there is no meaningful schema, and it's impossible to make any simplifying assumptions about the subject matter of your question before you ask it. It is more productive to search in IMDb than with Google not because IMDb's searching is better, but because its data is better. But this does not even fractionally exonerate Google, or anybody else who is currently trying to solve an information problem by defining it as a search problem. They're all data problems. Google has the hardest version of this problem, since they don't directly control the information-space they're searching, but they have more than enough power and credibility to lead a revolution if they can muster the vision and organization. And anybody building an "enterprise" search tool has no such excuse; the enterprise does control their information-space, at least out to the edges where it touches the public space, and every second that can be invested in improving the data will be at least as productive as an hour sunk into flatly searching it.  

So if I worked for a Searching company right now, I'd start madly redefining ourselves tomorrow. We are not a searching company, we are an information organization company. The last resort is necessary, but neither sufficient nor transformative. I'd pull the smartest people I had off of "search" and put them to work on tools for the other end of the information process, reaching to the humans who are creating it and giving them the power to communicate not just the words of what they know but the structure of it, and to the collective mass of people to help them communicate and recognize and refine their collective knowledge about the schemas of known and knowable things. This is why Google Base holds the future of Google, and why you should sell your Google stock right now if they keep treating it as mainly a way for someone to buy your unused exercise equipment from you using a credit card. It should be the world's de facto public forum for the negotiation of the schema of all human knowledge, and if it isn't, every other decision Google makes will be forced by whatever is.  

But well-structured data, though necessary, isn't sufficient either. The good news for "search" companies is that improving the data is itself just a means to an end. Ideal data only encodes what we already know. The problems of useful inference from known data are hugely harder and super-hugely more valuable than the current forms of searching, especially when you realize that the boundary between private and public data is an obstacle and an opportunity in both directions not a wall to hide behind or run away from. The real future of "search" is in providing humans with the tools to form questions that haven't already been answered, and assemble the possible pieces of the answer, from threads of reasoning that traverse all kinds of territories of partial knowledge, into some form that synthesizes ideas that have never before even been juxtaposed, and onto which humans can further apply human powers where machine powers really fail -- fail because the machines are machines, not where they fail because we didn't take the time to let them be more thoroughly themselves -- so that they in turn can help us be more completely and wisely human.
I think it is becoming painfully clear that the web suffers from at least two critical design flaws, one of structure and one of usability.  

The usability flaw is the omission of real tracking and monitoring from the original browsing model. The "visited" link-state is no substitute for true unread marks, and HTTP response headers are not adequate building blocks for functional monitoring.  

RSS, born out of various motivations, is turning most coherently into a retrofit tracking/monitoring overlay for the web. My conversation with a feed is qualitatively poorer in context (and potentially in content) than my conversation with a web site, but it's qualitatively more manageable. The feed tells me when there's something new, and what it is, and lets me keep track of my interaction with it.  

This dynamic should have been built into the model from the outset, because without it the whole system does not scale in use. Providing it as an overlay, and a whole parallel information channel, is idiotic in every theoretical sense, but its pragmatic virtue is that a separate system can be built with far fewer technical and social dependencies.  

And while RSS is still nowhere near social critical mass among human information consumers, it is approaching a viable critical mass as a geek technology, and we will thus be increasingly tempted to lapse into thinking of it as a goal in itself, rather than a means. Witness, most glaringly, the fact that so far nobody, not even the people writing RSS-aware web-browsers, has attempted to use RSS to solve the original problem, which is making sense of the contents of a web site, not from it. And witness, almost as gallingly, the fact that we're pretending to think there's a future to the network model in which every reader is individually polling every information source every few minutes.  

In content, the same time-wasting cycle is going to replay in RSS that played in HTML: the new channel is initially lauded by sheltered tech geeks for freeing the "real" content from all the crap that used to surround it, and then quickly retaken by the forces of reality, which understand the commercial point of "all the crap". So ads and context will creep into feeds, and before long the content of RSS items will start to reproduce the whole experience of the originating web site, and there will no longer be anything streamlined or usably universal about the content of a feed.  

In scalability, the whole thing is just going to implode, or become horrendously convoluted as people scramble to patch over the network problems with proxies and collective batching.  

Of course, if we're going to have to rebuild the whole web for structural reasons, rebuilding the tracking/notification overlay on the current web is a throwaway project, but that doesn't mean it isn't worth doing, and it certainly doesn't mean somebody won't try to do it.  

If I were working for Microsoft or Apple right now (or, in theory, on Mozilla, but I'm not sure this can be done without corporate-scale backing), I'd have my R&D people putting serious work into treating RSS not as a content channel but as a source of the necessary metadata to build monitoring and tracking directly into the browsing experience. Forget trying to "teach web users about feeds", they shouldn't have to learn or care. Build the monitoring/tracking stuff around and into the browser where the user already lives and reads.  

If I were working for an infrastructure company, like Google or Akamai or maybe IBM, I'd have my R&D people hard at work on standards proposals and proof-of-concept prototypes for a cogently bidirectional subscription/syndication protocol that sends messages from the consumer to the source only when the consumer's interest changes, and from the source to the consumer only when the information changes. Quantum-leap bonus points for subsuming old-style email/IM messaging and web-browsing itself into the same new protocol. These are all most essentially conversations.  

And in the meantime, if I were working on any kind of RSS/OPML-related application, I would take a day or two to stop and think about my goals, not in terms of today's syntaxes but in terms of the flow of information between human beings, and between machines as our facilitators. I'd want, and maybe this is just me, to be working on something that not only improves the lives of people using the imperfect tools it has to work with right now, but would improve the lives of people even more efficiently if the world in which it operates were itself improved. Sometimes a broken window demands plywood, but as a tool-maker I dream of making something you won't just throw away after this crisis passes.  

(Of course, the deeper and ultimately more costly of the web's two design flaws is the structural mistake, which is the original decision to base HTML on presentation structure, rather than content structure. This is a monumental tragedy, as it has resulted in humanity staging the largest information-organization effort in the history of the species, and ending up with something that is perversely and pathetically oblivious to how much more than screen-rendering engines and address resolvers our machines could have been for us. In building this first unsemantic web we may well have thrown away more human knowledge than we've captured, and now we're going to have to build the whole thing over again, more or less from scratch, against the literally planetary inertia of our short-sighted mistakes.)
[An idea arising (or maybe coalescing) from a conversation with Pito Salas of BlogBridge about "feed remixing".]  

Del.icio.us/popular and Digg, at the moment, produce feeds and are probably heavily fed by people who read feeds, but still rely on a workflow that requires browsing: I read something interesting in one of my feeds, I go to the web page it represents, I bookmark/Digg that web page, a bunch of people do the same, and when it crosses some threshold of popularity it hits del.icio.us/popular or the Digg front page, or whatever. Those pages in turn then generate feeds, which I read. This flow makes excellent sense if I want to bookmark the thing persistently, or I want to annotate my bookmarking of it, or participate in a discussion about it. But sometimes all I ever want to do is read it and pass it on.  

Maybe there should be a way to simply bypass the browsing stages. When you read something interesting in a feed, you could Figg the feed article itself. Your stream of Figged articles from all your feeds forms a new personal compilation feed, and those personal feeds are then aggregated and collated, and the most popularly Figged articles appear in a collaboratively generated new feed. This is just a flow, so it would be my recommendation to leave persistence and annotation and tagging and commentary all to the other model. Keep it to a single function requiring no other per-action parameters, whose output is just a normalized feed with articles uniquely IDed by source. The aggregation could either be centralized (i.e., as a service that also provides hosting for the personal feeds), or decentralized (you host your own personal feed, and just register it with the aggregation service).  

Note that I'm not claiming this is a business idea, nor do I even think it's a durable idea in structural terms. It won't surprise me much if feeds, in their current form, go straight from early-adopter obscurity to being obviated or subsumed or reintegrated back into a new form of browsing. But for now these possibilities are part of this idea's appeal -- for a little while the technology of feeds still happens to define a community and an audience, and Figg could be the ultimate insiders' channel.  

[If the main point of this is single-click-ness, it would require blog-reader integration, but several RSS readers already have Blog-This functions, and this would be simpler.]  

["Feedmarking" would have been a great name for this idea, but that term is already being used to talk about the marking/tagging of feeds. Of course "bookmarking" was originally the marking of pages within books rather than the marking of books, but on the web this distinction doesn't exactly hold.]
Despite spending my weekdays designing web software since pretty much the dawn of the web, I've only ever constructed a whole web site for myself, and I've only done that using my own deliberately self-centered and exploratorily minimal tools. At the moment this site is running on a Perl+XML system that would qualify as "content management" only with the liberal application of asterisks. In its exact current state it is a random combination of me-specific hacks I didn't feel like generalizing, over-generalized partial architectures of things that my own site's small scale doesn't really require, and I guess at least a few sensible compromises between the two. The system is not a product, and I don't really aspire to turn it into one, but I'm a product designer by trade, and so tend to gravitate towards product-designer-ish solutions.  

I've also never been a web freelancer, and I've always been pretty sure that freelancing wouldn't suit my personality particularly well. I prefer generalizable problems to the inherently individual, I like the challenge of adapting moral imperatives to evolving contexts and constraints more than constantly starting over at the beginning, and I really like having some control over the kind of work I'm doing.  

But that doesn't mean I'm not curious, and in my at-least-temporary unemployment I have the chance to experiment, and a friend of mine who does freelance design has a project for which he needs a developer. And, intriguingly, the structure of the site he needs to build is more or less the same as this one: a few sections of static content and a couple streams of dynamic stuff.  

Actually, perhaps even more importantly, the client's site is smaller than mine. Fewer pages, fewer bytes, fewer moving parts, probably even fewer visitors. More revenue, I hope, but none of it directly transacted by the site. So while my system is of vastly unproven scalability, I'm pretty confident in its ability to scale smaller than its one existing deployment.  

But "scalability" is actually a vector of variable orientation. I've written an outline of the implementation plan and a full schedule of task-time estimates before we finally stop and think about what we're doing. My system is streamlined in ways that are arguably clever, but in service of my goals and habits and assumptions. I am willing to write my own code to produce exact quirks of behaviour, and conversely would rather have simple behavior under my complete control than complexity that depends on other systems and constraints. I don't have to anticipate where I can adapt. I don't mind editing XML files by hand. I embrace informed incompatibility. I want a work in constant progress. I am a designer of large systems produced by large teams in my work life, and this is my other-extreme small system for the smallest team.  

My friend's client, on the other hand, is a chicken breeder. I don't mean this metaphorically, I mean they're a company that breeds chickens. Their web site, when it's done, will have background information, breeding statistics, news and announcements about their breeding of their chickens. I am quite prepared to believe, after looking through the source material for the site, that they are every bit as diligent about chickens as I am about information. And, vice versa, I would care about chicken breeding as long as it took me to build their site, and they would care about web design as long as their site never really required them to.  

So while I could build their web site, they could probably cook me a chicken dinner. I deal in information structure first, and the structure of chicken-breeding information is not complicated. They deal in predictability and consistency, and if you can breed chickens you can probably follow a recipe.  

But there are people who cook for a living, and people who make web sites like this for a living, and there are excellent reasons to let them. Fiddling with my site when I feel like it is a pleasure. Fiddling with theirs in a sudden crisis would be annoying for me and for them. My system is designed in anticipation of a future in which my software environment may change in a hundred ways, but I will always be me. Theirs should be built in almost exactly the opposite way, assuming that techs and admins and data-enterers and freelancers will change but the software will stay the same. A commercial content-management system is intolerable overhead and point-missing premature closure to me, basic foundation and the first step towards maintainability for them.  

So I'm not doing the site. We had fun imagining how we might have, probably me more than my friend, since I'm not billing for my time, and at the end of this he still has to find someone to build him a chicken breeder's site the right way. I got some ideas of new things to play with here on my own site, he got a couple ideas about streamlining their navigation and using tagging to filter news by audience. And I don't know whether this means I'll never be a freelancer, but I have a clearer idea of what oddities a project would have to entail to lend itself to my odd tools.  

And I am reminded, most usefully, that the most critical constraints on your solutions are not your capabilities, but the capabilities of the people whose problems you are trying to solve. As a tool collector and maker of tools for making tools, you are allowed to fill your own workshop with lopsided automata and non-Euclidean corners and puzzle-joins and secret panels; but when you're building for people who only ever want to have to own a hammer, you better stick to nails.
Site contents published by glenn mcdonald under a Creative Commons BY/NC/ND License except where otherwise noted.