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.
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:
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 RequirementsFor 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 InterfacesTo 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.