Anarchogeek

Events & Calendars: Trumba, EvDB, and Upcoming.org

Kellan's been telling me, calendaring is hot again. Back in the day kellan and i started a company called MetaEvents to do online calendaring things. Since then we've maintained protest.net which is an activism calendaring website which runs the old metaevents code. We're in to calendaring and events when it comes to the web, but we've moved on to other projects and left calendaring an unsolved problem.

I've tried out the three current leading public calendaring plays. There are Trumba, evdb, and upcoming.org.

In my opinion all three fail to be compelling web applications and more importantly to solve the public calendaring and scheduling problem. It's a hard problem, and i am not sure what the right solution is, but i know i haven't seen it. It's a very different problem that that of a PIM or a business group / team scheduling. The majority of calendar apps are PIM focused, which is not my personal interest, as my life is not full of business meetings. I use a good old fashioned paper organizer.

Taking them one at a time.

Trumba

They provide public event scheduling and calendar publishing tools. Their system reminds me a lot of metaevents. They do many things right which we failed to do with metaevents, yet still have the same fundamental limitations. Users login, they create calendars, they publish events. There is import and export of events from a few formats. They support ical (calling it ics for some reason), excel files, and csv. They have a clear interface for publishing a calendar to be public, and have a moderately good interface for making some basic design decisions about the calendar.

They have a large, here is how you use Trumba page when you login. This is necessary because their tool is not obvious. We've debated this in Odeo and i've been trying to push the system to be clear and accessible to the point where we don't need to give users a big, here's how it works man page. The interface is basic and uncluttered. Unlike evdb and upcoming which have abandoned the wall calendar / desk calendar look. Trumba tries to do a few things well. They are not looking at living in a connected world, but are building online calendars for clubs, organizations, and the like. It's pretty easy to setup and provide a way of creating a web calendars. On the whole, the application feels stable, but there is nothing which draws me in to use it.

What trumba doesn't do. It doesn't make it easy to add event information to the calendar. This is a problem is common to all three of the new calendaring plays. It's hard to enter in information. There are many fields. It's as if calendar creators failed to notice that the rest of the world has moved to use simple interfaces even when the data and 'space' are complicated. They still make us select the date by a maze of pulldown menus. There seems to be no awareness in Trumba that a web app needs to act like a desktop app which is the essence of ajax.

A major problem with Trumba is the user who is adding information isn't valued for their time. You make them click, moving their hand back and forth between menus and text. It's a tedious process. Nobody's going to go, oh boy, what i want to do is do data entry. Interestingly, in other more flexible environments you have people who do jump up and down to do data entry. It's about the interface, the relationship between the user, collective ownership of the information, and playability of the system. Trumba supports pulling in events from other calendars, but only on a one off basis. Until there is a more automated way of doing it the merged and mixed in calendars aren't going to work.

The real area which Trumba fails is that it's living in the last century when it comes to web services. It's as if they didn't notice that delicious rewrote the rules of the game. They provide a simple import / export interface which is not ment to be used as an automated web service. No rss, no nifty ical, no REST interface, there aren't even places to put links on the calendar pages! Perhaps they didn't notice Jon Udell's critique along these lines of of upcoming.org. As long as Trumba doesn't play nice with others, their system is doomed to isolation. That's a death knell for a space where you need to get ubiquity in the events space to be useful.

EVDB

The second high flying new startup is the evdb.com. It's funded by a bunch of big name net folks including Evan Williams who i have the pleasure of working with at Odeo. The folks at evdb clearly get the web 2.0 world in ways that the Trumba doesn't. They have web services and a network world build in to their system from the ground up. There are normal calendars which populated by people adding events directly in to the system, and they have smart calendars which are build up with a fairly workable search interface. They clearly present both rss and ical versions of each page you're looking at in a way which is easy to find. They do this better than Odeo at the moment. Any search results page can quickly be turned in to a smart calendar. They have a text based interface which is clear and easy to navigate.

Once an event is in the system it's easy for all users to add information, tags, links, descriptions. The evade folks have learned at least some of what makes wiki's powerful. No page is ever in a final state, but it's an evolution where the readers are expected to add new information. This is where evade really shines. The web was meant to have an edit button. We've been trying to figure out how to add these kinds of features to odeo and in this respect evade is an example of site to copy.

