An anti-pattern, Wikipedia says, is a design pattern “that may be commonly used but is ineffective and/or counterproductive in practice.” The example most familiar to me is the password anti-pattern which describes sites that use your credentials to impersonate you on other sites. My work on the elmcity project has surfaced a few other anti-patterns, including one I call the submit-your-event anti-pattern. On websites with events pages, every invitation to send in event information by email, or to type it into a web form, is an example of this anti-pattern. Why? It breaks most of the seven habits of highly effective web citizens, especially #1 (“Be the authoritative source for your own data”) and #2 (“Pass by reference not by value”).
The pattern I recommend invites sources of event data to submit it by publishing feeds, and aggregators of event data to acquire it by subscribing to feeds. Since the legacy forms-based method has such deep roots, you might want to keep it going while offering the feed-based method as a preferred alternative, like so:

The submit-your-event anti-pattern is being rolled out in a major way at Patch, AOL’s foray into local news. On every events pages, like this one for East Providence, RI, Patch invites you to sign up, log in, and populate its database. I had noticed this in my travels through the eventsphere, and thought of it again when I read Ken Auletta’s (paywalled) New Yorker article this week, which profiles Tim Armstrong’s mission to save AOL by building a network of local news hubs. Here was the inspiration for the Patch events service:
While he was at Google, Armstrong had his revelation about local news. One Saturday morning in 2007, he and his children were driving home from a bagel store half a mile from their home, in Riverside, Connecticut. At a stoplight, they pulled over to look at the hand-lettered signs that residents had stuck in the grass to advertise local events. There was no online listing of events in Riverside, and the Greenwich Time lacked a calendar. Armstrong called the newspaper and introduced himself as a resident and told an editor that the paper was missing out on a terrific business opportunity.
“We really don’t need any help. We have a fine business,” the editor told him, before saying thanks and hanging up.
This was crazy, Armstrong recalls thinking. He lived in one of the wealthiest towns in America, yet he had to drive to a stoplight to find out what to do with his family.
I had a similar revelation back in 2005, when I walked around Keene, photographed all the event posters on shop windows and kiosks, and compared the results to listings in print and online. The posters collectively told much more about goings-on in town than did any of the listings, or indeed all of the listings combined.
A few years later, I came to a very different conclusion than the one Armstrong reached. The kiosk-and-shop-window system was outperforming the web because it was, in one crucial way, more weblike than any existing web-based events system. You don’t have to ask permission to post flyers, you just post them where they can be seen by everyone.
Imagine if the web used a submit-your-web-page anti-pattern. To post a page to the web you’d visit a site, register, log in, fill in a form, hit submit, and wait for approval. Well of course you can’t imagine that, because there wouldn’t be a web if things had to work that way.
To work as well as the web, the eventsphere has to work like the web. If you have events to promote, you post them to your own site. That’s the authoritative source. The information is displayed there as text for people to read, but is also available as data for people and machines to syndicate. Local media hubs don’t get to be the exclusive owners of a database of events because there is no database of events, there are only feeds from authoritative sources. They do, if they’re savvy web thinkers, get to play a preeminent role in the eventsphere by inviting contributors to light up their feeds, and by offering rules and tools that help contributors manage them.
I’d be interested in your thoughts on DC Tech Events (and some other sites I’ve launched on the same platform).
http://www.dctechevents.com/
In your language, I’d say it *supports* the anti-pattern, and encourages the pattern.
Yes, it does exactly what you say: support the anti-pattern but encourage the pattern!
It’s not immediately obvious because you need to register for one of the hubs to see it. I registered with the Ann Arbor hub just to see what you meant. Here’s a picture that illustrates for those who are not registered with an Event Grinder hub:
http://jonudell.net/images/event-grinder-submit.png
Nice!
“Imagine if the web used a submit-your-web-page anti-pattern. To post a page to the web you’d visit a site, register, log in, fill in a form, hit submit, and wait for approval. Well of course you can’t imagine that, because there wouldn’t be a web if things had to work that way.”
Well said.
Perhaps a refinement of the event posting useful, to help to match a users expectation about posting details for a particular event.
After submitting an ical feed, the
current events would be fetched and the user could select a particular event, or to include all events from the feed.