Angry Little Tree

Analogies are Like Dinners, or Thoughts on Cliff's Notes and Mobile Sites

2012-05-01T00:00:00-05:00

If the words "mobile web," "responsive design," and "click here to view our desktop site" mean anything to you, the last couple of days have probably been pretty interesting. On April 12th, the venerable Jakob Nielsen penned a controversial article telling companies to roll back their clocks to 2008. Build a separate mobile site, he advised, redirect mobile device users to it automatically, and provide cross-links for those determined to see how the other half lives. In particular, he advocated eliminating content and features that aren't "core to the mobile use case."

Designer and Mobile Dude Josh Clark weighed in with what I can only assume was profound disappointment, noting that the much-talked-about 'mobile use case' is a mirage. Some users are on-the-go factoid hunters, looking for a quick hit of movie showtimes and key phone numbers. Real mobile usage, however, covers a broad spectrum of scenarios. In addition, more and more low-income users access the internet exclusively through mobile devices; a 'just the basics' approach to mobile site functionality is another element in the growing digital divide.

Enter writer and web developer Jason Mark. His recent column for .Net Magazine tries to split the difference, and accuracy suffers for the sake of provocative positioning. He boldly announces that both Nielsen and Clark were wrong, but singles out Clark's points for specific criticism and ultimately makes a case for the same separate-site approach as Nielsen. While the essence of Mark's advice is sound (look to the actual usage data for a site to figure out what its "mobile users" need), his critique of Clark stumbles in two key ways.

First, the piece summarizes Clark's argument as "Always build a single responsive site." In reality, Clark's article advocated the same sort of analytics-driven decision making that led Mark to build separate mobile sites for his clients. The key take-away from Clark's article was the fact that there is no single "mobile use case" all companies can target. Figure out how your visitors are using your mobile site (or how they'd like to) and tailor it to that. If responsive design techniques work, use them. If a separate site with pared down content is what they want, that's the right way to go. The danger lies in in assuming that a mobile visitor has a particular task in mind simply because of her user-agent.

Which brings us to the second problem: A terrible analogy. Clark's article equated limited-functionality sites to books with chapters ripped out, and I agree with his comparison. Jason Marks' response article responds with a counter-analogy: limited-functionality mobile sites are like Cliff's Notes, and students love those little yellow-and-black lifesavers.

The problem isn't that someone, somewhere, is serving up truncated content. The problem is assuming that a visitor wants that truncated content or reduced functionality simply because of the device they're using. It's like assuming every college student wants the Cliff's Notes version of a book simply because they're wearing school colors. Sometimes, it's a perfect match -- often, though, it will result in annoyance and confusion.

That frustration and confusion is often compounded by the common antipatterns found in separate mobile sites: mismatching URL structures, deeplinks to the desktop site that redirect mobile users to the front page of the stripped-down site, iPhone-centric design assumptions, and so on. Responsive design, far from being a design fad, is an attempt to solve those problems and streamline the process of managing content and functionality-rich sites. It's not a panacea, but celebrating the merits of separate mobile sites without addressing their real flaws is an exercise in missing the point.

Hipsters, Curation, and The River Of Crap

2012-03-14T00:00:00-05:00

I'm seeing a lot of hate for "curation" these days; I suppose that backlash is inevitable to some extent. The concept of adding value by selecting and organizing related works is kind of fuzzy to begin with, even though it has precedent. As tools proliferate and the difficulty of basic curation tasks goes down, though, we encounter the classic self-aggrandizing folks who classify their OCD retweeting or Mashable links as "curation," because aren't they selecting and organizing things by deciding what to RT?

Yeah.

The challenge is that a lot of what people do casually as part of their information diet is legitimate curation, in the same way that people who pick songs for poker night's playlist are DJing. Some of those curators-by-technicality seem to regard their retweets and reblogs and pins and so on as acts of profound importance; recent efforts like the Curator's Code seem to focus on crediting the people who post a link more than those who create the original works.

That, I'm happy to admit, seems a little backwards. For every carefully tended digital archive like Paleofuture, there are hundreds of minimally-maintained linkblogs, softcore Tumblrs, and machine-gun retweet-please-follow-me accounts. The worst of them are simple spam; the mediocre are an annoyance unless you're a topical obsessive; but when you find someone willing to put the time and energy into crafting a genuine narrative context for their links? Well, that's magic.

When there was less stuff out there, simple aggregation was a fine service. Simply collecting all of the stuff out there on a given topic was useful in and of itself, and the act of "finding something cool" or "gathering up all the articles about X" was a genuine service. Today? Algorithmic filters are barely keeping up with the deluge of fresh content. YouTube alone adds 48 hours of new video every minute, and Sturgeon's Law is choking us all.

Aggregation has failed as a solution, though it's still useful as a starting point. Genuine curation -- the stuff that rises above the crowd -- requires the curator to provide a unique narrative, a context for the raw content. Which brings us a bit closer to the paradoxical heart of the matter: there's too damn much stuff on the Internet, but good curation is itself an act of creative addition. That kind of curation doesn't need special linkback hat-tipping markup syntax; there's value in the links, but the curated work is worth linking to on its own merits.

Thoughts on taxation and social responsibility

2011-08-17T00:00:00-05:00

I'm a white midwestern suburb kid who started out mowing lawns and hauling rocks for summer funds, got a crummy job out of school and slowly bootstrapped myself to become a reasonably successful software developer and public speaker. From a flat-out personal income standpoint, I stand to benefit from the Republican (and even Tea Party) tax proposals over the next decade or so. From a societal standpoint, however, I stand to lose out badly. My taxes pay for a world in which those with less money than me have a bit less to worry about. That means that they can do productive, useful things like raising their kids rather than trying to scrape for a third job; go to the doctor for a checkup rather than waiting until they collapse in pain; and starting new and innovative businesses rather than "playing it safe" for their families. Those are the things that a social safety net makes possible, and when other people enjoy its benefits I benefit as well, from their business if nothing else.

I view my contribution to the management of our society -- via taxes -- to be one of my fundamental responsibilities as an American, no less important than showing up for Jury Duty and registering for the draft. You can object to how some tax monies are being spent, just as you can object to how our military is being used around the world, or how certain court cases turn out. The objections being raised by most small government advocates, however, have little to do with "waste" once the rhetoric is swept away. It's about the idea that shared funding of society's infrastructure is fundamentally wrong, unless it goes to police or military forces.

