Doc Searls Weblog

Sixth in the News Commons series.

The Big Calendar here in Bloomington is one fed by other calendars kind enough to syndicate themselves through publishing feeds. It is put together by my friend Dave Askins, who writes and publishes the B Square Bulletin. Technically speaking, it runs on WordPress, and uses a plug-in called ICS. Dave is steadily improving it, mostly by including more feeds. But he also has a larger idea: one that satisfies the requirements I’ve been outlining in posts about deep (and deeper), wide, and whole news, plus a community’s (and journalism’s) need for facts and not just stories.

What Dave suggests is a whole new platform, just for community calendars. He calls it DatePress (modeled on WordPress), and describes it this way:

A bigger idea for community calendars

WordPress is a fantastic platform for running all kinds of websites—from news sites that generate lots of chronological posts, to websites that are mostly static, and serve up encyclopedic information.

For added, very specific functionality, WordPress fosters a robust ecosystem of plugins.

But there’s one kind of plug-in that is worth developing as a platform in its own right: a feed-based calendar. What if the whole point of the website is to host a feed-based community calendar? Such as this one here. We can do that with the WordPress ICS Calendar plug-in, as we do at that link. But why use a plug-in to do a platform’s job?

DatePress

Let’s call this as yet undeveloped calendar platform DatePress, just as a placeholder. DatePress would be a calendar hosting web engine that is built from the ground up to host feed-based calendars. Maybe some enterprising soul develops a plug-in for DatePress that allows a user to add a blog to their calendar. But the one job for DatePress would be: Publish community calendars.

DatePress does what?

What kind of functions should DatePress have?  For starters, it should have the kind of features that  the WordPress ICS Calendar plug-in already includes. Specifically:

• It should be easy to add feeds to a calendar, and specify a background color and  label for each feed.
• The published display should include ways for a visitor to the published calendar to filter by typing into a box.
• The published display should make it possible to add any individual feed displayed by the published calendar to their personal calendar.

But there should be so many more tools for calendar administrators..

• For any calendar feed, it should be possible to add a prefix to any event title in a specific feed, to help people who visit the published calendar understand what kind of event it is, without clicking through.
• For any calendar feed, it should be possible to assign multiple tags, and it should be possible for calendar visitors to filter by tag.
• For any view that a visitor to the published calendar generates with a filter, the parameters for that view should be passed to the URL window, so that a visitor can send someone a link to that view, or embed that specific view of the calendar in their own website. That view should also define a new feed, to which someone can subscribe.

DatePress itself should know all about the content of feeds:

• Duplicate events across feeds should be automatically identified  and collapsed into a single event.
• When a feed is slightly non-compliant with the standard, behind the scenes, DatePress should be able to convert the feed into one that is 100-percent compliant.

Why does DatePress need different levels of logged-in users, which really demands that it be a platform? Here’s how that looks:

• Only some users, like the administrator, should be able to add or delete feeds from the calendar.
• A curator should be able to manually flag events across all feeds—and all the events flagged by some curator would define a new feed. Visitors to the published calendar should be able to look at events by curator, and to add the curator’s feed to their own personal calendar. A curator should be able to embed a display of their curated calendar into their own website.
• Annotators could add information to event displays, especially after an event is over.  After the events are over, their status will change to “archived.” Annotations  could include a simple confirmation that the event took place. Or maybe an annotation includes a caution that the event did not actually take place, because it was canceled. Annotations could include links to published news articles about the event. The calendar archive becomes a draft of a historical  timeline for everything that happened in some  place.

Let’s please build this thing called DatePress.

I think this is a great idea that can start to do all of these things and more:

1. Pull communities together in many commons (such as we study here at IU’s Ostrom Workshop) around shared interests.
2. String the pearls of local journals without any extra effort on anyone’s part.
3. Give calendar hosts a way to think of their events as part of a bigger commons.
4. Let rank-and-file residents tap the wisdom of those who are “in the know.”
5. Recruit community members to the work of making local history more complete.
6. Calendar archives could jump-start history-based newsrooms in communities everywhere.

Please add your own.

The images up top are among the best of the hundreds I’ve had Bing Create produce using DALL-E3. The prompt for these four was, “A library building with the name Date Press (spelled exactly that way) over the door. The roof and walls are calendars.” I insisted on exact spelling because without it the AI left out letters, obscured them, or added extra ones. I also separated Date and Press because it always screwed up “DatePress” when it was prompted with that as a word. And it never liked lower case letters, preferring always to use upper case. Visual AI is crazy and fun, but getting what one wants from it is a little like steering a cat by the tail.