Wombat Mobile I should be coding or sleeping instead of this...

Some of you have already heard this from me, but I wanted to open this up to more people and get some additional opinions. So instead of emailing everyone I know I thought it would be easier to reach people by just blogging about this. (and since no one seems to use email anymore :) So far, opinions have been split, so I wanted to get a bigger sampling.

The Background
I've been thinking about how much of a pain it is to get everyone together these days for things like group dinners, LAN parties, movie nights, CafeSFs, local tech talks, etc. We've often had ideas for getting together, but when actually trying to coordinate it, there's often too much inertia and it never happens. Sometimes the problem lies in scheduling difficulties and sometimes the email discussions just lose momentum. So I'm curious as to whether this is something that could be coordinated online and made more efficient beyond the event/meeting tools currently out there?

Here are some of the things I jotted down that might be useful in a tool for this:

• a collaborative calendar
• rsvp functionality
• more power for the group, with less onus on the host/event initiator
• rss feeds so that those interested can subscribe, instead of spamming everyone
• event-based, to avoid having to define overlapping or subset groups of friends
• the ability to decide how public or private the event would be by who receives the event url (emailed to friends or posted on a blog)
• deploy a site that could be rapidly revised to evolve as we go along

So I cobbled together some prototypes from pieces of apps I've written in the past to convey the concept. I've gotten a lot of great suggestions from a handful of people so far (especially from kwc), and it's now on the 4th iteration, but I'm looking for more input. The latest prototype can be seen at the URLs below. The underlying code needs to be cleaned up, but everything should work, so feel free to play around with it.

Sample Event #1:
http://gefilter.com/6bSWzR
(event in scheduling mode)

Sample Event #2:
http://gefilter.com/9jMnvy
(event in rsvp mode)

I'm almost to the point where I'm happy with the concept and I can start cleaning the code up, but there are a few issues where opinions have been strongly divided and I wanted to get more feedback from a larger audience on a few things:

1. User-accounts vs. open participation - This is probably the biggest issue, and people have taken both sides. The first few prototypes didn't have a user account system, and I wanted to make things really easy and totally open, like commenting on a blog. The idea was that among friends, there would be a wiki-style trust and people wouldn't mess around with impersonation and date vote tampering. The whole Read/Write web thing.

But I also understand the argument for a slightly closed system with user accounts, which allows for more customization, privacy, and nice features like "My Events" and easier ways to create get-togethers with the same people.

On the other hand, it's a pain signing up for yet another account on a website. Years ago, when I wrote the login/membership/subscription section of mcafee.com, I wasn't happy with the decision to make everyone sign up for an account just to see the rest of the site. I got to see on a large scale how many people dropped off when confronted with "please login/register to continue".

Hmm, but there's also the problem of how to keep a gathering small which might hard to restrict without accounts.

Well, as you can see, I'm very torn on this issue and would be interested in any opinions.

2. Pure html vs. AJAX/DHTML - The other issue of contention is the browser experience. The initial concept was for really lightwight, pure-html pages, but many people suggested a more interactive UI with AJAX and DHTML. I've added some DHTML and AJAX XMLHttpRequests to the calendar in places that made sense, but there's a lot more I can do if I decide to go full-on with a beefier client. What do you think? Do you prefer a thin or a thick experience on the browser?

Which direction?
These issues are part of a larger dilemma that I have, which is, would you rather see this tool be built with a Web 1.0 or a Web 2.0 approach. For example, I'd love to make this thing easily integrate with everyone's blogs as well as make it work with iCal and Event RDF, but I don't know if enough people I know would use this to go in that direction. I'm really more interested in what you guys would find useful than trying to cram in as many trends as possible (semantic web, AJAX, read-write web, APIs, etc.)

One of the benefits of a Web 1.0 approach would be fast and familiar development. I can probably recycle code that I've used a dozen times before in different apps. One of the benefits of a Web 2.0 approach would be easy integration with other sites and an evolving online world. A potential downside is a misdirected focus and losing sight of making a tool that truly addresses our needs.

I realize that the two approaches aren't mutually exclusive and things will evolve over time, but I want to make sure I start with the proper focus now, since it might be harder to change down the road.

Oh yeah, the name Gefilter Fish doesn't have any significance. It's just a domain name I had planned to use for a service to filter and translate web sites for small screen devices (filtered Babel Fish), but I never finished developing it, so it was just sitting around.

Holy crap, this was way too long. Sorry about that. I'm done.

So what should be done to make this tool useful? What would you do? Let me know what you think at wombat@wombatmobile.com or leave a comment here.