The two arguments that I hear frequently are strangely contradictory. First, there's the claim that lower income people who want to see taxes raised are "trying to screw the rich." Second, there's the complaint that higher-income people who want to see taxes raised "should just donate to charities if they want to help people." The obvious conclusion is that no one -- not anyone! -- can make an honest case to raise taxes. Charity and charity alone should cover the social safety net.

We tried that, as a nation, for some time. It didn't work, and we went through a long hard slog to fix it. That's why we pay higher taxes than we did in the 1800s. That's why the rest of the first world pays higher taxes than Tea Party and small-government conservatives would prefer. They either don't remember the lessons that our country learned, or they believe that trading the potential of unlimited wealth for the reality of widespread hardship is worthwhile. I do not believe that it is; I'm OK with being called anti-capitalist, anti-American, and so on because of that. That's the way that political discourse works.

Gutters

2011-05-23T00:00:00-05:00

Conrad had arrived at dawn, ready to do what needed to be done, but his father had been up for an hour already. The gutters were well underway, and Dad's pride was palpable.

"I'm not a cripple, you know. I can just use an extra pair of hands."

"Well, just point me where you need me."

He gave his father a chuckle, an amused roll of the eyes, just as his mother had done for decades. But brave words aside, the man's steps were uncertain as he inched down the ladder. Hands shaking as he reached the ground and stopped to catch his breath.

"Here, dad. I'll finish this side. You check the back while I clean up."

After another hour, Conrad could read exhaustion in his face; when Dad announced it was time to trim the old willow, Conrad feigned a cramp and suggested a break for coffee.

"We just started," his father muttered, shaking his head. He made his way inside without protest, though, and within minutes of sitting he'd fallen asleep in the old living room chair.

Conrad sat watching him in silence, warming his hands around the mug of Folgers he'd poured. Hardly a year since she left, and it was already hard to remember how she'd animated his father's face, filled it with her presence.

"Fuck." He sighed, setting the mug down as quietly as he could, and slipped his phone out. One message from Meg.

??
doing ok, looks like shit but no accidents. be home at 4.

He sent the reply and turned to his father again.

"Hey. Dad." A nudge, and the man stirred. "Leg's fine now, I'm going to finish up the willow."

The man blinked, confused for a moment, then huffed his agreement. He shifted half-heartedly in his seat, making a show of rising before Conrad stopped him.

"Don't worry, I've got it. I think I need some time out there, too." He met his father's eyes: a nod, and a faint smile before he relaxed in the seat again. Eyes fluttering closed.

There is truth in that

2011-04-05T00:00:00-05:00

Catherine: Good morning! I saw your tweet about Varnish configuration. I hope it's okay that I didn't read it.

Jeff: What? Don't you want to hear about using edge-side includes to balance highly dynamic user-generated content with heavily cached pseudo-static page structures in a high availability environment?

Catherine: [ crickets ]

Jeff: I could've just made those words up.

Catherine: No, those words are too boring to be made up.

The rest of it all

2011-04-03T00:00:00-05:00

There's nothing like three weeks of travel, a site launch, and a major sinus infection to cut into your blogging output, you know? But now, here I am: I've survived DrupalCon, the client's web site has launched successfully, and I'm doped to the gills on painkillers, antibiotics, and anti-inflammatory drugs. Hooray!

Although the Lullabot team has been doing post-Drupalcon posts and podcasts over at the company site, we haven't talked much about one of the really cool things that preceded it. Our second annual full-company retreat was in downstate Illinois this year, and it was pretty amazing. Since I joined in 2006, Lullabot has grown from a handful of devs hacking on Drupal to a powerhouse team. There are about two dozen 'bots now, and as a fully virtual company we have to work hard to get face time. It's a critical investment in the company, though: the four days we spent laughing, connecting, planning, and getting to know each other better was invaluable.

I'm struck by how lucky I am to be working with such a gifted group of developers, designers, teachers, writers, project managers, and more. We've grown to the point where specialization is a necessity, not a luxury, and seeing everyone tackle their roles and specialties (and thrive) is tremendously encouraging. One of the retreat days was dedicated to teaching -- not Drupal stuff, but the random talents and interests and passions that we each have. Joe taught us how to give awesome hugs (complete with charts!), Liza gave a fashion boot camp for geeks, Angie introduced everyone to the beauty of Picross, Dave taught us sleight of hand tricks, Jared showed everyone how to make a golden ratio grid... By the time we left for Drupalcon proper, we were all riding high.

One of the topics that was discussed a lot over the retreat week was the challenge of preserving Lullabot's culture and values as it grows. In a way, I think that our challenges mirror those of the Drupal community as it evolves into a "mature" platform and industry. A lot of the default approaches to communicating, planning, and setting goals have to change and grow. And while Lullabot's definitely grown in the past several years, the folks steering the ship have made deliberate choices to focus on being good at what we do rather than being the biggest at what we do. That encourages me a lot, given the relentless emphasis on VC-funded growth explosions that the web industry frequently treats as the goal.

We all talked a lot about books like Small Giants, and ways to improve the things we value most. Over the past couple of weeks, I've started collecting various articles about similar ideas, and it's interesting to see examples of that kind of focus are scattered all around, often hidden behind the flashier success stories. Chipotle's story of staying focused even when McDonalds pressured them to branch out, Trader Joe's history of doing a few things really well, and developer Wil Shipley's thoughts on "miners" versus "farmers" all resonate really deeply these days. It's an interesting time to work on web stuff, and I'm glad I'm doing it with awesome people.

Power Power Tigerpaw, live in concert

2011-02-21T00:00:00-06:00

With the exception of chaotic prep for Drupalcon, this weekend was a nice breather from the impending launch of The Top Secret Project What Can't Be Named. It'll be nice to see it launch, both to get the deadline behind us and to see what public reaction to the site is. It feels good to have set up a client for future success, but but it's always tough to predict how bumpy the transition period will be.

I managed to catch a Power Power Tigerpaw show at the Roundhouse on Sunday, which was a lot of fun. Jason, Danny and Mike have only just started to book shows, but they've been practicing like madmen for over a year. They are ridiculously tight. It's bombastic guitar-heavy rock with a lot of personality, and if you're reading this odds are you'll like it.

In unrelated but fun adult beverage news, I started the third round of test infusions. After the success of the holiday infusions at our Christmas party, I wanted to take a stab at some additional flavors. Currently cooking: blackberry, plum, and banana-vanilla vodka. I have high hopes...

It doesn't matter until it matters

2011-02-16T00:00:00-06:00