EVDB also fails in a number of respects. When you go to the site, they provide nothing but a search box, and some confusing create calendar options. There is a graphic with some tickets dominating the center of the screen. Why, oh why? Expose some data, give me something to click on. There is nothing like the useful entries in to the system that 43things does with it's default and zeitgeist page. A simple search box is good, but it doesn't encourage people to explore. First off, when you go to evdb, you don't know how extensive it's database is. So do you search for california or lower haight? When it finds nothing it encourages you to add events, but it doesn't provide a useful suggestion for alternate searches. For example, there was an event in evdb for lower haight, but it was last week. The search results don't provide a good way of saying WHEN you want to search for, or to limit the results when you have too many.

The system is trying to be locative aware, but it isn't, not the way some people are doing. Geographic space doesn't divide up by legal boundaries. I don't think of myself as living in the 5th supervisors district of the city of san francisco in the county of san francisco of california of the United States of America in North America. My personal conception is that i live in the Lower Haight, San Francisco, the Bay Area, Northern California. I'll go to some place in my neighborhood for most things interesting, and also near by places such as the mission, castro, and the haight. If it's all the over in the outer mission, I'm not likely to go there unless it's really interesting. Beyond that, you have the east bay, my personal geography has oakland and berkeley being cities in the east bay i go to, beyond that is out of my stomping grounds. In terms of geographic distance, Marin is closer to my apartment than berkeley, but i never go there.

So, a good calendaring system would provide a way of at least accommodating for these kinds of geo-human environments. Physical distance is only one measure. Transportation systems and cultural divides between communities also have a huge effect on where and when i'll go some place. If we're trying to answer the question, what am i likely to do, that's important. EVDB, and trumba for that matter, doesn't provide anyway of answering that question. The geographic scoping is very basic and build upon governmental administrative units, an inhumane kind of division.

This kind of navigation style system is difficult to build. Perhaps EVDB could let users define geographic relationships. Part of why craigslist is successful is it divides up cities in neighborhoods. When I'm looking for an apartment, i can search by the neighborhoods where i've already decided i want live. Event publicity systems need to do this. If EVDB really believes in trusting the users to build out the data, they will create a way to let users tag and organize neighborhoods and geographic areas. It could be made in to a game which people enjoy tagging and adding data, especially if you allowed for consensus building and people to propose neighborhood boundaries.

This gets back to an issue where EVDB has problems. The site is not very surf-able. One reason people like to play with and add information to wikipedia is that they can wander around from page to page. This is doable in a calendaring environment. You've got a street address, slow a list of other concerts in pubs on that street by proximity. If I'm looking at what's happening at Cafe International, i'd be interested to know what's happening a block down the street at Molotov's. That kind of surfablity doesn't exist within the evdb system. Users can add links, comments, descriptions, and tags, but the adding is limited. I'm sure it'll be fixed, but right now when i click on a tag, it doesn't take me anywhere. The trick is, it shouldn't take me to everything tagged music. It should slowly walk me out from where i am to where i might go. The difficulty are the few outlier events like conferences. These are terrible things for event sites to touch. They break all the rules of normal event planning and attendance by real people. They are an alternate reality and folks will travel very far to attend them.

EVDB has a bigger problem, that's getting information in to the system in the first place. They've created this monstrosity of multipage forms. It's slow, full of menus, and generally uninviting. Nobody's going to enjoy filling out these forms. Instead of giving me a text box where i write when the event is, it has 14 form elements! That and there is no repeating event structure in evdb at all. So instead of writing the human "every Thursday at 6pm" i have to walk through this hard menu / text area system.

A good event entry system should have somebody spend some serious time in creating a parser for human descriptions of time and repeats. Then you can let the user confirm that it got it right and do a more advance tweaking if necessary. The venue page is also time consuming. Sure it's great to collect venue information, but couldn't that have been data which was already mined and preloaded in to the system. The phone book and google local know that cafe international exists, has events, and is located at 508 Haight street all with me just writing "cafe international san francisco, ca". That data should be mined and used by events aggregator sites.

It's hard to enter in a lot of data in to evdb. Lots of page loading, complicated forms, etc... I don't think many people are going to do it. That said, evdb is looking for ways to import data. They've gone around and asked a lot of event producing websites if they have an export of their calendar data including protest.net. They already have pulled in the meetup events database as well. This is a good start, but it will only get them at best a small percentage of the events in any given community. Something is better than nothing.

There are some interesting ideas at play in evdb. EVDB is undesigned and functional in the honored tradition of delicious. They have potential, but it's not a site i feel compelled to use on a regular basis. This was one of our experiences with metaevents, folks just don't want to spend that much time looking at calendars. You need to get a fairly large proportion of the events before it becomes useful to users in a given geographic or social community. Once you do get that, it's not like folks want to spend hours looking at your site. EVDB could move to providing better usability of it's site, and improve the publishing and they'd have something interesting. The web 2.0 stuff is compelling, but we still don't know what web services for events and calendars should be. EVDB has a terrible name, nobody can remember it, it's not catchy. The only thing going for it is that it's short. Perhaps evdb isn't thinking of building an end user audience and the domain name isn't important, but i doubt it.

