James Brown, Brendan Hickey, Kim De Mora, Randy, Meagan, Tom, and myself have talked a lot about what features we want the igem2007.com site to have. I have about 15 pages of scribbled notes and drawings exploring and defining these ideas with various degrees of clarity, but nothing that ties them all together. So I'm going to describe each of the main features we want separately, with the hopes that doing so will make it easier to tie them all together afterward. And because this is a blog, I'm going to describe each one in a separate blog post, mostly so that it will be easier to comment on specific ideas, but also because hey, blogs are supposed to be bite-size.
Structuring Team & User Data: Team Portal pagesOne of the main focuses of the new site is on dynamic content. The main page is a place that everyone in the community should want to frequently visit because it provides an instantaneous snapshot on the state of the community. To that end the site must be built so that the content users and teams put online can be aggregated automatically into composite pages like the main page. Last year we required the teams to build at least one page on our wiki to represent themselves to the community, and encouraged them to put up much more content - but we left the organizational scheme up to them. The content and structure each team settled on was often similar, but never the same, and so a fair amount of effort was required to find the same information for different teams.
So, the new site will feature a Team Portal page for each team, dynamically generated from content teams upload via specific forms or perhaps even wiki pages (marked up using microformats so we could scrape the pages?). Here's a list of specific pieces of content we will want from each team:
- Team name (short name, long name, official name)
- Team picture (800px wide)
- School logo (128px x 128px)
- Project Abstract
- list of links to main wiki pages
- Elaboration of Project description, updates
- Etc. ( other favorite links)
- Team Blog
I believe that part of the problem with the team wikis last year was that there was a general ambiguity about what was to be done with them. Teams knew they had to put something online, but there were no clear or specific guidelines as to what it was we wanted or how to do it. It's the structured data problem again. So in a lot of cases, those teams that did use the wikis ended up using them for two purposes: for project management, i.e. scheduling and posting the results of experiments, and for telling the team's story, i.e. introducing the members and giving the background and progress of their project. I think the wiki is an ok way for teams to get this content online, but we have to be help them be more intentional about what information goes where.