This Ars Technica dissection of the Anonymous hack on HGBary is an excellent overview of how really serious exploits happen. Any one of the security holes that the company had would have been bad, but I'd argue that almost every company has them floating around in unrealized corners. It's ridiculously hard to completely avoid all security holes, and for most companies it's just not worth it. You put walls between critical systems and you ensure that your relatively unimportant systems don't have easy entrances into the more important ones.

The real problem was the multi-factor cascade of failures, some technical others human. A SQL injection exposed weak password hashing, which revealed a weak password, which had been foolishly re-used by a user, whose account was used to convince a sysadmin to do something he shouldn't have, which was used to open up another security hole, which the sysadmin noticed but didn't crack down on as quickly as he should have, which...

The problem is that computer security, like physical security, is about obsessively following best practices and tightening down every bolt and screw, even if it makes your daily work really frustrating and cumbersome.

Solid security is hard. Not because it is rocket science, but because it is about constant annoying vigilance against small violations of protocol, few of which ever really matter.

Except when they do.

And then you're fucked.

Easy beats open: a reflection on walled gardens

2011-02-15T00:00:00-06:00

This week, Apple's updated requirements for the iOS App Store have sparked another round of debate about "Walled Garden" software platforms and the dangers they pose. For those who don't hang around Mashable and Slashdot waiting for Free Software debates, I'll summarize.

2008 to 2011: The App Store in review

When the iPhone App Store debuted in 2008, Apple announced it would take a 30% cut of all sales in the store. There was some grumbling, but for the most part it was the price of access to a large market. It also maintained Apple's place as gatekeeper for the iPhone experience: although it was unevenly enforced, apps routinely got kicked out for doing things that Apple argued would be bad for users.

About a year or so later, Apple added an in-app purchasing API, allowing apps to offer premium add-ons or in-app stores without linking to any external purchasing screens. Today, an iOS user looking to get premium stuff just clicks a "Purchase" button inside the app, the user's iTunes account is charged, the app gets purchase confirmation, and the user gets their goodies without any other interruptions. It's used by lots of games to provide additional "premium" maps, unlock special abilities, and so on. However, those in-app purchases are subject to the same 30% cut that Apple takes of new app sales.

Now, Apple has added support for recurring subscriptions to the API. Magazine publishers are obviously intrigued by this addition, because it matches their traditional distribution model much better than creating and distributing a completely new app for each issue. As with App Store purchases and in-app purchases, though, these subscriptions are subject to the same 30% cut for Apple.

The real kicker is that Apple now makes it very clear that anyone providing in-app sales or subscriptions must use the Apple payment APIs. No work-arounds, no links off to web sites that handle payment, no sneaky tricks. Either you use Apple's payment APIs or you don't offer in-app content purchases. And if content can be purchased in two places -- inside the app and via a web site, for example -- it has to be offered at the same price. No 30% markups for the in-app version of a book, for example. In that way it's similar to Facebook's new CreditsAPI -- all Facebook games that process credits are required to use it.

Some people are very angry about this, some people don't care, and some people are just trying to figure out how to parse the App Store guidelines document to get a straight answer about edge cases. (Does the Netflix app qualify as a "content subscription?" Does a monthly Skype subscription? Probably not, but there are lots of arguments popping up around the web about the legalese.)

Richard Stallman is laughing at us all

Ever since the launch of the App Store, Free Software advocates have been telling us that it was Bad News with a capital B. It turned the iPhone -- already a relatively closed device thanks to Apple's control over iOS -- into a closed ecosystem for apps, too. Instead of developing open web apps that ran well on the iPhone, many developers scrambled to develop native iOS-only apps that could be sold in Apple's store. Why wouldn't they? At the time it was one of the only really capable smartphones with a browser beefy enough to run real web apps, and writing native iOS apps would allow them to turn the mobile apps into a revenue stream instead of a loss-leader for web ads.

Of course, Richard Stallman has been warning about this kind of stuff for years. The problem with walled gardens -- software ecosystems where one vendor controls access and only those who play with them can distribute their work -- is that eventually things go south. Features you want get turned into premium add-ons, innovative developers run afoul of the legalese and can't compete with the big guys, and so on and so forth. Looking back at Steve Jobs' promises from 2008, it's not hard to see that the warnings were correct:

“We don’t intend to make any money off the App Store,” Jobs said. “We’re basically giving all the money to the developers and the 30 percent that pays for running the store, that’ll be great.”

That's a little of the Reality Distortion Field in action: it seemed plausible at the time, but as Apple makes the use of their purchasing APIs mandatory for iOS apps, it's hard to pretend this isn't about protecting a revenue stream.

The problem, of course, is that none of this matters. Magazine publishers like Wired and GQ were already releasing each issue as a separate app and paying the 30% cut to Apple. In-app subscriptions simplify things for them. Existing subscriber-only services like Netflix never offered in-app purchasing to begin with, only linking of the app to an existing subscriber account. And Amazon won't kill its Kindle app for iOS; it will simply remove the 'Store' button from it to comply with Apple's guidelines. Heck, the Kindle Store itself runs into the same DRM walled garden problems: anyone who's complaining about this particular change to the guidelines is already in bed with the enemy, as far as Free Software advocates are concerned.

The heart of the problem: Open Is Hard

Given that background, it's predictable that Apple's latest announcements have triggered a lot of "Open is better! See?" comments from free software advocates and DRM critics. To some extent, they're right: if the iPhone were an open device, people could use any operating system they desired to power their phones. If the iOS were free-as-in-freedom software, unencumbered by Apple's onerous terms of services and so on, people could use any app store they liked and developers could thumb their noses at Apple's 30% cut. But that's not the case, and people continue to use iOS devices like iPhones, iPads, and iPods despite the burdens of a tightly controlled system.

Many open-systems advocates and Apple critics are baffled. Why do people use iOS devices when open alternatives exist? Why are most people untroubled by this stuff even though it looms so large in developer discussions? The answer is simple: Apple has focused its energy on making iOS really easy to use, and when the credit cards come out, "easy to use" almost always trumps "philosophically open." Let me repeat that, just in case I'm unclear:

Easy always trumps Open. Closed only loses when it is cumbersome.

Apple learned this lesson when it launched the iTunes store in 2003 and started selling DRM'd digital music. Other companies had been doing the same thing for years, and the prevailing opinion was that no one would be able to complete with "free" pirated mp3s. Apple proved to the music industry that few people cared about DRM and open formats -- they wanted a huge selection, track-by-track purchasing, and a simple shopping experience. Apple delivered all of those things in spades, and they laughed all the way to the bank.

