Death to MYddlebury

This post was originally an email to “the people who cared most about this issue”, which I immediately realized was the most conceited possible address for a message on this subject: the personalizable features for the new website. By its very nature, this concerns everyone who works, studies, and teaches at Middlebury, all of whom care on at least a small, perhaps unconscious level about whether they can create their personal web space or maintain a profile on our new website.

At least, it’s been my hope since the beginning of this project that people cared a little about this.

Still, sometimes it takes a conference room of 30+ people to convince me that I’m wrong about something. This afternoon we met to discuss a possible solution for implementing a personal portal experience on our new website. There was plenty of criticism for the proposed software and I didn’t take it very well. During the meeting and then later in the afternoon I advocated a compromised position: we should implement the parts of this software that dealt with creating personal web spaces and profiles and ignore the rest. After a few hours of reflection, and a few beers, and a brandy, and a glass of port, I’ve come to a different conclusion: we should scrap the whole idea, look back at the features people either requested or were prematurely promised and develop a method to get that stuff working on our new site.

Here’s what the application we looked at this afternoon offered:

  • A directed announcements page
  • A static list of constituent-oriented links
  • A RSS feed reader
  • Personal web space for all users
  • User profiles fed form a central database like Banner
  • Alumni gateway features like a career network

Here’s what we’ve actually been tasked with delivering:

  • Professional profile pages for Faculty and Staff
  • A page of personal bookmark links
  • Maybe some sort of iGoogle thing. That’d be really cool!

That’s it.

Let’s deal with each of these point-by-point.

Professional profile pages

We already offer several systems for building out your personal web space. Many users have web-accessible directories on our old UNIX server where they can upload HTML documents. I got one of these accounts when I was job shadowing one of the system administrators at the college in 8th grade and then used it again when I took an intro CS course at the college while in high school. The server’s been upgraded a couple of times since then and now runs some version of linux, but it’s basically the same set up. If people want a bit more, they can create their personal web space on Segue, our custom developed LMS, or here in WordPress, or as a user page in one of our wikis, or as a profile posting on our current CMS, or in a couple other really specialized systems. We will very likely soon also offer Google Apps for Higher Education, which will allow people to build out their personal site using Google Sites.

But the idea with these professional pages was that people would want to present information about themselves in a highly structured format, integrated with our new website and content management system. Faculty might want to post their CV, academic history, and current courses on a page that as the same look-and-feel as the rest of their site, delegate permissions to allow the academic coordinator for their department to help them update the information, and provide some dynamic content from our campus directory or course catalog. Doing this requires more of a thought out, structured system than we’d be able to offer with basic HTML document web hosting or even Google Sites. The idea was, therefore, to create a basic web space for everyone within our new CMS and let them build out their site in this space.

This creates some rather obvious problems. If this is just basic web space, how to we integrate it efficiently with the course catalog or online directory? How do we automatically enable departmental colleagues, such as the academic coordinators, to assist in building out the content for these profiles, as they have done in the past? If we want to add a piece of functionality to every one of these professional profile sites, can we do it in an efficient manner? Can we aggregate this content easily, knowing that our central database system doesn’t tell us which people belong to which departments or workgroups? How do we reuse this content in other areas of our site?

If we were to just turn on really simple web site editing for all users, very few of these things would be possible.

