furia furialog · Every Noise at Once · New Particles · The War Against Silence · Aedliga (songs) · photography · other things
3 February 2006 to 18 January 2006
My yearly statistical service to the music-critic community is up, with numbers just re-done this morning to take into account some corrections in the source data.
Here's how bad the spam problem has become: my kittens are getting spam.
Here is my favorite current example of a good bad internet business idea. My wife and I have a number of friends with whom we often get together for variously collaborative dinners in various permutations of availability. Nearly everyone has some kind of eating preference, and several of our friends have menu-changing physical or moral constraints like wheat allergies, lactose intolerance and levels of vegetarianism. Keeping track of all the personal variables and their interactions is hardly impossible, but neither is it trivial.  

DinnerPeace, then, would be a web-based eating-constraint resolution service. Each participant specifies their own food rules, the dinner's host selects the guests for a specific event, and the service automatically combines the guests' needs to produce a composite constraint profile for the evening's menu.  

Later versions might add invitations, recipe-database integration ("I've got these eight people, a lot of spinach, and a good sale on Alaskan salmon; give me some suggestions."), pre-event/potluck planning discussions, post-event notes and recipe-sharing, and historical context ("Oh, and I don't want to make anything I already made for any of these people before.").  

As a stand-alone business this is a fairly dismal idea. Users won't be willing to pay much, if anything, for what is at best an appealing minor convenience. Food-related advertisers might be interested, but the only ones really likely to benefit would be grocers local to the people preparing dishes, and there probably won't be a critical mass of participants in any given locality, soon or ever.  

More significantly, though, an independent service is simply the wrong model for the idea. It requires the builder to provide and maintain all the framework of a generic social service (notably member- and discussion-management), and requires the users to join another thing, keep track of another set of credentials, and of course provide a bunch of information whose privacy they have to consider, and which is unlikely to be reusable in any other parallel or future venue.  

The biggest jump-start for building little good ideas like this would be a pre-existing public infrastructure for distributed identity management, with portable authentication, ratification of trust, communication uniqueness (that is, your new managed identity is sufficient contact information for IM, email, etc.), arbitrarily extensible personal profiles, integrated personal past-and-future calendar-handling and straightforward control over what information is exposed to whom. This needs to be at least as easy and ubiquitous as email is already. In the new world, in fact, this (and not just email) needs to be the new baseline for online presence, in the same way that the baseline for telephone presence grew from home-phone to home-phone+answering-machine to home-phone+remote-messaging to cellular.  

This new baseline identity system would get DinnerPeace and everything like it (including much bigger things with ultimately the same structure) out of the commodity headaches of name arbitration, password resetting, access control, scheduling, elemental data-storage, history, recovery, etc., and leave each inventor to put all their work into their idea's unique characteristics, which in the case of DinnerPeace are really only a reference schema and vocabulary for the representation of a person's eating constraints, and the associated reconciliation logic for sets of these constraints and their histories.  

The business problem may be a little harder than the technical problem, but it is of the same shape. Along with the new identity system must come a distributed microcommerce system of which ad-click commissions are only the distant ancestor, their replacement being much closer to a pervasive method of tracking and apportioning credit for all the influences on each spending event, including the new possibility of tipping as a networked and optionally aggregated act.  

Thus DinnerPeace, and all the other little pieces of a smarter new world, mostly shouldn't need "business plans" in the old sense, nor investors or funding or stock or even companies. They shoud live or die or evolve based on their usefulness, and profit or not based on how much commerce they touch. DinnerPeace should generate one little trickle of money from how it affects what its users buy, another from its users' direct gratitude, and a third from its share of its users' collective appreciation of all such services they employ. This money flows in outgoing trickles, in turn, to the contributors to the service's logic.  

Probably the trickles from one idea usually don't add up to a living for even one person, let alone several, but then most of the little ideas from which they flow are not life's works, either. They are inspirations of moments, and the work of hours or days. The new world is improved by little touches, and rewards them with little gifts. And if it becomes less compelling to dream of retiring on windfalls of luck or greed, then maybe it will become easier to live by caring.
[Postscript to Content and Presentation Are 3...]  

Arguably the most fundamental specific semantic failing in the current HTML approach to information communication is that it does not effectively distinguish between a) content unique to the individual information node represented by the page URL, and b) navigation and context appearing on the same web page but belonging conceptually to a higher containing node. Thus, most obviously, indexers have no way to reliably attribute text-matches or links to the correct node. Less obviously, perhaps, this makes it difficult for reading software to easily recognize that two URLs present the same content in different contexts, which is currently the shape of quite a bit of content abuse, or different content in the same context, which at this point is probably the shape of most legitimate web information. The real solution still lies in separating content structure and presentation structure, but a microformat-style approach might help a lot in the interim.  

PPS: There is also currently no good method for separating the content and context components of a URL, either, meaning there is often no user-visible URI for the content node itself. This may be moot most of the time in the new world, since content will either have a context imposed upon it or will invoke its own default context. But standardizing URL formats in the short-term may be even harder than standardizing class-based pseudo-semantics...
See if you can spot the production step the makers of this litter scoop forgot.  