Upcoming.org

Upcoming is different that the two other calendaring plays. It's been around for a couple of years and it's Andy Baio's project instead of a funded startup. When i first saw upcoming, i was very impressed. The calendar space had been dead for years, and this was somebody trying to experiment. He broke out of the suffocating grip of the month calendar / desk calendar layout on the web. He also embraced the production of feeds, user generated content, breaking down the lines between calendars, friends, and useful conceptions of human geography such as metro area. I was among many people who thought that upcoming would take off. It seemed that it would take off, but that hasn't happened. Recently there has been a flury of blog posts about how to make upcoming more web 2.0 / services centric. Andy has added tags, an open restful api, better search, feeds, syndication, and a new design. Upcoming is expanding upon it's interesting conception of a vertical social networking site. It's about events, but understands users as people who have relationships to other people. The site supports this nicely.

Of the three calendaring plays, upcoming is to me the most compelling. It's the most transparent, connected to the community, quickest on it's feet. Upcoming has the nicest interface, not as slick as trumba, but professional and much more useable. But i still don't use upcoming.org. Something is missing.

What Calendaring Should Be

Before we get in to the question of how to build this app, which site will win, etc... We need to ask the question, what are we trying to accomplish with public events calendars. There are two online calendars i use on a regular basis, protest.net which i help maintain to find and track major protests, and the indymedia bay area calendar to find out what i want to do tonight or this week.

What this tells me are two things. One, i'm interested a specific sub-community's events. I don't care what when other people do meetups, who's playing at a club, when the next professional sports team will be playing, or when some industry conference will take place. We live in a world of the multitude, and it should effect how we organize and use information. Despite the unified notion which television presents of society, we are highly fractured and event and planning information needs to reflect that.

So i'm interested in what anarchist events are happening in the bay area, i'm interested in the free software community, i'm interested in live music but only if it's within a couple blocks of my apartment and free. I have perfectly acceptable ways of finding out when all of those things are happening. I find out about anarchist and political events from indybay and mailinglists. There is also a monthly broadsheet printed by some punks of free events in san francisco which as a distinctly activist bent. We've got a copy of that calendar on our fridge. The free software community has blogs, meetup.com, and also mailinglists which work just fine for those kinds of events. For music, i can see the schedule on the notice board when i go in to the cafe for coffee in the morning on my way to work.

For somebody to switch from how they are finding events to a new way of finding out what to do, they need to have a compelling reason. The fact is that none of these systems are good enough to replace what we have. Many people also use the weekly newspapers to find out what's happening.

Back when we were starting MetaEvents we brought in a friend of ours who was a professor at Hampshire College specializing in human computer interaction (HCI). We explained what we were going, and what we were trying to solve. His answer as to what we should do was not at all useful to us at the time. He said, look, think about where a person is and what they are doing when they decide what they want to do. They are not at home or work sitting in front of a computer. They in a cafe, hanging out with friends, leaving a restaurant, eating breakfast, etc... In order to provide information in deciding how to spend your day, what things you might want to go do or see, you need to be able to get to the user then. At the time, 1998, this was a distinctly useless answer. Sure, it was true, but there wasn't much we could do. There weren't ipods, net accessible palm pilots, net enabled cell phones, or other similar kinds of devices.

Once we can answer that question, we can say, yes, this tool will help you find those answers WHEN you want to do it, then you'll have a compelling calendaring application.

There are ways to improve things as it is. For example, google local / maps on your cell phone which would work. Just take time and interest and add it to the local service and there you go. Also, if there was an easy way of extracting event information out of text then you could create event directories without front loading tons of user volunteering without direct benefit. Another issue, is folks need to escape from the universal calendar concept. Don't solve the problem for everybody. Solve it for specific populations. Make a good calendar for the tokyo arts scene instead of the universal events database. Communities have more interest in building themselves and providing resources to increase participation. Be they church goers or anarchists, they want to maintain and advance their community.

Why don't people do that? Because the money is in ticket sales and people have become seduced by bands and concerts. If we think of communities, understand localism, build services, create surfable minimalist interfaces, encourage users to take ownership over the information, and build tools as a network of resources not a data roach motel, then a site could be successful. None of the players today do that. Maybe eventually they will, or maybe google won't make the mistake of developing a PIM instead of a public events calendar.

I've got to get back to getting Odeo out the door and stop critiquing others.

Posted by rabble at April 15, 2005 07:17 PM