There will always be people who demand their music in un-DRM'd OGG Vorbis files, just as there are people who refuse to use hardware they can't hack. For those people, "Open" is a feature that matters just as much as performance or ease of use. For the vast majority of the public, however, "Open" is just another word that gets tacked onto product pitches and can be safely ignored. What matters is the stuff you can do with it. If something is hard, or cumbersome, or annoying? That's no better than it being impossible due to licensing restrictions.

No, seriously, Open always fails.

The OpenID standard, for all of its technical advantages and all of its benefits for heavy duty web nerds, is suffering compared to closed alternatives like Facebook Connect. Recently a number of blistering blog posts have outlined the most popular explanation: simply put, it's really confusing and really complicated compared to a login form. Although smart folks disagree that OpenID is a failure, the important point remains. Open Stuff that promises hypothetical benefits but makes day-to-day tasks harder will always be a hard sell. Similarly, Open Stuff that delivers additional functionality that is only interesting to hardcore developers or advanced users will always be a hard sell. A device that automatically works for 90% of the market is more useful to most people than a device that can be made to work for 100% of the market but requires arcane tinkering.

Apple has succeeded not because of Steve Jobs' famous reality distortion field, but because it makes things really easy to use. Easy enough, in fact, to overcome customers' aversion to paying for stuff. Easy enough to make most people ignore the hypothetical benefits of open standards, because the implementations of those open standards are clunkier, more complicated, less established.

Sooooo... Where to from here?

The answer isn't to lecture people who choose ease of use and simplicity. The answer isn't to talk about what things might be possible with open systems that can't be done on closed ones. The solution isn't to show non-technical users all of the arcane and complicated geek games that can be played with open systems, either. What can we do? The answer is straightforward, but it takes a lot more work than wagging our fingers at Apple users.

We have to make open solutions just as useful and easy as closed ones for non-developers.
We have to win users over with specific solutions to problems closed systems aren't addressing, rather than the hypothetical benefits of openness.
We have to accept that the vast majority of users want to be served by their software, not converted to a cause.

Open Source has traditionally succeeded when the closed source alternative is too inflexible or too expensive to serve the needs of important markets. If we as OSS developers want to tackle markets where most users aren't yet feeling those problems, we'll have to learn to compete on more than ideology.

Everybody needs a buddy

2011-02-04T00:00:00-06:00

Bing like a bee

2011-02-02T00:00:00-06:00

So, the gauntlet has been thrown down. According to Google, Microsoft's Bing search engine is secretly copying their search results. According to Microsoft, Google is totally paranoid and they were just talking to that chick at the bar, and it didn't mean anything.

In fact, Microsoft seems a bit testy about Google's approach to the issue: setting up honeypot search terms, "trapping" Bing mirroring the results, and so on. They say it was a cheap stunt worthy of a bad spy novel, but Google's not amused. I think they've got a good reason to be pissy, not because Microsoft violated some gentleman's agreement, but because the OS giant has finally figured out how to leverage its position in the OS and browser market to boost their in-house search engine.

According to Microsoft, Google's search results are mirrored in Bing's because Internet Explorer and the Bing search toolbar "collect information to improve their computing experience." That data includes the sites they visit, the links they click, and so on -- all sent back to Microsoft for analysis, all with Users' permission when they check the 'collect data' checkbox as they install the software. For those who need coffee, Google is a site that those users visit, and the search results they get on Google.com are links that they click. When IE and/or Bing Toolbar users run searches on Google and follow one of the resulting links, it becomes a data stream for Bing -- one of many, of course, but definitely a data stream.

Internally, Google has used tools like SearchWiki to let users customize their own results, and I believe that they've used their own clickthrough data in ways similar to Bing. If search users frequently click a particular link after searching for a subject, that link can get more weight for the search term. Google can track this information on its own searches using simple clickthrough scripts, just like any other site tracks metrics as users surf around the site hierarchy and follow links to leave. Microsoft, though, can watch the same clickstream via IE and/or the Bing toolbar, and they've admitted that they use the data in their index weighting.

At least in theory, for search terms with no good matches (like the gibberish text Google was using), any information gathered via this clickstream data mechanism would become the hottest source of ranking data for a particular gibberish phrase.

Collapsing down a lot of the details from the Google post and correlating it with what various Microsoft responses have said, the mechanism by which the "honeypot sting" worked is pretty straightforward.

Google notices that Bing "trails" Google search engine tweaks by a couple of weeks.
Google sets up the honeytraps by inserting false search results for a handful of gibberish phrases.
Google engineers then search on them and click through to the bad-match pages on machines running IE. By doing so, "user data" is gathered by Bing, associating the gibberish words with the badly matched results pages.
Because those gibberish phrases have no good matches on the Internet already, the incoming 'user behavior' data weights high in Bing's algorithm.
After a couple of weeks those gibberish phrases start generating the same matches on Bing that they do on Google.

The most interesting part of the whole affair is Microsoft's argument that they're not "spying on Google" at all -- they're just watching what IE and Bing Toolbar users do on the Internet, and using it to weight results. In doing so, yes, they're piggybacking on Google's clickstream data. In fact, they're able to piggyback on clickstream data for any search engine that IE or Bing Toolbar users try.

Think this through: it means that every search engine out there is feeding data to Bing as well. Google complains that Microsoft is cheating instead of competing on the algorithm front, but this process is Microsoft building an algorithm: an algorithm that pits search engines against each other and watches what results get the most clickthroughs. In that context, Google's heated response makes a lot of sense: they've realized that there is no way to avoid simply becoming input for Bing's meta-algorithm. There's no way for anyone to.

It'll be fuel for a few rounds of editorials, blog posts, and arguments, naturally. But there's another wrinkle that the snark in me finds intriguing. Presumably, Bing doesn't use clickthrough data on just any web site -- the results mattered more because they saw the clickthroughs occurring when people visited google.com. Google engineers made that happen by inserting the bogus results into their own index, and searching for them on their own machines using IE. Couldn't someone else do the same thing on a small scale using Firebug? Search on Google, use Firebug to add a bogus result to the search page, click on it in IE, and bam: you've seeded Bing's meta-algorithm with fake information. From there, it would be cake for a dedicated group of people to automate the process, using proxy servers to insert bogus links into Google results pages, and telling a group of volunteers to click the hell out of the bogus links.

Google might be annoyed that Microsoft is piggybacking on their clickstream, but with this set of accusations and the careful analysis it's triggering, they might have just handed 4chan the keys to Bing...

Draw a Dinosaur Day

2011-01-31T00:00:00-06:00

