Research Management

(While this article is written from the perspective of a research lab manager, the discussion is applicable to any group content management situation.)

My primary goal is to get a PhD and eventually find a job in academia, so I've been thinking a lot about the best way to organize, manage and coordinate a small army of 'knowledge workers', aka run a lab. I say 'organize, manage, and coordinate' instead of 'lead' because, in my experience, it is the students who have to lead if a project is really going anywhere. The professor is still the 'primary investigator' in that he is responsible for coming up with innovative ideas and applying experience to suggest the most probably successful way to get things done, but it is up to the student to take ownership, survey the literature, organize the information, and do the actual work.

I believe it is also the responsibility of the professor to provide systems to be used by the students for organizing people, ideas, and information. Just a few years ago, there was no good way to implement such systems: the Web was still 'read only' for the vast majority of people, and the available content management systems were designed to be administered by a single person. A professor cannot be both a PI and an IT department! Fortunately, Web 2.0 advancements designed to enable 'user-created content' and 'group administration' are changing things for the better: a system can be designed and created by one person and then expanded and administered collaboratively by a group of people.

While my depth of experience with research management is pretty limited, I have tried several things that definitely don't work (and some that have, to varying degrees).

Coordination By Hoping That People Will Coordinate
Your lab will last about five seconds.

Coordination By Lab Notebook
Fine for projects with a single very responsible person; dangerous and nonfunctional in most situations. Only one copy exists, so extremely susceptible to loss or destruction. Not digitally archivable or searchable. Useless for group research; would require reading across multiple notebooks to follow the progress of the research. Impossible to share easily with others in the group for feedback and review and difficult to edit and update.

Coordination By Email
Familiar for everyone, archivable, and searchable, but there's no good way to organize them and the format is extremely limited. If a new person joins the project, it's just about impossible to bring them 'into the loop' and information in emails is lost when someone leaves the group.

Coordination By Traditional Website
Archivable, searchable; good for static materials. The most flexible format, but painful to update; must be done by someone with markup language or design software experience, which isn't a good thing for collaborative efforts. There are much better choices for dynamic materials and group projects.

Coordination By Google Sites
Archivable, searchable. Editing is by built-in WYSIWYG (what-you-see-is-what-you-get, Microsoft Word-like) interface. Includes built-in user management system, but users cannot create an account directly on the site. Sites can be made 'public' (accessible from the internet by anyone) or 'private' (authentication required). Includes built-in functionality for blog-like news posts, 'file lockers' for uploaded content, and standard pages. The free Google-hosted version has a content cap of 200MB for educational institutions (100MB for everyone else), but you can get some hosted space from your organization (or a private company) and deploy your own free Google Apps platform (including Sites, Calendar, Email, and Documents) with improved administration features (allowing you to set your own web address) and unlimited space. A vast improvement over a Traditional Website, but the format is still somewhat rigid; you are limited to the preconfigured functionality included by Google, and embedded custom scripts and the like are disallowed for security reasons.

Coordination By Google Docs
Archivable, searchable. WYSIWYG editing, but also allows formatting using HTML and/or CSS. Can be set to 'public' or 'private'; user management handled by assigning access privileges to a 'folder', and these privileges are inherited by all content (including subfolders). Like Google Sites, it does not allow embedded scripts. Users can create 'templates' for the content that they generate most often to speed up common tasks. This is a great platform to use in conjunction with another format (works great with Google Sites, for instance) because it has a lot of great features, but it is limited to the creation of text documents, spreadsheets, and simple presentations, and beyond that can only be used for uploading PDFs.

Coordination By Wiki
See my article on "How To Install a Wiki"!
Archivable, searchable. Harder to set up than the others; requires that you have your own server space and web address, which you should be able to get from your institution or for a few dollars a month from a private hosting company. Requires users to learn a simple markup language to edit pages - this could be a BIG turnoff for the WYSIWYG-only standard user. Built-in user management, but NO access controls - if you want to put secret stuff on a Wiki, it better be on a secure server.

Coordination By CMS (Drupal)
See my article on "Content Management For Web Design"!
Archivable, searchable. 'Modules' for added functionality (including a WYSIWYG editor to augment the standard HTML and plaintext), including blogs, wikis, multimedia galleries, forums, etc. Powerful, flexible user management and access controls with administrator-defined roles and priviliges; includes a built-in system that allows users to sign up for accounts directly on the site itself. A little more complicated to set up than the others (installation is similar to a wiki). A GREAT system with a little more of a learning curve than the others, but probably well worth it in the long run.

In Summary
There are a lot of different options, all with their own pros and cons. The best system is the system that gets used, so make the choice based on your own level of technological comfort and the wants and needs of your users.

Future articles: 'best practices' for research management; advanced research IT (file synchronization and backup)

CMS for Web Design

 What is a Content Management System (CMS)?
From Wikipedia:

A Content Management System (CMS) is a collection of procedures used to manage work flow in a collaborative environment. These procedures can be manual or computer-based. The procedures are designed to:

• Allow for large number of people to contribute to and share stored data
• Control access to data, based on user roles. User roles are used to define each use as to what information they can view or edit
• Aid in easy storage and retrieval of data
• Reduce repetitive duplicate input
• Improve the ease of report writing
• Improve communication between users

In the specific example of a Web CMS, it's a tool for designing, building, and administering websites.  Many modern CMS allow you to do all of these tasks in a graphical user interface (GUI) environment that is almost entirely free of 'exposed code' - no PHP, XHTML, or CSS required (though they are still powerful tools for making your site look just the way you want it).  They offer several advantages over traditional methods of web design: because they offer friendly interfaces and a standardized way of doing things, it would be fairly easy for me to design and build a site and then hand it off to someone else (with limited web experience) to administer.

I am experimenting with a Content Management System (CMS) called 'Drupal' - it is a free, open-source platform for designing, building, and administering a website.  It's serious stuff (the White House used it for this site, for instance), and it is designed with a 'many producers, many consumers' model of web development in mind.  It requires minimal effort to set up, and the initial process of server-side installation and database creation are very similar to the steps needed to install a Wiki (covered here last week).

My favorite feature: Drupal has powerful user management built right in, with the out-of-the-box ability to create roles, define privileges for each role, and assign roles to users with ease.  The default roles are 'authenticated user', 'unauthenticated user', and 'site creator', but you can make as many roles as you'd like.  This means it's a great choice for building an intranet, a secure storage place for user-created content, or any site where you need to be able to enforce access restrictions.  It also means that you can spread out the burden of administering the site: you can create 'superuser' roles which have the ability, for instance of moderating forums and user blogs.  This feature allows you to introduce trusted users to the administration methods and interface one piece at a time, easing them into the role of site administrator.  All administration is done within the site itself on a special menu that is hidden to regular users, which new admins usually find very intuitive (though it may initially confuse users of older CMS).

Drupal is free, open-source software with lots of community support.  You can add extra functionality (forums, blogs, wikis, multimedia presentation) by installing 'modules', which are user-created add-ons (called 'nodes' or 'widgets' in other contexts) - if you can think of it, there's probably a module out there to support what you want to do.  When you assign permissions to your site's roles, you assign them by module, which allows for quite a bit of customization.

I put this demo together in a few short hours (you'll need to create an account to access any of the content).  I think that this CMS would be perfect for the creation of sites by any organization, with or without a dedicated IT department.  For educational and community projects, this format enables the recruitment of site designers, constructers, and administrators with limited scripting and coding experience, which is EXTREMELY helpful for us non-computer scientist folks.