I would also like to see the paperwork for the "patented handle".
Lincolnville: Heavenly Calm (1.3M mp3)  

Because I was revisiting the C section of my shelves today...

Old South Meeting House, Boston (basement, morning)  

Gerrish Island, Maine (ground floor, evening)
At the moment, the tools for online publishing were mostly designed by software people for an audience of other software people, so it shouldn't be too surprising that by real (i.e., pre-/non- online) publishing standards most of them are not only fairly terrible in particulars, but basically comprehensively alien and unresponsive down to the conceptual model.  

The reason the HTML-tables-vs-CSS-blocks war wasn't over ten minutes after CSS was invented, for example, is that the CSS float/span/margin/escape model chose (more in ignorance than defiance, I'm sure) its own internal geometrical cleverness over the potential applicability of centuries of conventional information design. The most basic tool of scalable information design is and has always been the layout grid. CSS is capable of producing a simple layout grid, but not simply. Arguably it's even harder to recognize a page layout by reading its CSS than it is to write the CSS. Structural elements are structural by convention if you're lucky, coincidence if you aren't, and certainly not by nature, and are unavoidably cluttered by non-structural formatting elements.  

An HTML table isn't a good tool for page layout, either, but for the most part a simple layout grid can be expressed by a simple HTML table, and with decent code-indentation it is possible to more or less grasp the presentation structure of a simple table by looking at its code. The fact that tables require the content and the structure to be intertwined is a huge problem, and the fundamental misconception of the scheme emerges the moment any kind of table-nesting is required for page-structural and/or content-structural reasons. The non-programmer's mental model of a box is an actual box. You can put small actual boxes inside larger ones. If you forget to put a bottom on a small box inside a large box, you get a bottomless small box inside a normal large box, not a deformed small box falling out of the bottom of a mangled large box. Nobody, not even a programmer, intuitively thinks of object construction procedurally, and nobody but a programmer (and not most of those) would want to.  

Ironically, painfully, the closest thing in current web technology to simple modeling of simple presentation structure is technically the most flawed: frames. I would recommend their use for almost no public purpose, and frameset code is no pleasure to look at, either, but at least frame definition is separated from content (too separated, in fact, but separation is still a good idea), and its grammar operates by explicitly specifying structure from the outside in (with recursion, albeit awkwardly), rather than calculating it by implication from the inside out. If frames had been defined as page (and sub-page) elements pre-declaring layout structure, rather than window elements that contain content pages by reference, we might have had something.  

While we're redoing the layout model, though, we also need to fix our basic misunderstanding of the natural structure of repeatable content presentation. Any remotely enlightened programmer "knows" that content should be separated from presentation, but these are actually three things, not two: content, presentation structure, and actual formatting, and in practice the formatting can usually be further separated into content formatting (the formatting of the information unique to this content node) and page layout (the site-identity and navigation and other framing stuff displayed around it but conceptually invoked from context).  

Take this furialog entry itself, for example. Its content structure includes a title, a display date, a publication timestamp, a set of tags and a content block. This content structure is then mapped into a presentation structure for this web page which is quite a bit simpler: just a header and a body. The title, display date and tags are concatenated into a single formatted block for presentation purposes, and the timestamp is not (in this format) presented at all. The formatting rules, then, are applied to the presentation structure, not the content structure. This is important, because elsewhere on this site content with very different content structures gets mapped into the same presentation structure, subject to the same formatting rules, and thus it is possible for me to define a single rule-set that drives the middle layers of the production of all my content, a single page-layout that drives the outer layers, and appropriate extensions to which the sub-formatting of special-purpose inner blocks like tables and photosets can be delegated.  

The usefulness of RSS, similarly, is largely due to the fact that it defines a common presentation structure into which dissimilar content structures may be mapped. Different feed sources may put semantically different and/or compound information into the title and description fields, but the writing software doesn't have to know or care about the formatting rules, and the reading software doesn't have to know or care about the content structure. The drawback of using presentation structure as an interchange medium, of course, is that the reading software can't get the original content structure even if it could do something interesting with it. Human readers can re-interpolate it, but for the machines RSS tends to be lossy.  

This was also, maybe obviously, the original design concept for HTML: standardize a presentation structure that can then act as universal intermediary between content and screen. RSS gets away with its limitations because it's an alternate channel, but as the web emerged, HTML was the web, and universal intermediation quickly proved unsatisfying in both directions: writers couldn't exercise enough control over formatting when they needed or wanted to (and programmers often assume "want" is always the right word here, but publishers understand that publishing is different than just writing), and machines couldn't add enough processing insight without finer-grained and/or domain-specific data schema.  

Here, then, are some of the elements of the new model I want, some of what, from twenty years of working with information in both publishing and software spheres (and this isn't what I thought after ten, so maybe it won't be what I think after forty, but is that because I change, or because the world does?), I believe the whole system needs in order to fulfill its potential as a medium at once for direct human communication and human understanding supplemented by computer reasoning:  

