An informal look at interesting Drupal resources and services at other universities.
Stanford Sites is a self-service tool for building and managing websites for University work. Websites are hosted on a dedicated Drupal infrastructure optimized for performance, streamlined maintenance, and community-requested features.Stanford Sites is available to current faculty, staff, and students to use free of charge and requires little technical expertise.
- Worth taking a look at the incredible range of contributed and custom modules supported on the platform.
Following are links to step-by-step guides created by Stanford Web Services to guide you through tasks of creating and maintaining a Stanford Sites Drupal instance.
"Drupallers Drop-in Help" is held on the Third Thursday of every month for people to drop in and be helped with any Drupal website questions they have (or to drop in and help others).
The Berkeley Drupal Users Group (BDUG) sponsors monthly presentations on building websites. This group is open to everyone in the area who is interested in learning, teaching or networking about Drupal.
- Support both UC Berkeley and non-UC Berkeley Drupal developers
- Foster collaboration and idea exchange between Drupal developers
- Sponsor: Elizabeth Elliott, Director of Talent and Organizational Performance
IST Drupal Cloud Hosting offers powerful, easy-to-use tools for building and maintaining Drupal-based websites and applications. Partnering with San Francisco-based Pantheon to provide free state-of-the-art development tools and affordable hosting plans, IST Drupal Cloud Hosting is designed to support the many campus departments, research groups, and other organizations using the Drupal content management platform.
I originally intended today's presentation as a review of where MIT is now in terms of web development, followed by a presentation of an alternative approach. But I can say really simply now where MIT is, leaving me to spend the bulk of my presentation showing something better.
Basically, MIT has two options for bringing in new websites: single-site single-client development, or Drupal Cloud.
The single-site approach is unmaintainable. The sites are built by an outside developer and handed over to their MIT client, usually a program's communication manager, to manage. The developer oftens works on a contract basis to maintain the site and make needed changes. And the communication's manager maintains the site. The essential flaw in this process is that new MIT sites reinvent the wheel over and over again, building the functionality (people, projects, publications, news events, blogs, media galleries), that should long ago have been packaged and made available to the MIT community in some sort of centralized process.
Drupal Cloud I discuss in the blog post from yesterday.
So what I'll be presenting today is my approach, which basically presents the concept of an MIT distribution, then demonstrates the power and functionality that it is possible to build on top of that basis.
1. Panopoly. I start by introducing Pantheon's Panopoly distribution, because it is becoming the standard base for most other distributions by virtue of its brilliant use of Panels and Panelizer.
2. Then I demo the Open Academy distribution, originally built by Chapter 3 for UC Berkeley (I believe), which is built on top of Panopoly and adds standard (ahem, Drupal Cloud) academic features like Publications, People, Events, and News.
3. And then I come to the primary thing I want to present, which is the Open Atrium distribution. Open Atrium builds on top of Panopoly, so it's basic structure should be very familiar. But it adds the most brilliant feature set and interface I've seen on any website. The distribution has been adopted by the United Nations as their primary platform, and that makes perfect sense to me.
Over the past year I've used Atrium as the basis of my own sites, and have added the features that I think belong on an MIT distribution, the most important of which is a documentation intranet. The fundamental flaw with nearly all web development is that there is no documentation, neither for users nor developers. Sites are built and handed off, but as soon as anyone from the original team leaves, the site becomes unmaintainable. Virtually every stand-alone site I’ve seen at MIT has gone through this life-cycle spiral.
The other key problem with our current approach is that so much effort is being wasted in recreating the wheel, in building functionality that should take an hour at most, not the entire development budget. So virtually every site at MIT is happy to post events, news items, and people, and call it a day. Some are more attractive than others, but their functionality and development is a direct version of their html base. Revolutions have happened in how sites are built, in what they do. But MIT has simply updated html to php. There is so much that could be happening with academic websites, especially in large research centers, and none of it is happening beyond decent looking sites that show events, people, and news items, and call it a day.
So the presentation today is about demo-ing a more efficient structure. It's not the manifesto I had in mind when I originally thought of this presentation. But I think it represents a better way forward.
These are some of the ideas behind what I'll be presenting on Monday:
Drupal sites are difficult to maintain once the original development team is no longer involved.
This is partly due to security updates. Most Drupal sites have 200+ contributed modules, so updating the modules as security updates come along is a required task, and complications can sometimes develop. Developers who have built the site are much more confident doing this than developers who are inheriting a site to maintain.
But the real issue is lack of documentation. It may be possible that some developers have provided it, but I've never seen any for any MIT website. It's not part of the job spec. So there's no operating manual, no blue print to guide others when they try to work with any given site. Documentation, for both users and developers, must be required for all websites.
A stand-alone site developed for a single client is difficult to maintain.
Most MIT websites are stand-alone sites developed for a single client (sas-sc). Drupal Cloud sites are the exception to that, and I'll discuss Drupal Cloud separately.
This one-client-one-site approach is a legacy from html sites built for individual MIT schools and departmental websites. Or perhaps it's more accurate to say that it is simply a legacy from html websites. A legacy that MIT hasn't yet moved beyond. It's completely understandable why SAS-SC sites dominate at MIT, because they speak to the independence that every MIT center claims for itself. But they're inefficient, hard to maintain, and require so much effort to get up and running in the first place, that few resources are available once the site has gone live.
Mid-sized development clusters
When you look at MIT's Education page (http://mit.edu/education), you see the traditional MIT structure. And clicking on any link takes you directly to that website.
But when you look at MIT's Research page (http://mit.edu/research), you see a much more complicated story, and this more complicated story indicates how MIT's current approach to web development falls short.
Here, when you click on any link, say, civil and environmental, you are taken to an intermediate "topics" page which lists all the groups within that area. And it's this strucure which I feel should help guide development at MIT. Not in a dogmatic sense of being locked into a particular cohort. But in the sense of sharing resources whenever possible, and not reproducing the wheel over and over again.
This is what I'll be presenting on Monday. It's what I've used to build the MIT Energy Club, Clean Energy Prize, and Energy Conference websites, and what I'll be using for all the sites I build going forward.
It's based on the Open Atrium distribution, built by Chapter 2 and now adopted by the United Nations. There are brilliant ideas within this distribution, and I'm convinced that these will become standard elements of Drupal sites. Underlying the distribution are two key features: organic groups and panels. The first is a powerful way to create spaces and subsites within an individual site, and the second is a layout/configuration tool. I'm working on a screencast now to present the main features of panels, which is too often thought of as a layout tool when its most powerful feature has to do with configuration.
Beyond that, the two main ideas that I think are most important here are:
- complete documentation for all levels of users, and site maintainers and developers.
- an MIT-specific feature set.
So far I've created the following features:
- mit blog
- mit gallery
- mit calendar
- mit people
- mit sponsors
- mit job listings
- mit projects
- mit publications
Open Atrium's brilliant deployment of the clone/blueprint modules makes it simple to save any configuration as a mini-distribution, which I've used to create a conference template. I've started to build some sandbox sites to demo the functionality and will post links to these later today.
I made a short screencast to demo posting a journal article to a website. One of the essential ideas I want to present in my presentation next Monday has to do with documentation. The dirty secret of web development is that developers virtually never provide any documentation, either for the site users or for site maintainers. And this makes the sites, especially one-off sites built for a single client, virtually unmaintainable over the longterm. So I'm trying to avoid that trap by writing full documentation for the sites I build.
For example, every staff person at MIT should have a pdf cheat sheet hanging by their desk that covers the major tasks they have to handle on a given website. And the website itself should have a documentation intranet that provides help pages for all tasks. Even logging into a site can sometimes be a hassle.
So I'm trying to avoid that by making short screencasts for the intranet on my websites, that cover all tasks, major and minor, that users and developers are likely to encounter in interacting with the site. I'll try to have as many of these as possible up and running in advance of Monday's presentation.
And here's the first one:
This is going to seem a leap but I think MIT Libraries should take the lead for web development at MIT. For starters, they're heros for me, because whenever I go to a tech event in the Boston area, or have made a presentation myself, a few people from Libraries are inevitably there. And they're always ahead of the curve in terms of the resources they deliver to MIT, especially online resources, which have made the difference in terms of being able to stay on top of a field as fast-moving as web developing.
But more than that, so many changes are coming down the pike in terms of meta-tagging content in new ways so that it shows up in searches of all sorts, so that it can be redeployed to the infinite variety of platforms we are now having to deal with. Web development is too often thought of in relation to events, people, and news items. If Libraries were involved, then people would better understand that a fundamental task for websites has to do with archiving and making available eBooks, research graphics, and all the other products that a robust web development makes possible.
The other piece of this is that, being campus-wide, and already integrated into the life of the Institute, it would be easier for the MIT LIbraries team to provide the simple, walk-in help that websites need.
I don't know if this idea is viable but I'll make a case for it in any case.
Bizarrely, though MIT is filled with first-class communication managers, I'm not sure there are any actual web developers on campus. I certainly haven't met any in 23 years -- apart from the brilliant, mostly undergraduate volunteers running the Scripts team out of the student center. Enough can't be said about the great work that those students do. So bringing more of that energy into the rest of MIT would be a tremendous boon.
In any case, I think MIT should give undergraduates the option of picking up freelance work as hourly Drupal Cloud developers. They'd hit the ball out of the park with this one. And they would bring the kind of innovation that Drupal Cloud needs.
Someone emailed me a few days ago to ask that question. I didn't know, so I emailed its Dev/Ops maintainer, Camilla Fox, who replied to say:
"...the Drupal Cloud team is under new management, and we are working on our direction/strategy; most of us identify primarily by other titles, but the project is very much supported."
Good to know.