Apparently, no one told me that yesterday was Draw a Dinosaur Day. It's the sort of holiday we need more of, and I wanted to do my part albeit belatedly.

Drupal 8: The Road Ahead

2011-01-28T00:00:00-06:00

While the rest of the world kicks the tires on Drupal 7, the mad scientists who work on Core are already breaking out the whiteboards and starting to plan for the next release. It's a tradition: with the current release in the can, the pent-up energy for new stuff can be released.

After Drupal 7's epic three-year development cycle, though, even the most aggressive devs are taking a moment to consider what areas deserve attention. Some want to push forward with major architectural changes that didn't fit into the 7.0 cycle; others are lobbying for a "housekeeping" release that focuses on API cleanup and performance tweaks; and others want to take the User Experience improvements from D7 to the next level.

If there's one thing that the last several years has taught us, though, it's that we can't succeed by focusing on a single slice of Drupal's audience (or a single subset of the Drupal contributor community). Going nuts with architectural improvements is a recipe for navel-gazing unless it's guided by the felt needs of site builders, day-job developers, and businesses. Pouring our energy into new theming work, new UX widgets, and bold workflow changes will frustrate core hackers who see cracks in the foundation that need repair. And the idea of a pure "fix-it" release, focusing on fixing key frustrations without adding new features, is a non-starter: Drupal has always needed the carrot of new functionality to bait the stick of API changes. If version 8 included nothing but breaking changes, there would be no reason for the majority of users to upgrade. (And if the fixes don't break existing APIs, why not roll them into a 7.1 or 7.2 release?)

Obviously, pitting these different visions against each other is a false dilemma. Drupal's diverse community of contributors can work on multiple projects at a time! Larry Garfield's refactoring of the hook system wouldn't prevent Jen Simmons from adding HTML5 support to Bartik, for example. But as we move forward into the next cycle of Drupal, we need more than "projects that don't collide with each other." We need a vision for what the future of Drupal holds, a path to get there, and a set of realistic priorities for the next release that get us moving down that path. Above all, we need to keep the final goal in mind: making the software called "Drupal" a killer tool for building multi-user, content-driven web sites.

Three Points of Pain

While everyone in the Drupal universe has their own pet demons (has webchick mentioned support for Signatures lately?) several recurring pain points have emerged over the past couple of years. These issues cause lost sleep, missed deadlines, and endless frustration for people at all levels of the comunity; from businesses switching to Drupal, to shops building distros, to hobbyists bootstrapping online communities.

Missing APIs

The tug-of-war over what should live in core and what should live in contrib is eternal. Some foundational problems, though, are impossible to solve efficiently outside of core. Grafted-on solutions to those problems require duplicating large swaths of core, and risk collisions when multiple teams tackle the same problem separately. Identifying these critical missing links in Drupal's APIs and filling the gaps will allow developers to focus on solving their unique problems rather than wrestling over competing standards. Two APIs that are painfully missing are context and web services.

