Tag Archives: cms

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: http://miis2.middlebury.edu/academics/faculty).

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.

Welp

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.

Looser Threads

This is just going to end up annoying me if I don’t post it. I was trying to go to sleep tonight when I thought up something that I wanted to get down in writing before I talked myself out of it or realized how stupid it was.  I started writing this with one basic idea: ending threaded conversation on the web. After seeing where it took me, I think I realized that my solution was just too close to what’s already been/being created in Twitter and Google Wave. I saved this as a draft and closed my laptop. But I think there are some differences with what I want and those tools and, in any case, I wanted to ask other people what they think about the pros and cons of threaded conversation, so I decided that I’d come back, write this intro paragraph and then post the thing for ridicule.

I’ve been working with the LIS Website Team for a couple weeks now in thinking about how we can improve our organizational communications using the website. We set up a project blog and a project wiki and started trying to use them to communicate. One thing I noticed right away is that we’d have these mini conversations in the comments for a particular blog post that might be connected with other mini conversations from other posts, but there was no real way to tie these together. Eventually we might talk about one of these at a meeting and then, perhaps, transfer the results of the conversation in some other form onto the wiki. Maybe.

This same problem happens all the time in web forums where you’ll have a discussion in one thread that’s related to another, get off on a tangent, but have no way to connect the two threads. Communication tools like content management systems and wikis fail to convey the conversation in an even worse manner by obscuring how the concluding document was created by locking it in a revision history that often only shows what was changed, but not why it was changed.

A lot of it, I think comes back to the basic structure of all content on the web: a body, a title, an author, a timestamp, and possibly some other metadata depending on the type of content. This same structure has been in place since people were posting on BBSes. The trouble is, by locking the discussion into having a title you create silos of information in parallel conversation threads.

What’s needed is a discussion tool that allows open participation without tying the conversation to a topic. Alright, that’s what Twitter does in a sense. But while I appreciate Twitter’s elegant simplicity, I don’t think that format allows for the depth of back-and-forth discussion I want to have on certain topics and I require something more than the workaround of just linking off to a blog post or forum thread.

Here’s what I’m looking for in terms of requirements:

  • Single threaded conversation – You can reply to someone, or to multiple people at the same time.
  • Open conversation – People see what you’re talking about and can jump in and give their point of view.
  • Quote content for reply – when responding, you should be able to reference part or all of a prior post or posts in a way that makes it easy for any person to refer back to the original through (at most) a single click.
  • No other tool(s) required – You should not need to link out of this tool to a blog post, video, chat log, document, web page, or any other external content. Doing this could be an option, but the ability to create any of this content inside the tool should exist.
  • Experientially similar to email – Every time I talk about moving the conversation onto the web it’s really about moving away from email. Clearly there’s something about using email that people enjoy, so why reinvent that? You should be able to nudge people to comment by including them in a “To” line, similar to @’ing someone on Twitter.

