24 May 2006 to 13 April 2006
¶ public and private · 24 May 2006
Two notes of rather different kinds:
- I'll be at BarCampBoston in Maynard on June 3/4. I haven't been to any unconferences before, so I don't have any guess at how successful this one might be, nor even exactly what the criteria for success are, but it's free and it's experimental, and if it turns out to be interesting I'll be sure to brag about having been at the first one.
- Bethany has finally given in and started a blog, called rantum scoot, and her desire for feedback has overcome her public reticence, so she said it's OK for me to mention it now.
- I'll be at BarCampBoston in Maynard on June 3/4. I haven't been to any unconferences before, so I don't have any guess at how successful this one might be, nor even exactly what the criteria for success are, but it's free and it's experimental, and if it turns out to be interesting I'll be sure to brag about having been at the first one.
- Bethany has finally given in and started a blog, called rantum scoot, and her desire for feedback has overcome her public reticence, so she said it's OK for me to mention it now.
¶ Aspects and Orders · 20 May 2006 essay/tech
Although I'm not at all sure this is factually fair, I have begun to mentally, and maybe emotionally, blame Flickr for what feels to me like a plague of subject-oblivious square photo-cropping.
I should admit, I guess, that when it's me operating the camera, I'm a pretty extreme horizontalist. I'm happiest at about 3:1. In a tool universe built around 4:3, though, this is kind of a pain in the ass. I could mask my camera's LCD for 3:1 feedback, but then the picture is really too small to work from. For online display I have to assume 4:3-ish frame spaces, so 3:1 images end up in practice being shorter instead of wider, which is unsatisfying. And digital cameras will have to pack a lot more pixels into 4:3 sensors before I'll be informationally content to throw away more than half of them. And my obsessive preference for aspect-ratio consistency in exhibition sets means that I would usually rather stick to 4:3 for everything than mix in the occasional 3:1 where I spot an opportunity despite the obstacles.
So I understand, of course, the value of square-cropping in any content-neutral photo-showing application. It's possible to do an attractive job of mixing aspect-ratios, but it's exponentially easier to do an even more attractive job of displaying consistent aspect-ratios. Cropping 4:3s and 3:4s to 1:1 symmetrically is technically trivial, and although it's aesthetically unreliable in the abstract, the vast majority of amateur photographs are center-weighted, so it usually turns out OK. Actually, the vast majority of amateur photographs are also probably framed too widely, so a little universal symmetrical cropping almost certainly improves more Flickr pictures than it damages.
So cropping all pictures to squares for thumbnailing makes perfect sense as a Flickr design decision. It simplifies away arguably the biggest visual design problem in mass photo display. If you're looking at somebody else's photographs, it's easy to fall into assuming they are square, so any weirdness in framing you're likely to implicitly attribute to the photographer. The same applies to your own photographs unless you've spent some time seriously considering the originals, and the more you use Flickr, the more it is the way you consider your own photographs en masse.
But if your exhibited photographs are usually going to be approached through thumbnail galleries (the prevalence of which Flickr has also hugely influenced), and the thumbnails are usually going to be squares, it will simplify the rest of the experience if your photographs actually are square. I don't know if any digital cameras are already shipping with built-in square-cropping modes, but I expect those to start appearing very soon if they haven't already. The more square photos people have, the more display-tools will cheat and optimize for them, and the more incentive there will be to be square.
But square is a bad base ratio for photography, at least if by "photography" we mean people taking pictures of things people see, for other people to later share (or imagine) the experience of seeing. We see our world horizontally. Our eyes are side-by-side, our lives are gravity-flattened, our emotional landscapes are literal landscapes as often as metaphorical. My 3:1 fetish may be extreme, but I'm pretty sure that if you take photographs on their own terms, humans instictively respond more positively to wide aspect-ratios. The standard terms are actually telling: "landscape" refers to the subject of the picture, "portrait" to the act of picturing it. We can appreciate photographs in all sorts of shapes, but we can empathize with seeing most readily when the shared vision is the shape of experienced vision.
So this self-reinforcing dependent vogue for square photography is, I think, a machine gain and a human loss. Worse, it's a sparkly machine-gain that humans are lining up to lose. Machine gains are almost always sparkly, if only because it's far easier to polish a working machine than it is to figure out the machine you should have built instead, or admit that it was better, even if it was harder, to do something by hand. And we form machine-polishing clubs, and start companies to make machine polish, and open shops to sell it, and years go by before we stop and think about the flaws in which we've become invested.
So too with this idiotic chronology-switchback setup we've tempoarily settled on for blog formats. The right way to read incremental written forms, beyond any vague doubt, is in serial order. You start at the top of the first entry, you read to the bottom, and then the top of the next entry should follow the bottom of the previous one. Thousands of years of usability research has validated this basic design.
All of which was summarily and obliviously ignored by the original engineers of HTML and web browsers, with the result that they neglected to provide a simple and reliable mechanism for one absolutely essential bit of visual behavior: a fixed identity header and indepdently scrollable/pageable content. Without this, a designer of serial content can have identity reinforcement (come into the page at the top) or currency (come into it in the middle, where the new content starts), but not both. And since they didn't build in any meaningful tools for handling the user-subjectivity of "current", identity basically wins by forfeit.
The reverse-chron blog format is a sparkly-machine solution to this problem. It puts the newest entry next to the identity, thus at least superficially addressing both goals at once. For every other purpose, though, it's actively reader-hostile. If the entries form any kind of overall narrative, you have to read it in a painful zig-zag. If you are following a blog and miss a single update, you have to use the same awful up-and-down to find where you left off, read down, scroll back up, read down, repeat. This is bad.
But it's bad in what has become an established way, so even if you don't believe the alternatives are worse on their own terms, they almost certainly become worse in public practice. As with square photographs, we make our tools in the easiest shapes, and then we accomodate their limitations, and then we hone them to perfect their limits, and then we forget that this is not how we wanted to live.
Next time you make a crude tool, don't polish it, and don't accomodate its limitations. Use it the way you wish it worked, pay attention to how that hurts, and then throw it away and try to make the next crude, unsparkly tool so that using it doesn't make the tool better, it makes us better.
I should admit, I guess, that when it's me operating the camera, I'm a pretty extreme horizontalist. I'm happiest at about 3:1. In a tool universe built around 4:3, though, this is kind of a pain in the ass. I could mask my camera's LCD for 3:1 feedback, but then the picture is really too small to work from. For online display I have to assume 4:3-ish frame spaces, so 3:1 images end up in practice being shorter instead of wider, which is unsatisfying. And digital cameras will have to pack a lot more pixels into 4:3 sensors before I'll be informationally content to throw away more than half of them. And my obsessive preference for aspect-ratio consistency in exhibition sets means that I would usually rather stick to 4:3 for everything than mix in the occasional 3:1 where I spot an opportunity despite the obstacles.
So I understand, of course, the value of square-cropping in any content-neutral photo-showing application. It's possible to do an attractive job of mixing aspect-ratios, but it's exponentially easier to do an even more attractive job of displaying consistent aspect-ratios. Cropping 4:3s and 3:4s to 1:1 symmetrically is technically trivial, and although it's aesthetically unreliable in the abstract, the vast majority of amateur photographs are center-weighted, so it usually turns out OK. Actually, the vast majority of amateur photographs are also probably framed too widely, so a little universal symmetrical cropping almost certainly improves more Flickr pictures than it damages.
So cropping all pictures to squares for thumbnailing makes perfect sense as a Flickr design decision. It simplifies away arguably the biggest visual design problem in mass photo display. If you're looking at somebody else's photographs, it's easy to fall into assuming they are square, so any weirdness in framing you're likely to implicitly attribute to the photographer. The same applies to your own photographs unless you've spent some time seriously considering the originals, and the more you use Flickr, the more it is the way you consider your own photographs en masse.
But if your exhibited photographs are usually going to be approached through thumbnail galleries (the prevalence of which Flickr has also hugely influenced), and the thumbnails are usually going to be squares, it will simplify the rest of the experience if your photographs actually are square. I don't know if any digital cameras are already shipping with built-in square-cropping modes, but I expect those to start appearing very soon if they haven't already. The more square photos people have, the more display-tools will cheat and optimize for them, and the more incentive there will be to be square.
But square is a bad base ratio for photography, at least if by "photography" we mean people taking pictures of things people see, for other people to later share (or imagine) the experience of seeing. We see our world horizontally. Our eyes are side-by-side, our lives are gravity-flattened, our emotional landscapes are literal landscapes as often as metaphorical. My 3:1 fetish may be extreme, but I'm pretty sure that if you take photographs on their own terms, humans instictively respond more positively to wide aspect-ratios. The standard terms are actually telling: "landscape" refers to the subject of the picture, "portrait" to the act of picturing it. We can appreciate photographs in all sorts of shapes, but we can empathize with seeing most readily when the shared vision is the shape of experienced vision.
So this self-reinforcing dependent vogue for square photography is, I think, a machine gain and a human loss. Worse, it's a sparkly machine-gain that humans are lining up to lose. Machine gains are almost always sparkly, if only because it's far easier to polish a working machine than it is to figure out the machine you should have built instead, or admit that it was better, even if it was harder, to do something by hand. And we form machine-polishing clubs, and start companies to make machine polish, and open shops to sell it, and years go by before we stop and think about the flaws in which we've become invested.
So too with this idiotic chronology-switchback setup we've tempoarily settled on for blog formats. The right way to read incremental written forms, beyond any vague doubt, is in serial order. You start at the top of the first entry, you read to the bottom, and then the top of the next entry should follow the bottom of the previous one. Thousands of years of usability research has validated this basic design.
All of which was summarily and obliviously ignored by the original engineers of HTML and web browsers, with the result that they neglected to provide a simple and reliable mechanism for one absolutely essential bit of visual behavior: a fixed identity header and indepdently scrollable/pageable content. Without this, a designer of serial content can have identity reinforcement (come into the page at the top) or currency (come into it in the middle, where the new content starts), but not both. And since they didn't build in any meaningful tools for handling the user-subjectivity of "current", identity basically wins by forfeit.
The reverse-chron blog format is a sparkly-machine solution to this problem. It puts the newest entry next to the identity, thus at least superficially addressing both goals at once. For every other purpose, though, it's actively reader-hostile. If the entries form any kind of overall narrative, you have to read it in a painful zig-zag. If you are following a blog and miss a single update, you have to use the same awful up-and-down to find where you left off, read down, scroll back up, read down, repeat. This is bad.
But it's bad in what has become an established way, so even if you don't believe the alternatives are worse on their own terms, they almost certainly become worse in public practice. As with square photographs, we make our tools in the easiest shapes, and then we accomodate their limitations, and then we hone them to perfect their limits, and then we forget that this is not how we wanted to live.
Next time you make a crude tool, don't polish it, and don't accomodate its limitations. Use it the way you wish it worked, pay attention to how that hurts, and then throw it away and try to make the next crude, unsparkly tool so that using it doesn't make the tool better, it makes us better.
The Boston-based photo-sharing site/service Tabblo just opened for public beta-testing, and I did a writeup about it for BostonWTF.com.
¶ Jim · 5 May 2006
Jim Moran completed his life last night. His doctors said he had four months left last July, and he decided to take ten instead. He was entirely himself right up to the very last days, and died at home with people who love him. Metastasizing cancer is an awful way to end, but now I know how much grace and dignity can be imposed on even that much awfulness.
I don't think Jim ever did use the walker they brought over for him a couple weeks ago, and I think he only agreed to the wheelchair that arrived last week because he could push it around with his eyes closed.
We opened the windows one day last weekend when it was nice out, so he could hear the birds in the trees outside his second-story window. I thought I spotted him inching the chair towards the door. I told him I was sorry that the wheelchair couldn't take him outside. He didn't say anything for almost long enough that I wondered if he'd heard. But then he opened one eye a little, peered at me skeptically, and slowly closed it again.
And then he said "What makes you think it won't take the stairs?"
I don't think Jim ever did use the walker they brought over for him a couple weeks ago, and I think he only agreed to the wheelchair that arrived last week because he could push it around with his eyes closed.
We opened the windows one day last weekend when it was nice out, so he could hear the birds in the trees outside his second-story window. I thought I spotted him inching the chair towards the door. I told him I was sorry that the wheelchair couldn't take him outside. He didn't say anything for almost long enough that I wondered if he'd heard. But then he opened one eye a little, peered at me skeptically, and slowly closed it again.
And then he said "What makes you think it won't take the stairs?"
Vancouver Aquarium
Lighthouse Park, West Vancouver
White Spot, Georgia and Seymour, Vancouver
¶ CD death-watch update 2 · 28 April 2006
Credit to both Metropolis and Nonesuch for not only responding to my emails, but promptly and uncomplainingly sending replacement copies of the Gary Numan and Stephin Merritt albums. Double credit to Metropolis for not minding that I had abused my first copy of Jagged fairly badly, trying out various supposed copy-protection circumvention techniques. Double credit to Nonesuch for not minding that I had returned my two copies of Showtunes, and they were thus sending me not so much a replacement as a free copy for my trouble.
Of course, both new CDs have exactly the same problem as the old CDs. They're defective pressings, not defective individual discs. Triple demerits to both labels for not having figured this out by now. Or for not admitting having figured it out, if in fact they have.
Of course, both new CDs have exactly the same problem as the old CDs. They're defective pressings, not defective individual discs. Triple demerits to both labels for not having figured this out by now. Or for not admitting having figured it out, if in fact they have.
I'm not sure if I think it represents inspired design, cynical design, or inspiredly cynical design, but I've been watching the iTunes Music Store with alternately grim and admiring fascination since they started allowing user comments. I thought it was a pretty terrible idea for them from the beginning. Apple has a strong corporate personality, and one of the only strongly positive corporate personalities, and diluting it with inevitably idiotic "reviews" seemed self-evidently awful to me. Amazon has had some success creating a body of mildly thoughtful annotation, but Amazon's music department is still oriented around selling CDs, so there's some remote hope that a person writing about an album may actually have heard it.
In the iTMS, however, not only are individual tracks sometimes more popular than whole albums, but even more significantly, it is central and trivial to listen to samples of all the material, which leads directly to the most uselessly write-only of all possible user contributions, the snap rating of albums based on first impressions of fragments of songs, by people who haven't even heard the whole thing once. It's debatable what function reviews have at all in the previewable era, but if they still have any role, surely it's to report back from extended experience with the music. If I can listen to the fragments myself, I don't need a second-hand version of that experience.
But the self-ratcheting structure of Apple's comment system applies some brilliant/crass social judo to automatically marginalize the crap. Under each comment is the telling question "Was this review helpful? Yes/No", and then the main page for each album shows only the first few reviews (6 if there's no "editorial" review, and only 3 if there is) as sorted by helpfulness. The all-reviews page begins with one recent review, to encourage new input, and then again defaults to sorting by helpfulness. Thus the farther a review falls down the helpfulness sort, the fewer people will even see it, and the less likely it is that it will be able to move back up. The worst crap, at least, sinks.
In the iTMS, however, not only are individual tracks sometimes more popular than whole albums, but even more significantly, it is central and trivial to listen to samples of all the material, which leads directly to the most uselessly write-only of all possible user contributions, the snap rating of albums based on first impressions of fragments of songs, by people who haven't even heard the whole thing once. It's debatable what function reviews have at all in the previewable era, but if they still have any role, surely it's to report back from extended experience with the music. If I can listen to the fragments myself, I don't need a second-hand version of that experience.
But the self-ratcheting structure of Apple's comment system applies some brilliant/crass social judo to automatically marginalize the crap. Under each comment is the telling question "Was this review helpful? Yes/No", and then the main page for each album shows only the first few reviews (6 if there's no "editorial" review, and only 3 if there is) as sorted by helpfulness. The all-reviews page begins with one recent review, to encourage new input, and then again defaults to sorting by helpfulness. Thus the farther a review falls down the helpfulness sort, the fewer people will even see it, and the less likely it is that it will be able to move back up. The worst crap, at least, sinks.
(four moments found in my cameraphone, which I never seem to remember having used)
Traffic seems to have slowed to a standstill on vF, my discussion forum. This is totally unsurprising, since the forum has never had any better reason to exist than me feeling like programming it, and I haven't done much to recruit conversants or stimulate conversation.
Nor will this really count as recruiting or stimulation, but today I finally got around to porting the search function used elsewhere on this site over to the forum software.
Please rejoice discreetly.
Nor will this really count as recruiting or stimulation, but today I finally got around to porting the search function used elsewhere on this site over to the forum software.
Please rejoice discreetly.
¶ alpha beta go · 13 April 2006 essay/tech
Say you're making software to do X. The audience for this is people who want to do X, and the evaluation criteria for the software to do X is that it actually can be used to do X in some respectable and hopefully distinguished manner.
Before you get to the released version of your software to do X, there are two useful stages you will probably want to pass through: beta and alpha. These are not percentages of completion or levels of toleration of error, they are themselves tools for different purposes than the released version. X beta exists to provide an evaluable preview of X. X alpha exists to provide an evaluable preview of X beta.
It is not only possible, but critical, to substitute these purposes of beta and alpha back into the original statement. Like this, for beta:
Note that this is different. The people interested in previewing a tool to do X are not necessarily the same people as the ones who want to do X, and their goal is not doing X but seeing how your software is going to do X.
Likewise with alpha:
That is, the beta is a tool for seeing how the real thing is eventually going to work, and the alpha is a tool for seeing how the beta is eventually going to work. The audience for alpha is thus double-meta, and is likely to be very small, sometimes even smaller than the team working on it.
Even more crucially, the substitution works in the other direction, too: beta is a released version of software for evaluating a preview of X, and the alpha is a released version of software for evaluating a preview of the beta. So while the X beta may have omissions and errors in its performance of X without failing, if it has omissions and errors in its performance of the evaluation and preview of X, it fails.
Thus the released version of an online calendar for shared scheduling, for example, fails if it can't be used for shared scheduling. But the beta fails if it can't be used for experimenting with shared scheduling. So the beta doesn't require that all the shared scheduling features work, but it does require that all the experimentation features are ready.
If your software involves manipulating user data of any kind, then, here are some things that probably have to be already working, without appreciable error, in your beta:
- import
- reimport
- importing useful sample data
- distinguishing data by import batch
- undoing import batches
- deleting data
- deleting data en masse
- full data purge and restart of beta experience
- comparing your treatment of this data to the treatment of it wherever it came from
- comparing different treatments of this data within your own software
- export/sync/feed of this data to any evaluation-critical downstream integration points
- sync/feed of source data from any evaluation-critical upstream integration points
- full operation of a representative subset of anything critical of which there will be multiples (integration points, environments, styles, templates, other users, etc.)
- any configuration settings integral to personal evaluation
- clear explanation of beta limitations
If any of these aren't done, don't ship your beta yet. If some of them aren't even in your design, you've got more designing to do.
Before you get to the released version of your software to do X, there are two useful stages you will probably want to pass through: beta and alpha. These are not percentages of completion or levels of toleration of error, they are themselves tools for different purposes than the released version. X beta exists to provide an evaluable preview of X. X alpha exists to provide an evaluable preview of X beta.
It is not only possible, but critical, to substitute these purposes of beta and alpha back into the original statement. Like this, for beta:
Say you're making software to {provide an evaluable preview of X}. The audience for this is people who want to {evaluate a preview of X}, and the evaluation criteria for the software to {provide an evaluable preview of X} is that it actually can be used to {evaluate a preview of X} in some respectable and hopefully distinguished manner.
Note that this is different. The people interested in previewing a tool to do X are not necessarily the same people as the ones who want to do X, and their goal is not doing X but seeing how your software is going to do X.
Likewise with alpha:
Say you're making software to {provide an evaluable preview of an evaluable preview of X}. The audience for this is people who want to {evaluate a preview of an evaluable preview of X}, and the evaluation criteria for the software to {provide an evaluable preview of an evaluable preview of X} is that it actually can be used to {evaluate a preview of an evaluable preview of X} in some respectable and hopefully distinguished manner.
That is, the beta is a tool for seeing how the real thing is eventually going to work, and the alpha is a tool for seeing how the beta is eventually going to work. The audience for alpha is thus double-meta, and is likely to be very small, sometimes even smaller than the team working on it.
Even more crucially, the substitution works in the other direction, too: beta is a released version of software for evaluating a preview of X, and the alpha is a released version of software for evaluating a preview of the beta. So while the X beta may have omissions and errors in its performance of X without failing, if it has omissions and errors in its performance of the evaluation and preview of X, it fails.
Thus the released version of an online calendar for shared scheduling, for example, fails if it can't be used for shared scheduling. But the beta fails if it can't be used for experimenting with shared scheduling. So the beta doesn't require that all the shared scheduling features work, but it does require that all the experimentation features are ready.
If your software involves manipulating user data of any kind, then, here are some things that probably have to be already working, without appreciable error, in your beta:
- import
- reimport
- importing useful sample data
- distinguishing data by import batch
- undoing import batches
- deleting data
- deleting data en masse
- full data purge and restart of beta experience
- comparing your treatment of this data to the treatment of it wherever it came from
- comparing different treatments of this data within your own software
- export/sync/feed of this data to any evaluation-critical downstream integration points
- sync/feed of source data from any evaluation-critical upstream integration points
- full operation of a representative subset of anything critical of which there will be multiples (integration points, environments, styles, templates, other users, etc.)
- any configuration settings integral to personal evaluation
- clear explanation of beta limitations
If any of these aren't done, don't ship your beta yet. If some of them aren't even in your design, you've got more designing to do.