The first one -- context -- is about keeping track of the essentials when responding to a web request. "What page am I on? Who asked for it? Am I in someone's blog, or in a forum?" and so on. These are all simple contextual questions that must be asked before a page can be rendered. In Drupal core and contrib, there are literally dozens of separate functions dedicated to answering these questions. Two competing mechanisms (CTools's Context, and the standalone Context module) have emerged and found an enthusiastic user-base, but neither can reach its full potential as a bolted-on solution in contrib. The Butler project is a first stab at providing a central context mechanism in Drupal core, and getting its skeleton in place should be one of our top priorities.

The second missing API is a built-in foundation for web services. Drupal's early automatic support for standards like RSS and BlogAPI helped push it ahead of competition that required grafted-on solutions. As next generation standards for data exchange emerge, though, we risk falling behind. In Drupal 8, we can build on the foundation of the Entity API: automatically exposing all Drupal entities in a RESTful fashion would dramatically simplify the work of building desktop and mobile apps, complex cross-site publishing tools, and more.

Deployment

Today, most Drupal site-building consists of clicking small pieces together to assemble complex functionality, and storing the settings in the database. The line between site structure, configuration, and user-generated content has never been blurrier; separating the wheat from the chaff to reuse that configuration work is a huge challenge. In addition, the work of content staging -- creating content on one Drupal site and deploying it to another -- is truly difficult. With more large sites moving to Drupal, and the line between configuration and content blurring, these shortcomings are huge.

The first part of the solution is universally unique identifiers -- UUIDs. Today, quite a bit of our content is identified only by serial IDs generated in the database. Taxonomy term 5, node 92, menu item 103, and user 8 can't be migrated from one site to another, because their IDs are only unique to the site they were created on. Adding "machine names" to many entities like roles and input formats has eased some of the pain in Drupal 7, but we need to take it all the way: things we save to the database need UUIDs or machine names instead of a serial IDs.

The second piece of the deployment puzzle is a built-in mechanism for importing and exporting our configuration. The Views module pioneered this approach, allowing users to build out a complex screen, export the resulting View definition, import it on another site, and embed it into a module as PHP code for manageable reuse. This workflow is now leveraged by Panels, the Features module, and even several APIs in Drupal 7. By leveraging UUIDs and machine names to avoid collisions, and allowing the same import/export/override mechanism to be used with all data, we can take eliminate a huge chunk of the deployment problem.

User Experience

Creating a single user experience that works for everyone is an impossible task. The Drupal 7 User Experience team tried, and generated amazing results: a new administrative interface, streamlined tools for content posting, a fantastic new core theme, and more. The essential nature of Drupal, though, is still the same: it's a box of LEGO bricks for building web sites. To continue improving, we need to ensure that UX work focuses on bite-sized solutions that can be leveraged throughout the Drupal ecosystem.

Drupal's toolbox of UI elements conventions has been growing since the day it was first released: we need to document it and expand it. In the 1980s, Apple demonstrated the value of providing clear guidelines to developers on solving common UX problems. Module developers need to know when to use Vertical Tabs instead of collapsed fieldsets, why they should utilize drag and drop tables, and how to hide unecessary information from novice users. In addition, UX tools that are unecessarily tied to specific use cases, like Color module's color picker, need to be broken out for cleaner reuse. Enhancing and documenting UX Pattern Library for Drupal will pay off in greater consistency throughout core and contrib.

Finally, the addition of Bartik as a core theme has proven that Drupal is much more than a sidebar-content-sidebar cookie cutter. We need a complimentary "minimalist" theme in core for sites that require a no-nonsense, nothing-but-the-content approach. Customizable typography, color schemes, and imagery would take priority over lots of regions: we've proven that Drupal can handle complexity, and shipping with a "zero-cruft" theme would help us balance things out with zen simplicity.

The goal: A better Drupal product

So far, the ideas I've proposed aren't very revolutionary. Context and web services, better deployment and export tools, an enhanced UX toolbox and a minimalist theme for core... Several of these initiatives are already in the works, and the rest have generated considerable excitement among developers and designers looking to contribute. They would provide a compelling bullet-list of enhancements for the next version of Drupal, but they feel disconnected. At the end of the day, what greater goal are we working towards?

The flexibility of Drupal has always been biggest selling point: endless expansion hooks, a huge library of modules, and powerful tools for code-free construction. However, Drupal as a standalone download -- a tool that does something useful the moment you install it -- has been stuck in a holding pattern for years. We're trapped between a desire to add functionality and the need to make it as generic as possible. With the emergence of the "Minimal Install Profile" in Drupal 7, we have a safe starting point for the build-from-scratch folks. In Drupal 8, we can free the Standard Profile from its chains.

Drupal's default installation profile should be treated as a genuine product. It should be unashamed to focus on the target audience that already benefits the most from it: small groups of collaborators who want to share their work with the world, and convince their audience to participate as well. This covers a broad mix of users -- open source software projects, online news teams, community organizers, and more. The tools that come with core are already well suited to this use case: multi-user blogging for the team, RSS feeds and aggregation for collection and distributing news, forums and polls for getting the audience involved, contact forms for soliciting direct feedback, and so on.

For the purposes of this post and my subsequent discussions, I'm going to call this focused "Product" install profile... Tsunami. I think it combines the idea of an unstoppable force with Drupal's water theme, and it's easy to work into jokes about drupal.org's issue queue.

Many of the challenges that have plagued the D7UX team can be simplified by embracing Tsunami's focus. Features and workflow enhancements that are controversial for use across all Drupal sites can be implemented in the Tsunami profile -- perhaps even in modules restricted to the Tsunami profile, rather than the framework-wide modules directory. Allowing both developers and UX team to roll out features in Tsunami even if they aren't perfect for every site will make the default experience better, and free us from the impossible task of building an "Everything interface."

What's the most important principle? Drupal's need for ultimate flexibility shouldn't hold back the evolution of the default Drupal "product," and the default "product" shouldn't force its own requirements onto every other Drupal site. If we're willing to draw the line between the two, we can let them grow in tandem.

Who will fill the gaps?

The idea of making Drupal's out-of-box experience rock always sounds good on paper. But If we start tailoring it to a specific use case, what happens to everyone else? Single-user blogs, enterprise intranets, virtual stores, and online magazines all ues Drupal. Would their needs be overlooked?

For the past five years, the Drupal community has gone through waves of enthusiasm and disappointment over Installation Profiles and Distributions. The promise of downloading a copy of Drupal pre-tailored to your use case is hard to ignore, but today's reality is that building and maintaining a purpose-built distribution is hard work. I believe that the priorities outlined in this document will make that process much easier: improved context management and web services reduce the overhead of building great web apps; unique IDs and a reliable import/export framework will make capturing essential configuration in an Install Profile far less problematic; and a good library of UX patterns will help ensure that core tools can be effectively reused.

Finally, I believe that our long-time insistence on keeping Drupal's default download as generic as possible has actually made the difficulty of customizing it far far worse. Useful reusable tools are often left out of core because the "default profile" has no good use for them, and what assumptions are made about Drupal's out-of-box use case must be overridden with complex workarounds for other applications.

If we accept the idea that the default install profile is a product worthy of attention in and of itself; if we begin to implement features in that profile that can't baked into every other Drupal web site; if we commit to using our own core APIs the way other Install Profile and Distribution developers must use them... Then the process of enhancing Drupal's default product will actually clear the way for other products and other markets. That's what Twitter discovered when they built their API: until they treated Twitter.com as a web application built on top of their API, other users of their API would always be second-class citizens.

I Love It When A Plan Comes Together

That was a mighty wall of text. After all that, where are we? Is there a plan to be found? I say yes. In Drupal 8, we should prioritize:

Missing APIs: Some of Drupal's most pressing blind spots could be filled by providing a unified "Context" system and exposing all Drupal entities via a RESTful interface.
Deployment: The pain of managing, deploying, and sharing Drupal solutions can be dramatically reduced with universally unique IDs for all Drupal data, and a standard system for importing, exporting, and overriding those items in code.
User Experience: The work in D7UX can be extended by documenting and simplifying the use of common UX patterns like color pickers and draggable blocks, while a streamlined "Focus on the post" theme would act as a compliment to Bartik's swiss army knife.
A Real Use Case -- Tailored to an actual audience, Drupal's default install could empower users with no site-building experience, free the drupal UX team from the tyranny of one-size-fits-all workflows, and reveal areas where our assumptions are crippling other solutions.

None of these items are simple -- each one would be a huge undertaking for any development team. Over the past decade, though, our community has proven that it can do amazing things. Teams of passionate developers, designers, and UX experts have already been working on many of these tasks: working with this plan would simply highlight and prioritize the work that's already going on.

In addition, coordinating efforts between these three major areas will help bring balance and a compelling narrative to the Drupal 8 development cycle: outside observers will know what we're shooting for, why it matters, and what the promise is for those outside the Drupal development club.

This is where I'll be focusing. How about you?

Doubt: The liveblog

2010-09-21T00:00:00-05:00

0:00 - Welcome to the movie 'Doubt!' It's lookin' like the 50s or 60s. Drama took a while to get moving in those days.

2:30 - Kids playing outside. Uhoh. Kid mentions to his neighbor that he's an altar boy. Totally different implication now.

5:00 - And... our first Phillips Seymour Hoffman sighting! He's preaching about the Kennedy Assasination, a nice timecheck. He's talking to people about isolation and loneliness and doubt. It is a suspiciously Willow-esque sermon.

7:30 - We have our first nun head-smack! Meryl Streep, keepin' the kids in line. Priest says, "Doubt can be as powerful and sustaining a bond as certainty: when you are lost, you are not alone." Nun looks unhappy. Dun-dun-DUNNNNN. She probably didn't like Blue Like Jazz, either.

9:00 - Kid confides in Father whats-his-name that he wants to be a priest. Kid and priest share a quiet moment of friendly interaction. Priest gives the kid a present. OH GOD MOLESTOR

10:00 - Innocent nun-caught-in-the-middle. In our first scene with her, she's waking up in the middle of the night. Clearly something is weighing on her.

10:01 - Or not? Nuns just wake up really early all the time, I guess.

She's a teacher! Totally looks like a wet-behind-the ears newb nun, and the kids are acting up in class. Maryl Streep nun walks in, and they snap to attention and stand up. I'll bet she chooses one to publicly kill each year. She grabs a kid who was listening to a radio, drags him out. Everyone looks nervous, like Zebras trying not to talk about the lion that just took Ned.

15:00 - Nuns! Eating dinner! It is a very quiet dinner.

17:00 - Dinner with nuns, still very quiet. OH CRAP maryl streep is ringing a bell. Asks the other nuns what THEY think the sermon about 'doubt' was about. Conclusion: she is a hardass. Or she totally knows he's a child molester.

20:00 - Meryl Streep is the House of the nunnery. "William London would set his FOOT on fire to escape half a day of school," she says of one student Takes the newb nun under her wings, explains how things work. "You are responsible to ME. I am responsible to the mon signor, and the bishop, up to the holy father." Throws away the newb nun's box of cough drops (they're like candy!). She points disapprovingly at a ballpoint pen. "Penmanship is DYING across this country!"

