In two years at my association I have been involved in two website development projects. The first spent almost two years in development but ended without an actual launch, while the second took about a year of development ending in a successful launch. Through these experiences I gained some valuable insight on what goes into creating a robust social networking site for an association. So in response to Brian Birch’s Anatomy of a Web Launch post on Acronym blog, here is my bit of advice.
A bit of background, the website we launched was aimed at bringing the association’s community together through online groups. The association has over 75 geographical chapters and 20 Special Interest Groups as well as a total membership of over 12,000 members and 130,000 registered website users. The second web launch was a site built on Drupal that leveraged its Organic Groups module for each of its chapters and SIGs. Each group could create content such as blogs, forum threads, events, and pages that its members could subscribe to. Prior to this each group had a Moveable Type blog and a mix of listservs and forum to meet online.
While I was not the project manager when development started, I inherited a portion of it a few months prior to launch. My role focused mostly on testing the site and migration of content from the previous site. Shortly after launching the site I had come to the realization that you cannot please everyone. While there was a great deal of conversation with the volunteers who would be using the site to manage their chapter or SIGs online presence, it was impossible to get the functionality that everyone wanted. These groups were spread out using many different blogs and listserv software so it was difficult to get all the features that everyone was used to.
To help ease the transition there are a few different things that can help. One thing we did was provide webinars for our volunteers that would be managing these groups. Run through the different features and make it clear what functionality would be available to them. Make it clear what is there for them and what is not there. Promising functionality that is not there will lead to headaches down the road when groups have moved their online presence and are unable to keep up the type of presence they are used to.
Another issue we ran into was permissions for all these groups. The decision was made to let each group pick their permissions level. Each type of content like a blog or event could be set to allow the public to view it, only group members, or members only. This can cause confusion to everyone who visits the site. For example, instead of each group having the same permissions level, each question that comes in from a site user asking why they cannot join a group or view content you will need to check their membership level and also what permissions are set for the group they wish to access to determine if it’s an error or just a visitor trying to view a members only group. While the permission levels for each group is viewable, you will still run into these questions from infrequent website visitors.
This is just a small bit of insight into a very large project. Hopefully it provides some useful advice if you are in the midst of a web launch. I would be happy to discuss this further and offer more insight, just post a comment or contact me with any questions.