What do you think? Are these needs already answered by some combination of existing tech like Twitter, Google Wave, blogs, wikis, desktop collaboration applications, or email? Am I on the right track in that unthreading the conversation will improve communication? Or should I just have gone to sleep an hour ago?

    Video on Drupal

    I’ve added the Video Filter module to all of our Drupal pre-production instances to help those of you who are testing Drupal or doing preliminary content development on those servers. You can use this module to include video from one of the 15 sources that it accepts out of the box, like YouTube, Google Video, and Vimeo.

    This uses the format [video:URL width:X height:Y align:left/right autoplay:1/0]. For example:

    [video:http://www.youtube.com/watch?v=G8pPiS7aUGY width:300 height:350]

    I also extended this by creating the MiddMedia Video Filter module which uses the same syntax as the Video Filter module, but allows you to add videos from our local streaming media server, which supports flv and mp4 video as well as mp3 audio. All the optional parameters work for the videos, but you can’t set them for the audio player. For example:

    [video:http://middmedia.middlebury.edu/media/imcbride/walkingTour.flv width:400 height:300] [video:http://middmedia.middlebury.edu/media/imcbride/Google_Reader2008-12-04.mp4] [video:http://middmedia.middlebury.edu/media/imcbride/WS_30019.mp3]

    LIS Website Team Blog

    I tweeted a bit earlier about how I’m now a member of the LIS Website Team. We’re still in the very early stages of this project, but we’ll be firming up our vision and charge in a meeting later today. The concept of teams is also the topic of the next LIS Staff Meeting in July. I have to say, as someone who is typically very cynical about these types of activities, I’m actually feeling good about how this project will work out and hope the Team model is one we repeat in future LIS projects.

    You can follow all of our team’s updates through our team blog and keep informed of our notes and documentation through the team wiki page. We’ve also enabled email subscription to the blog, for those who would prefer to receive updates using that rather than RSS.

    Getting to Know Drupal: the Presentation

    You can listen to my nasally drone talk about Drupal from this afternoon’s session!

    [middmedia imcbride imcbride WS_30019.mp3]

    If you want to check out the presentation and are on campus, you can visit the site at:

    http://chisel.middlebury.edu/drupal/drupal

    And the video version is up at:

    http://muskrat.middlebury.edu/administration/lis/Accordant/DLA/IanMcBrideDrupal61509/f.htm

    Internationalization and Translation for our new Web Site

    I’ve added language packs to a development version of the Drupal site for each language where Middlebury has a Language School. These language packs help to translate the user interface of Drupal. However, most of our users will be interacting with Drupal through Monster Menus, rather than the default interface. Fortunately, Drupal provides an interface to automatically detect strings in UI screens and adds them to a database of strings that can have translations. Both Middlebury and MIIS should consider who within their organization could provide interface translations for each of our supported languages.

    Speaking of which, here are the language packs I installed:

    Language
    Arabic 0/5373 (0%)
    Chinese, Simplified 2511/5373 (46.73%)
    Chinese, Traditional 2514/5373 (46.79%)
    English (built-in) n/a
    French 4695/5373 (87.38%)
    German 4500/5373 (83.75%)
    Hebrew 1450/5373 (26.99%)
    Italian 3488/5373 (64.92%)
    Japanese 2883/5373 (53.66%)
    Portuguese, Brazil 2650/5373 (49.32%)
    Portuguese, Portugal 0/5373 (0%)
    Russian 2363/5373 (43.98%)
    Spanish 2539/5373 (47.25%)

    The second column shows the number of strings and percentage of total strings the translation pack comes with. Note that there currently is no supported language pack for Drupal 6 for either Arabic or native Portuguese, though the maintainer of the Arabic language project just started up work on it again this week.

    None of this needs to be decided today, of course, but do we want to support both versions of Chinese and Portuguese? Are there other languages we want to support? Middlebury and MIIS can have either the same, or different, sets of languages enabled in their site, so which would each site like?

    And that’s just interface translation! We should also be considering content translation, as we’ve already seen that this will be a likely prominent feature of the MIIS site and I would be shocked if it weren’t featured at least on the language oriented parts of Middlebury’s site. When talking to areas of the college about content development, be sure to mention this.

    LISterine Workshop: Getting to Know Drupal

    A short programming note: I’ve been asked to lead a presentation on the Drupal platform for staff in LIS. This will be Monday June 15th from 3:30-5PM in LIB 105. Here is a synopsis of the presentation:

    You’ve probably heard Drupal mentioned in discussions about our new website, but you might not know what Drupal actually is. Drupal is a web-based Content Management System, similar to the software that our current website runs on, but also different in many ways. In this session, Ian McBride will discuss the things that makes Drupal unique, why we chose Drupal as a platform for our new site, and look at some examples of the ways we can extend Drupal to improve our website. We’ll spend some time looking at an extension developed by Amherst College, the only other school running its entire web presence on Drupal, named Monster Menus which we’ll be using as part of the core functionality of our site.

    This session requires no technical knowledge of our website, content management systems, or programming, but is a great opportunity for you to ask questions on those topics.

    I’ve prepared an agenda of topics as well:

    1. The Drupal CMS (20 minutes)
      1. Anatomy of a Drupal Page
      2. Drupal Nodes vs. MCMS Postings
      3. Modules
      4. Why we chose Drupal
    2. Amherst’s Monster Menus (10 minutes)
      1. Creating a site hierarchy
      2. Delegating permissions and design
      3. Extending with RSS
    3. Free Form Questions and Answers
      Your opportunity to ask whatever you’d like about Drupal’s features, framework, and functionality or about our future website’s structure, extensions we’re planning, and our philosophy with regards to requests for new modules. To accommodate those with scheduling conflicts, feel free to come and go as you please during this.

    Self-Service GO

    GO has undergone several revisions in its operating code base. The first version was a PHP 4 script running off cat.middlebury.edu that simply handled redirection of URLs based on well-formed parameters. This was then moved to a special CMS channel with redirect postings for each of the “codes”. At this time the system wasn’t known as “GO”, rather the “CRA” which is an acronym I can’t remember the meaning of. When Chris thought up extending this to be go.middlebury.edu, I rewrote the system in PHP 5 so that it could have a database back-end with some administration screens. This version of GO supported all kinds of functionality: shortcut “types” like “Banner” that allowed us to shut off whole systems at will, a statistics library that grew so large we could never use it, multiple fallback URLs for some shortcuts, and a load balancer that I swear, at one time, actually worked (others disagree on this point).

    Becuase of the scope of that application, maintenance was continually an issue, particularly at stress points in the year, like Registration, where many people would hit the GO system all at once, hoping to get transferred to Banner so they could register. Chris decided we should simplify the whole process and remove scripting languages and databases from the equation entirely, so we transferred the existing shortcuts to a flat file that served to redirect the URLs. This meant that we lost some functionality like the old GOtionary with its code descriptions and the ability to turn on or off a particular code at will through a web interface. So I got to work on a “simplified” GO and that’s what we launched on Monday.

    The old GO database’s 13 tables were cut down to a mere 4: one to hold users, one to hold shortcuts, one to relate users and shortcuts, and one to hold aliases for shortcuts. This also allowed us to simplify the administration interface for the application to just have a “create” and “update” screen that people can use to manage their shortcuts. Additionally, because of its simplicity, we decided to make GO a self-service application. This means that you can now create any GO shortcut you want! Of course, you can’t create a shortcut that’s already been created, and we may need to re-purpose your shortcut if the College needs it for an important academic or business purpose (e.g. if you register go/czech and later on Middlebury opens a Czech Language School…).

    Here are some helpful definitions regarding GO:

    • shortcut: these are the meat and potatoes of go. Anything after “go/” is the shortcut. So in “go/bannerweb” the word “bannerweb” is the shortcut, but you might also have “go/bannerweb/courses/english” where “bannerweb/courses/english” is the shortcut. Shortcuts can be up to 255 characters long and contain any alphanumeric characters plus /, ?, -, and _. The only restrictions are that they can’t begin with /, ?, or the phrase “go/”.
    • alias: these provide an alternate path to a shortcut. For example, “banner” and “bw” are both aliases for “bannerweb” so you can type go/bw, go/banner, or go/bannerweb and get to BannerWeb. If, for whatever reason, the URL of BannerWeb changes, we only need to update the “bannerweb” shortcut and the “bw” and “banner” aliases automatically follow.
    • creator: the person in charge of the shortcut and any associated aliases. Only the creator can delete a shortcut and only the creator can add other users.
    • user: any person who can update the shortcut. Users can change the URL, description, institution, and whether the shortcut is hidden from the GOtionary.
    • institution: we maintain both go.middlebury.edu and go.miis.edu and you can create shortcuts for either. However, each shortcut can only have one institution. You can change the institution of a shortcut at any time, but it will stop working in the other institution.

    One thing we noticed during the Web Redo requirements gathering process is that people seemed confused about the GO domain. We got a lot of responses saying, “I wish I could use GO when off campus!” You can! The domain go.middlebury.edu exists for exactly this reason. In fact, when you’re on campus, you’re using this address even if you just type “go/”. It’s just that, since you’re on campus, we assume that you’re interested in middlebury.edu stuff, so we don’t make you type it. However, all the addresses in GO are available anywhere in the world by typing go.middlebury.edu/shortcut (or go.miis.edu/shortcut). GO isn’t the only service that you can get to quickly just by typing its sub-domain name when on campus; try this out with “www”, “segue”, “middmedia”, or “netstorage”.

    There’s a plea about this on the GO administration screen (http://go.middlebury.edu/admin), but I’ll repeat it here: if any of the existing GO shortcuts are things you’d like to manage, and you work or study in an area related or responsible for the shortcut, let me know (by emailing go@middlebury.edu). I’ll set you up as the creator of the shortcut and you can go from there.