God, this is like listening to Andy Rooney.

24:00 - Uhoh. Father seymour is teaching kids basketball. Stops the game, starts lecturing kids on cleanliness and not having dirty nails. God, the creepyness. "Look, my nails are long, but I keep them clean. I like 'em long. But that makes it okay." Ooooooookay. You just go like it long, man.

There are strange weird subtexts as the kid who wants to talk to the father gives the priest glances and searching looks. Donald, his name is. "Donald, please go to the rectory."

28:00 - OH SHIT NEWB NUN SNOOPING IN THE PRIEST'S LOCKER. I... wait, what? OOooh. I see. Newb nun saw priest snooping in a KID'S locker, then snooped in in it. Which means... Ah, geeze. Priest sniffing kids' shirts. This is like Livejournal.

30:00 - "This parish serves irish and italian families," says the old nun. "Someone will hit Donald."

"Donald... has a protector. Father Flynn." Maryl streep pauses. Ice fills the air. "He's taken an interest."

Ominous music. Maryl Streep's eyes go cold.

33:00 - Father Flynn chatting comfortably with the kids. They're having milk and cookies and he's talking to them about girls. Catherine: "HIS NAILS ARE SO CREEPY."

36:00 - Conspiracy of nuns: A CHALLENGER ARRIVES. I'm ... creeped out by the vibe of the nuns all knowing without saying it that they have to keep an eye out for pedophile priests.

42:00 - Nuns-and-priest conference. Christmas conference being discussed. "Frosty the snowman espouses a belief in PAGAN MAGIC. I... may I ask what you're writing down with that ballpoint pen?" The glove is being thrown down. Battle of the wills. Father Flynn is talking about how the church 'needs to change.' Maybe sing some songs from the radio. Be friendlier. TAKE THE BOYS ON A CAMPING TRIP OH GOD MOLESTER

45:00 - she manuevers the conversation to Donald Miller as she manages to maneuver the father back around the other side of her desk. She's adjusting blinds, putting the sun in his eyes. God, it's like police interrogation.

Father Flynn is being shifty. A telephone is ringing. Meryl Streep doesn't answer it. "I object to your tone," he says. "This isn't about your tone. I want to know WHAT HAPPENED IN THE RECTORY."

The ambiguity of it is fascinating: clearly two carefully constructed narratives, one in which a new and (relatively) liberal priest engages with his congregation and his students and faces attacks from suspicious traditionalists... or, alternately... oldschool nun who cares, trying to outsmart a predator.

53:00 - "You honestly find this school to be run like a prison?" "Well, no. But. All the students are uniformly terrified of you." "Yes. That's the way it works."

54:00 - Father Flynn preaches a sermon about gossiping. Oh, way to use the bully pulpit. Streep watches from her pew, steely-eyed. Newb looks tormented.

57:00 - Pastor Flynn talks to newb nun. She doesn't trust him. He's extending an olive branch -- OR trying to drive the wedge between her and the hardass nun. Argh, the drama!

60:00 - First encounter with Donald since these revelations. Outside class, in class. The kid seems tormented. Now Donald's mother appears at the school to talk to the nun. She's a very smart, canny operator. And she's slowly, carefully, trying to build a case against Father Flynn. Every facial tic, every weighted pause, feels like a clue in an unfolding murder mystery.

Nun tells mom she's concerned about the relationship between Father Flynn and Donald. "He may have made advances on your son." Oh God. The dominos start falling.

"I know I am RIGHT." Ai yi yi.

75:00 - Oh god. Fuck. This is bad.

77:00 - Hey, look, it's the murderer at the door, and the nun won't lie!

80:00 - "You will tell me what you have done!"

85:00 - And see, this is why I don't like the sacrament of confession. It's like the metafilter thread all over again!

I'm on team Edward

2010-08-19T00:00:00-05:00

Just smile and back away

2010-05-13T00:00:00-05:00

About a year ago, I was on a flight returning home from New York. The plane touched down and the woman sitting next to me whipped out her cell phone and dialed instantly. That's not odd in and of itself, but the conversation that followed was a little uncomfortable.

Apparently, her boyfriend had been told that she'd be returning that evening. And apparently, she thought he would be picking her up from the airport. As best as I could make out from her side of the conversation and the muffled squawks from his, he didn't get the message, and was out having a good time with his buddies. He had no intention of changing those plans, see, and perhaps she should get a cab. Oh, but no! She knew he had gotten the message. Clearly, he had ignored it, and was he really serious about things? Is this how anyone would treat someone that they really loved? Like he'd said last week?

It only went downhill from there. I generally try not to eavesdrop, but... well. You're jammed in next to someone, and you're waiting to stand up and get your luggage out of the overhead. It's hard not to notice the relationship flame-out in progress. The best you can do is make eye contact with the rest of the people around you and hope that it doesn't get worse, you know?

So, yeah. That's what this whole Apple/Adobe thing is like.

Sort of Invented Here

2010-03-03T00:00:00-06:00

My work with Lullabot involves a lot of teaching and training. We've invested a lot f time and resources in becoming experts, but there's more demand than we can fill: as such, "teaching people to fish" has been part of the company's mission since it was formed.

We've been really fortunate, in that all of the Lullabots have been passionate, eager folks who love sharing their knowledge. We've all had a lot of opportunities to collaborate on how to best train others to use Drupal, and we've gotten a lot of experience under our belts over the years. This year, we've been working on taking things up a notch by hiring more dedicated trainers, building more curriculum to cover additional topics, and making it easier to customize the kinds of courses we're able to give. Being a huge fan of systems -- I couldn't resist the opportunity to jump in and work on it!

