At the conclusion of Deeper in .NET, in Milwaukee, I got to hang out into the wee hours of the morning with Scott Spradlin of INETA, Chris Barwood, Julie Lerman, Brennan Stehling, and Doug Rhoten (photos) at the Rock Bottom Brewery. Doug Rhoten is the founder and President of the Chippewa .NET user’s group, as well as the guy who provided the nice door prizes for Deeper in .NET. Back at the Hyatt, where we were both staying, Doug enumerated the three biggest challenges he faces as an INETA event organizer. There are thousands of INETA user group leaders worldwide and presumably, Doug’s challenges are not unique.

1. It’s very difficult to identify and recruit presenters for user group events;
2. It’s tough to transfer content between sites;
3. He hasn’t figured out a really effective way to advertise events to .NET developers and other interested parties in his area. (I suggested Scoble. ;-)

In this post, I will focus on #1, an interesting problem, which is I think we can solve, together.

A Universal Problem?
Many social computing applications are "geo-aware". Sites like LinkedIn and MySpace "know" where users live, assuming such data is provided by its users. Actually, MySpace even "knows" that I’m in Canada, right now, as evidenced by banner ads that are Canada-specific and a Country field in their search form that is pre-populated with "Canada". Some social networking applications (e.g., GPS-aware) have a more specific idea of where users are, or say they are. But…

Few, if any of these sites "know" where a user will be, in the future. Actually, that’s not entirely accurate. Some sites (like MySpace) provide calendaring features that enable users to specify where they will be in the future. However, none of the sites (that I know about) bring it all together in a way that enables users to query a data store for a combination of interrelated geographical and temporal user data. Herein lies a great opportunity, I believe. Future geo-matching…

User Story 1 [partial]: Doug, a .NET user group president in Wisconsin, is planning an event for sometime between 3 and 4 months in the future. He decides on a theme: agile development. He now needs to locate a presenter of sufficient renown and domain expertise that he can attract a large number of .NET developers in the Chippewa Valley area (and optimistically, from other nearby areas) to his event.

Currently, Doug might do the following to identify a worthy speaker:

• Try… Mearch in the Dark
• He mearches "+Agile +.NET +Speaker" or some variation thereof, using MSN Search, Microsoft.com, and finally, http://blogs.msdn.com.
• He creates a list of names and email addresses of potential speakers.
• He sends a "call for speakers" email to all potential speakers.
• Catch… Post a Query
• He calls and emails other INETA organizers such as Scott Isaacs in his region for ideas, recommendations, and to determine if anyone else is in the area might be interested in joining forces and combining resources to attract the right speaker.
• He asks the most well read blogger he knows personally to solicit ideas for speakers and possibly nab a speaker’s interest.
• Finally…
• He calls or emails people he knows at Microsoft, such as his regional developer Evangelist or the INETA program manager.
• If all else fails, he might settle on a second tier speaker or change the theme of his planned event to accommodate the appearance of a top rate presenter whose appearance he can guarantee.

Does it have to be this difficult? What if Doug had a way to find and contact qualified and motivated speakers who might be planning to be in Wisconsin or passing nearby (e.g., in an airplane) in 3 to 4 months time? Such speakers do exist and presumably, most wouldn’t hesitate to visit the Chippewa valley to speak at a user group meeting if doing so is convenient for them and Doug can make it worth their while.

User Story 2 [partial]: Jim Newkirk, a Microsoft employee and world renowned expert on Agile development is planning to speak at a .NET user group meeting in nearby Chicago, IL, in approximately 3 months. Jim doesn’t know that Doug Rhoten is seeking speakers for a meeting of the Chippewa .NET User Group in that timeframe. Likewise, Doug is unaware that Jim will be in nearby Chicago and might be willing to extend his trip by an extra day to accommodate a side trip to Wisconsin.

System Requirements
For almost every social problem, there are numerous potential computing solutions. As you know, the trick to designing great social software is to make it dirt simple for data providers (the Jims) to make their data available to data consumers (the Dougs). GPS can’t solve this problem for us. We must rely upon the data providers to voluntarily and happily engage in some amount of manual data input and/or attribution.

At a high level, the system we require is a data aggregation service (and store) whose primary objective is to collect as much high quality information about speakers, their capabilities and experience, and their future whereabouts and potential availability as possible. To achieve this objective, I propose that we must provide a range of data input and/or provision interfaces and optionally, enable the third party creation of additional interfaces. The Jims are very, very, very busy people. In fact, if you are a "Jim", I can't believe that you're reading this sentence and encourage you to say, "hi" in a comment.

Different Folks, Different Interfaces
To maximize user adoption, I think that we must consider, design, and implement a range of data input affordances: manual and semi-automated, which integrate with the tools, sites, and services that data providers like Jim use on a daily basis. Then, we can design and build out a scalable and extensible data storage solution. Only thereafter should we allow ourselves the luxury of dreaming about the perfect interface for data consumers to query the system and subscribe to their queries. IOW, let's not ruin our dinner by eating our desert first.

Given infinite resources and the ability to deploy your solution to microsoft.com or gotdotnet.com, what would you do to solve this problem?

In future posts, I will propose several realistic and viable solutions of my own. If you’d like to be notified when I do, I encourage you to subscribe to my blog feed.