Instead, we should do what we have already begun to do for Monterey: use a specialized template in our new site for professional profiles that includes fields for all of the information we want to know about the person and might choose to use when segmenting or aggregating the information. We should then have these profiles pages created within the departmental or office sites relative to these people. We can then use the power of our new CMS, Drupal, and its Views module to create pages that allow the user to quickly and efficiently find the people they want to know about. An example of this already in action can be found on the development version of the MIIS site (here’s a link that will only work on-campus and will break soon:

We have never been successful demanding that anyone use a particular system and will, naturally, still offer all of the options for creating your personal web space that I mentioned above, but for creating the types of profile pages that we know need to be present on the official departmental pages, we’ll offer this option with encouragement and development support for integrating the “official” profile with the database systems that already contain much of the information we’ll be presenting.

A page of personal bookmark links

This is the most important feature of our new website for our internal audience. During meetings last winter, faculty, staff, and students were both promised that this would be available and told us that this feature was required. Accordingly, we need to find a way to make this work. The resulting system cannot feasibly be one where the user can simply click a button on any page of our site to add it to their personal bookmark list; such functionality requires an integrated portal product that we are not able to run due to pressure from faculty to run systems such as WordPress and MediaWiki for their specialized uses rather than a single portal application like SharePoint, Luminis, or the custom systems developed at Amherst and Gettysburg. However, that does not mean that we cannot offer customizable gateway pages with the following features:

  • A default list of links
  • A prominent form, encouraging users to log in and edit their list
  • Drag-and-drop reordering of links on the page
  • A quick webform where the user can paste a URL and enter a simple title for the link page
  • Integration with our single-sign-on system, so if the user is already signed in to one of our web applications they will be presented with their custom link list immediately upon selecting one of the constituent gateway options from the global site footer

Some type of iGoogle thing

We know that our advanced, cutting edge users want to personalize their web space with drag-and-drop widgets, design their own homepage experience and have deep, interactive ties with our core systems. We have also heard, from several of the design vendors who visited us during our RFP stage as well as intelligent folks on campus, that rebuilding a local version of a really cool application like iGoogle is a fool’s errand. As soon as we’re done with our version of it, Google will come out with a really cool new feature that ours doesn’t have and people will just keep using Google’s version of the application.

Much as I want to believe differently, I have it on good authority that Google has both more and better developers than Middlebury College. We’ll likely never be able to offer a better version of iGoogle than they have already created, so we might as well use the instance they’re giving us. We’ve heard that the iGoogle that comes with Google Apps for Higher Education is considered “deprecated” by Google. Still, I remember a phone conversation that Chris and I had with a Google representative in 2006 who assured us that Google would soon be charging institutions like ours over $10k a year to use the Google Maps API without advertising and that this change was only “months” away. By my count, it’s been at least 40 months away at this point. Of course, we can never tell when a 3rd party vendor will unilaterally kill support for an offering that they’ve told us they’re killing support for, but we’re talking about something that we already know will be used primarily by our power users.

They can deal with it if Google decides to move on.


To summarize: I think I was incorrect about the necessity of implementing a local profile portal to serve the features our requirements gathering effort found last winter. When this post was still an internal email, I was going to request that I be given the opportunity to publicly apologize for  my behavior this afternoon in attempting to push this through rather than listen to the honest feedback coming from our staff and students present at the meeting. This blog post should serve as that apology. I think I get it now and rather than implementing services that I think would be really cool, will advocate for things that accomplish the actual goals you set for us in this project.

I recently emailed my boss saying that my time working on our website after hours like this was at an end, but I find I can’t really operate that way. If I didn’t spend the time to type out this post, this would just be gnawing at me all night and that’d be a worse punishment that taking the hour or so required to get my thoughts down in writing. While I’ve said that I think I’m now more correct in my thinking about how this should all work, I have to acknowledge that I was incorrect previously which could very well mean that I’m still laboring under misconceptions. Please use the comments field here to let me and the rest of the development staff for Middlebury’s new website know if I’m still off my rocker on this issue.

8 thoughts on “Death to MYddlebury

  1. Kristen

    I think you are right on in exploring some new options. When Joe was explaining the Amherst profile model to Lynn and me on the phone yesterday, I wasn’t super excited about it. I am excited to see and partake in other possibilities.

    Oh, and we at Monterey definitely appreciate the after hours work you have put in to help get our website ready for launch. :)

  2. Lynn McDonald

    Excellent post!!! I really appreciate your honesty and insight. I went home stressed tonight and all I could do was take a bath. This post is way more therapeutic and constructive.

  3. Jason Mittell

    Thanks for this thoughtful post – I agree that thinking about the core goals is more vital that focusing on the tools at this point.

    I think your idea for a editable bookmark page will work fine, as long as it’s minimal in confusing features and clearly documented for the average low-end user. And I totally agree that as long as we create RSS feeds for everything in the site, an external build of iGoogle would be just fine, as determined by the user. Perhaps there’s a way to write a tutorial for how to set up a Midd tab in iGoogle, or a defined template/theme that Midd users could implement? But this is a low priority at this point.

    I think I disagree on the profile issue. One major problem now is that faculty feel no ownership of their profile pages (as they now stand) because they need to ask a coordinator to edit it. Thus it gets updated rarely, often is inaccurate, and faculty who want to be up-to-date use a wide range of external/internal systems to create a real hodgepodge of profiles. Even though Drupal will be easier to edit, I still think there should be some form-like tool with fields to populate a generic faculty profile (and another for staff probably). Otherwise, I doubt that 80% of the faculty will touch it. Maybe the MIIS tool does that, but I don’t see it on the end result. Based on what I’ve seen, the tool we looked at yesterday would be adequate for this – what am I missing on that?

    Looking forward to further conversation on this,

    (Side note – see for an example of questionable collegiate branding!)

  4. Ian McBride

    Naturally, we need to ensure that Faculty members are able to edit any public profile of themselves, should they wish to take the initiative. By setting up the profiles in the departmental websites and granting Faculty access to edit their departmental website we both allow everyone to edit their profile as well as encourage contributions to other areas within the department.

    I also agree that the profile editing interface should look much like a form for basic profile information, though by using a specific content type for this function rather than free-form personal websites we’ll be able to integrate with the Directory and Course Catalog applications and pull in much of the relevent information about people without requiring them, or their coordinators, to do any work. We’ll also be able to have these pages appear in the departmental sites for each of the departments in which they participate and have it so that edits to their profile in any one department are automatically reflected in the rest (the same as we currently do).

    The tool we saw yesterday does do some of these features, but its unlikely that we’d be able to set up the profile connection with Banner by next month, meaning that when we start helping people build out their departmental websites we’d have to say, “but don’t create any profiles yet!” Instead, creating a simpler system that we know we can get working by October and still accomplishes our core goals while putting us in a good position for future improvements seems like a good idea to me.

  5. Jason Pontius

    “The resulting system cannot feasibly be one where the user can simply click a button on any page of our site to add it to their personal bookmark list…”

    I have a hard time believing this. The thing about bookmarking applications is that (with a few exceptions) they’re freakishly simple. Remember before Yahoo bought it? There was almost nothing to it. I don’t see why you can’t create a link in the Midd footer that goes to page), and then use mod_rewrite to let return a of the links Jason’s bookmarked— and *no further functionality whatsoever*. That seems like the kind of thing that would require no more than a few hours of programming, minimal design work, and that could be done in secret; instead of unveiling a plan for public review, I’d just build that, not tell anyone, and then say, well by the way, we have this. Want me to stupidly volunteer to build a proof of concept? No? Whew.

    “We have also heard, from several of the design vendors who visited us during our RFP stage as well as intelligent folks on campus, that rebuilding a local version of a really cool application like iGoogle is a fool’s errand.”

    I don’t think that, FYI. But maybe that’s because we just completed a very similar fool’s errand for Lewis & Clark:

    “When this post was still an internal email, I was going to request that I be given the opportunity to publicly apologize for my behavior this afternoon…”

    I’m sorry I missed it. :)

  6. Ian McBride

    You’re right about the bookmarking application, and we’re going to build that and it will work for *many* of the sites we host, but there will be some notable exceptions where the application won’t use the Middlebury design, or won’t be integrated with our single sign on application, or won’t have pages that easily lend themselves to bookmarking. I’m talking about much of MediaWiki, Segue, BannerWeb, the Dining Hall Menus, some blogs that won’t be in the Midd theme, etc. We’ll continually work to incorporate more centralized features into these applications, but they might not all be ready at the time of launch of the new site and I think it’s appropriate to set user expectations of such a system, particularly when they might have been told in the past, “you could go to *ANY* site at Middlebury and see this button…”

    Any page in Drupal? Yeah. Any blog post running a Midd theme? Yeah. A few other sites? Probably. And yes, we’re just going to build the damn thing and not over engineer a link list with a user lookup table behind it.

  7. Jason Mittell

    Ian – as one of the people doing some of the promising (well, more like touting…), I think that a bookmarking solution that hit 95% of the pages would be considered a huge win. For those remaining sites, would it be possible to also have a manual URL add function to the MyBookmarks page? Or maybe incorporated with the self-serve GO menu?


Leave a Reply

Your email address will not be published. Required fields are marked *