It's been a really fascinating opportunity both to improve the work that we do, and to learn about the existing science of curriculum design and education. @emmajanedotnet's recommendation of Developing Technical Training: Third Edition was worth its weight in gold, for example. That book perfectly captures a lot of key ideas that we've iterated our way into, but gives them context and supporting structure. Is it Chomsky who says we can't really understand a concept until we have some way of expressing it in language? This book gets me over the language hurdle, offering an existing conceptual framework for describing and building curriculum so I don't have to hash my way through that process. Instead, I can focus on the curriculum itself: the real meat of what we're great at. Yum!

The whole process has me thinking about times in my life where I've missed out on opportunities to learn from others' experience. I like to think that I'm a creative person, and like most software developers I enjoy building new stuff from scratch. That can easily lead to a sort of de facto "Not Invented Here" syndrome, where existing solutions aren't rejected so much as they're never even noticed.

I'm reminded of Robert Prisig's classic (and often-snarked-at) book Zen and the Art of Motorcycle Maintenance. Some of my favorite parts of the book are about the difficulties of teaching complex and nuanced subjects -- explaining the idea of Quality to writing students started Pirsig on an epic philosophical quest. He agonized, sacrificed, even alienated his loved ones in an attempt to figure out some really complex and difficult questions. In the book, he looks back on certain parts of that process ruefully: he spent a lot of time thinking that he was charting new ground, and years later discovered that he was only rehashing what other philosophers had done far earlier.

He viewed it (if I remember correctly) as a sort of "freshman error," a mild narcissism that can blind us to the fact that there are many other very smart people trying to figure things out -- that we're probably not the first ones to grapple with a particular problem. That resonated deeply with me: I've gone through the same epiphany/forehead-slapping cycle myself. "Aha! I'm a genius! Oh, wait... someone else figured that out a hundred years ago, and wrote a book about it." The flip side, of course, is that the process of grappling with a complex problem is its own kind of learning. Jogging, by analogy, isn't just about moving from one place to the next: a car would be more efficient, but wouldn't build muscle.

I'm trying to explore a middle ground in my life these days. When faced with interesting and complicated problems, I enjoy diving in and trying to figure things out myself. But I need to pull in outside knowledge as well, and do it early rather than late in the process. That doesn't mean I can't do the work myself, but at the very least it keeps the ego in check. There are smart people out there, it reminds me, and they always have insights to offer.

An exercise in learning, and humility

2010-02-11T00:00:00-06:00

There's an interesting discussion going on at MetaFilter about confused Internet users and the mistakes they make. It's full of laughs and full of arguments about iPads and Google and UX work, but one comment stood out to me:

"...How hard is it to understand what a browser is and what a URL is and how to use a search engine?"

The answer, in my opinion, is "Really, really really hard." The problem isn't that those individual things are tough to tell apart, or that a "menu" is inherently confusing or that it takes too many steps to copy a folder from one disk to another or anything like that.

The problem, at the end of the day, is that learning to use a computer is something like learning a complex new language. There there are thousands of little things to learn that are both subtle and irrelevant. Irrelevant, that is, until the moment they're important. And at just that moment, the fact that think a "Bookmark" and a "URL" are the same thing will cause you a world of pain.

The longer we spend with computers, the more difficult it is to capture that "beginner's mind" when communicating with others. One exercise that I've found useful is the simple act of writing out an explanation of a computer-related concept. That sounds easy, but there's a twist: if your explanation refers to other computer-related concepts, you have to explain them, as well. In addition, if your explanation glosses over important distinctions that could confuse the listener later, you have to note it.

"A web browser is a program that lets you look at information on other computers around the world."

What kind of information? ("Well, technically HTML files...") Can a web browser look at movies? ("Sure, as long as you have a plugin--") Wait, what's a "plugin?" ("It's another program that plays movies inside the browser.") My nephew told me Youtube doesn't need that. ("Only if you're in the HTML5 beta!") I don't think I am. Can other people look at information on my computer with a browser? ("No.") My nephew said I could look at his computer with it. ("Oh, well, he might have a server on his.") What's a server? ("Do you mean a computer that's a server, or a program that's a server?")

You can see where that's headed. The closest most computer experts get to this kind of disorientation is when they learn a new language, framework, or toolset. All of their old mental models turn to baggage, and they have to carefully feel out every answer for hidden assumptions.

The idea behind the exercise isn't to follow an infinitely deep rabbit hole while writing a simple explanation. Often, quick summaries are useful because they give people some important mental anchors. The important part is to remember just how immense the cloud of supporting ideas is -- and to have patience when talking to people who haven't yet absorbed enough to know what they need to know.</em

CMS Expo 2010: It's like a clown car full of Drupal!

2010-02-09T00:00:00-06:00

Last year I had the privilege of speaking at the Chicago CMS Expo, a yearly event that brings together experts from a variety of open source communities for learning and collaboration. In 2009, Joomla!, Drupal, and Plone folks had some great training and education tracks as well as interesting business sessions for the suits.

This year, WordPress has been added to the mix and the Drupal track features quite a few community luminaries. I'll be there in May along with Larry Garfield and Colleen Carrol of Palantir; Emma Jane Hobgin, co-author of Front End Drupal; Doug Vann and Matthew Lechleider; and Volacci's Ben Finklea. I've also heard a few rumors that a big name in the Drupal universe will be talking about the future direction of the platform... The list is pretty impressive and I'm looking forward to connecting, teaching, and hanging out with folks from various CMS communities.

If you're in the area and are interested in kicking various platforms' tires, it's one of the few events where you can hear experts from several CMS communities, rather than a few token visitors at an event dominated by one product. In addition, CMS Expo's banners are a pleasant, soothing shade of aqua. Check it out!

Regarding the iPad

2010-02-01T00:00:00-06:00

My life at this point is basically a nonstop firehose of Skype calls, delicious links, SSH logins, and googlefests culminating in presentations in strange office parks. I live in the cloud. My music, my photos, my todo lists, my notes, my travel arrangements, my Christmas list, and my pants size are just chilling out there in a distributed fluff of XML. So, yeah, on that level the iPad with a copy of Keynote for presenting and a bluetooth keyboard for server wrangling sounds like the best thing since ever.

On the other hand, I strongly believe that people who write paragraphs like the one I just wrote should be punched in the junk, over and over, until they buy potable water for a village somewhere.

So, conflicted.