- Not only should all meaningful content begin in its own schema, but this machine-parsable content structure should, inherently and automatically, underlie and accompany the human-visible presentation and formatting of all information. Imagine, if this were our only problem, adding an Elemental XML section to every HTML page, so that each page would carry its pre-presentation data in addition to all of its other markup, and splitting the View Source command into View Presentation Code and View Source Data to offer different tools for each. (Microformats are a similarly motivated effort, establishing presentation-structure conventions for particular kinds of content structure, but conflating the two kinds of structure is only reasonable as a short-term tactical compromise in a system where there's no good way to separate them, anyway.)  

- The mapping of content structure into presentation structure must be so trivially easy, and such an obvious entry into a richly distributed universe of sophisticated standard lexicons and templates, that nobody will even be tempted to try to skip the step by pretending that their content doesn't have any other structure than its presentation. Imagine, as you're publishing something, that you could chose dynamically from not only your own repertoire of formats and the templates provided by your authoring software, but from a social universe of templates, of all granularities, available from anyone who has one to offer. The laborious specific control of your own formatting, or the flexible custom extension of your presentation structure, should be optional opportunities for the motivated, not required burdens of participation.  

- The layout model should be based on recursive containment from the outside in (probably with layers, for graphic depth). Exceptional behavior, like violating margins, must be declared explicitly, not arise from routine errors in normal use. It should be trivial to map one element of presentation structure into one formatting container, to flow multiple elements of presentation structure into one formatting container, or to flow one or more elements of presentation structure through an arbitrarily linked series of formatting containers. We've learned a lot about UI and usability since Quark and PageMaker were invented, and not everything we ever wanted to do in books and magazines applies the same way on a screen or in an interactive environment, but in many ways the screen world is only now approaching the point where print was before computers, so as is already beginning to sink in about typography, more old lessons apply than not.  

- Where the new medium has new abilities, our tools should be granting new powers to us, not demanding new chores. AJAX is a clever retrofit of what should have been a native idiom. Forget paging vs scrolling, Google Maps is how everything offscreen should work, the computers dealing with computer constraints like bandwidth and memory without bringing people into issues that don't concern people. And if content were encapsulated intelligently, it wouldn't take Flash or iframes or scripts to make a piece of a page do things a whole page can already do. The web is a bad application environment kludged onto a bad publishing environment, and it ought to be a composite environment in which publishers realize that sometimes they are publishing applications and experiences and devices, not just pictures and words.  

- The separation of content, presentation structure and formatting is necessary for everyone's purposes, not just the auteurs and the programmers and the machines. Good, reusable, maintainable presentation design, even when it's done by dedicated designers, should always work first from presentation structure to formatting rules. The handcrafting of individual exceptions should be an elaboration on a framework of rules, not a repetitive substitute for making the effort to understand patterns. I see way too much CSS code that specifies individual pixel-unit fonts and margins and paddings for every single id-numbered div in an entire page (or, worse, for every id-numbered div in a whole set of pages, so that the style-sheet can be "reused" across all of them). Sometimes this is a result of having misused the (X)HTML to model the content structure, rather than the presentation structure, so that the formats and the selectors don't line up right, but I bet it's more often just laziness. It's always faster to add a pixel than to generalize a rule about why, but it takes an incredibly tiny number of exceptions to complicate a rule-set so irretrievably that it can only be modified by further exceptions. For all but the rarest purposes where chaos is the order, the fewer rules the better, and the square of the fewer exceptions the better.  

But fine. No matter what you credit as partial precedence, ubiquitous electronic publishing and communication as social infrastructure are at best in their adolescence, and it's amazing we've gotten this far with these primitive tools. The willingnesses to restart and rebuild are in our character, just as surely as myopia and impatience are our curses. Generations are how we learn.  

So yes, this means starting over, but the new ways, when they're right, are easier than the old ones, and we only shrink from them out of fear of change. In place of the current HTML/CSS information foundation we will have data (content structure), mapping (content structure to presentation structure), page layout (the containers through which the presentation structures flow) and formatting (typography, color, spacing, ornamentation and illustration within those containers). Any of these can be implied from defaults (set by the reader, writer or both), included by reference to external sources, included by recursion, included conditionally by context, or defined inline. Most of this will still be mediated by tools for most people, but the tools will be simpler and more powerful, and will let us focus more on what we're saying to each other, and less on how.  

And since the new way delivers both the formatting and the semantics, this will be a practical revolution that actually subsumes a theoretical one, better human communication interleaved with better machine communication, and thus the foundation for both better shopping and the dream of the internet being something qualitatively more profound and transformative than shopping.
Hundred Reasons: Lullaby (from Shatterproof Is Not a Challenge) (1.7M mp3)  

First up in my morning-commute shuffle, and apparently exactly today's mood. I discovered Hundred Reasons in a tour listing when they were opening for Idlewild, and they have remained in my affection long after I've given up on most of the shouty bands I recognize as generally similar. I think, as with Jimmy Eat World (and as songs begin in shuffle I have more than once confused the two), there is some essential core of sadness that makes even the most bellowing moments plaintive instead of merely loud.  

There are demos of new stuff up on their site.
Site contents published by glenn mcdonald under a Creative Commons BY/NC/ND License except where otherwise noted.