The last part of these series briefly discusses some things I keep in mind when maintaining a site after launch, some things I document for anyone charged with adding and updating content on the site, and some good things to keep in mind with regard to user feedback. Hopefully these tips will help you maintain and expand your project beyond the initial launch, and allow you (with the help of user feedback!) to improve the site long after it goes public.
Site Maintenance
Once a site is live, it will still need to be maintained at some level. If you use a content management system like Omeka or WordPress, you will need to keep up with software upgrades and bug fixes, and apply those to your site as needed. Subscribe to the news blog or email listserv for your particular CMS to keep up-to-date with new releases and bug fixes. For projects at CHNM, I’m subscribed to listservs and blogs for WordPress, Drupal, bbPress, and a variety of plugin comment threads.
When upgrading software, I find it best to perform the upgrades on a copy of the site in a undisclosed folder on your server. If you have a development server, use it. Or you can perform upgrades and maintenance on your local computer if you’ve set up a web development environment on it. (I detail how I set up my web development environment on my wiki.) Of course, be sure to backup any files and databases when performing upgrades.
Documentation
In addition to maintaining the software, you’ll need to provide ways for your content team to continue maintaining content on the site. If your website requires regular content updates, and if you expect the site to be relevant and sustainable long after development is done, its prudent to create some documentation for how current and future members of your project team can update the site.
A styleguide is particularly useful for advising the content team on proper markup and formatting for site content, and for future designers and developers who may have to do more significant upgrades to the site’s design. The styleguide at the New York Public Library is a perfect example. It outlines the DOCTYPE that webpages on the NYPL website should use, proper markup for things like headings and lists, and how to use/modify CSS on the website. You could easily write something similar for your own site, assuming you made some concrete decisions about layout, typography, and colors during the design and development phases. You did that, right?
User Feedback and Community
After launch, its good to provide some means for direct user feedback. Despite all the planning and testing prior to launch, user feedback is vital to the sustainability of a site and ensures you can adapt your site to the needs of your visitors. Also, it provides a way for users to contribute to the life of the project. Hopefully you can build a regular group of users vested in the success of your project, and recommend it to others. User feedback can come in several forms, from suggestions for improvement to troubleshooting. Methods for soliciting and managing feedback can depend on several factors:
- How much feedback you expect
- How much time/how many people you have to deal with user feedback
- How public you want feedback to be.
At the least, you should provide an email address for users to content for site errors and general questions. If you find yourself dealing with the same questions regularly, though, it would be beneficial to create a Frequently Asked Questions page on your site. You could then funnel inquiries through that page, and if a user’s question isn’t addressed in that FAQ page, they can then continue to some other process for feedback. This saves time for both you and your users.
More robust forms of feedback could involve setting up a separate section for forums, in which individual users can have accounts, post questions to a forum, and have admins (and other forum members) respond. CHNM uses this on Zotero and Omeka. Omeka in particular uses a free software platform called bbPress, from the makers of WordPress, to power its forums. We set up forum topics for different areas to focus conversations and make it easier for users interested in similar aspects of the project to interact.
With some of the WordPress plugins I’ve helped develop, I rely on the WordPress forums for user feedback and assistance. I subscribe to the RSS feeds for the ScholarPress Courseware tag, and try to respond to posts there whenever I can. One of the great things about having the support forum there is that other WordPress users can (and do) respond to posts about plugins I help develop. If the code for your project is hosted elsewhere, check if those repositories can also help you set up space for user feedback.
Indirect feedback is also important. This kind of feedback includes blog posts, Twitter messages, and any other things written about your project. Its good to keep up with this activity, and respond when useful, because you should be actively interested in how your project is received by others and encourage others to write about your project. For example, I get Google alerts email for any news and blog posts that link to the Omeka website, I subscribe to the RSS feed for tweets that include “omeka,” and I subscribe to the RSS feed for the delicious tag “omeka.” There are a few others, but the point is to find a few social app and services, see if people using those services are talking about your project and connect with them. Humanities scholars should see the importance of indirect user feedback and engaging with that feedback. While its great to get people to ask you questions at a conference, its also great to have people cite your work in their own scholarship, write reviews of your work, or recommend your work to their colleagues. Being able to track this kind of feedback, and follow up on this feedback when warranted, is an important part of tracking the impact of your project across a variety of audiences on the Web.
Wrapping Up
That’s it! I must apologize for the time it took to complete the series. I hope the series has been useful nonetheless, but I also hope that you take anything I’ve outlined and modify it for your own needs. This is a good process, but its also good to adapt to the changing needs of your project, your team, and your users. In the end, those are the most important things to consider when framing a design and development process for your project.
[...] Jeremy finishes up his great how-to series on design process in the digital humanities. [...]
Thanks so much for this fantastic series. I have learned so much, and this will be an awesome resource to have new team members read.
Happy to help out Karin!