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?

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

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

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.

This morning I added images to the RSS feed HTML for all of the feeds on the CMS. Most of the feeds on the CMS are collections of News postings made by various functional areas. We have a page set up that indexes all of the live feeds on the CMS. If any of these News postings contain an image or are redirects to another news posting that contains image, that image will be displayed in the feed source. This only works for images which are in the default image placeholder control on the News template.

This appears to work in all major browsers and in the RSS Feeds component of Outlook 2007. For Outlook, I had to manually specify the height and width of each image because if you don’t Outlook will resize your image to 50×50 pixels for “security reasons”. I can’t quite figure out what those reasons might be, but fair enough. Now I trigger an additional callback to the Resource in the Resource Gallery that contains the image, render it in an Image Stream and access the height and width parameters to include in the img tag in the RSS.

We’ve successfully consolidated the News published by Public Affairs today. All news can now be found at http://go.middlebury.edu/news. This is the source for front page News items on the CMS, which previously had been drawn from a different News channel. This change should make it easier for Public Affairs to get their important stories onto the front page, since they won’t need to recreate them in a second location any more.

I made another News related improvement on the CMS yesterday that managers of Newsletters will appreciate. Each Newsletter has a set of pre-created “right nav objects” (check out SportsNotes to see what I mean), which are common design items that can be displayed on multiple Newsletter issues. Since the code for this was reused from a different part of the CMS, the right nav objects would only display if they were applied to the current channel. That’s fine when you want to display a link to the Initiative website on the front page of Supporting Middlebury, but not fine when you want to show this on every issue of a weekly (or daily!) Newsletter. You’ll be spending a lot of time setting up each channel to do this. Now, just for Newsletters on the CMS, the right nav objects will look to their parent channels to see if any are specified and inherit from there. This can be overridden at the issue level as well, allowing for variety if the author so chooses.

Newsletter administrators who want to know more about this should contact myself or Chris Norris.

When we first implemented the CMS here at Middlebury I was a summer intern working in a closet in Warner basement between stacks of printer cartridges and Dell driver CDs. One of my job responsibilities at that time was to fix any broken links on the CMS. To “help” me out, a script was created that sent an email to a central mailbox account every time somebody tried to access a page that didn’t exist on the CMS. In web terms, this is know as a 404 error. I received several thousand of these messages each day.

The volume of emails was too great for anyone to keep up with and so the script was turned off. We now rely on the sub-site content providers to maintain their own site and fix any broken links they might hear about from peers. Rather, that was the case until last night when I re-wrote the 404 Email script for our new CMS framework. Stephen Kiel, Technology Coordinator for the Career Services Office noticed a line in our CMS documentation which said:

“404 email notifications can be delivered to Content Providers upon request. Know about broken links on your sub-site as users discover them, very handy for large sub-sites with many channels/postings.”

As far as I can figure, this was to be a new feature of the MiddCMS framework that was just never added to the code, but was placed in the documentation. There is a section in the code that tries to log each 404 request to the server, but it is commented out with a note about performance concerns and even that doesn’t do what our documentation is saying we do. Still, the functionality is simple enough. We just need a configuration file with the email address of a person to whom we’ll send an email and the part of the site they’re concerned with, then just parse the configuration file every time you get a 404 message and send them the email with the information. This took me about a half hour to put together, with some time to add error handling for parsing the configuration file and other concerns.

Now we can send our content providers an email letting them know that a user wasn’t able to get to a site within their sub-site just by adding a line to an XML document like this:

<ErrorMails>
<ErrorMail path=”/administration/cso” email=”imcbride@middlebury.edu”></ErrorMail>
</ErrorMails>

With that in place, I would receive an email for every bad request to anything under “/administration/cso” containing two URLs. The first is the address to which the user attempted to get, such as http://www.middlebury.edu/administration/cso/does_not_exist.htm and the second URL would be the referer of the page request, if it exists. Typically, the referer will be the page the user just came from. This is useful so that the content provider can go to that page and fix any bad links to content that doesn’t exist. There are some times when the referer will be blank. The most common of these are:

1. If the user typed the page address directly into their address bar
2. If they used a bookmark
3. If they clicked a link in an email

There are certainly other scenarios, but those are by far the most common for our site. So if you want this functionality for your sub-site, just let us know by sending an email to the Helpdesk requesting it. I’ll be glad to add your email address to the list!

The updates to the web environment that we performed over the holiday break, including updating the MCMS database to use SQL Server 2005 and applying MCMS Service Pack 2 with a ton of fixes went forward successfully. There were a couple bumps in the road after applying the changes, but for the most part the upgrade went well. One of the most glaring changes caused a rendering issue with many pages on the CMS, namely those in which the content flows around another framework element, like a picture. The two most prominent of these pages were the Language Schools and Schools Abroad home pages.

As you can see, the content doesn’t properly flow around the “post it” in the upper right corner of the content area. I was able to track down this issue to the editing interface we use for the CMS, Telerik’s r.a.d. Editor, which in .NET 2.0 aparently inserts a style=”display:inline-block” attribute on the element where it renders the content from the editing control. This messed with our CSS, forcing the wrapping to break. I fixed this by manually adding a style element inline in the template that we use for these pages, like so:

<telerik:RadEditorPlaceholderControl style=”display:inline” id=”mainContent” Placeholdertobind=”mainContent” toolsfile=”~/RadControls/Editor/ToolsFile.xml” configfile=”~/RadControls/Editor/ConfigFile.xml” runat=”server” />

Problem solved! Or so I thought. I figured this would be the only place on the CMS where this particular issue would occur since I couldn’t recall where else we were wrapping content around elements like this. Unfortunately, I forgot about the News template, which wraps its content around a picture with a caption. My colleague, Brett, helped me track this down by looking through the Telerik support forums and finding that the display:inline-block style is hard coded into the control and can’t be easily removed from the editor. We could override the whole control and implement our own styles, or we could force a global append of the correct style. We chose the latter as it meant writing one line of code, rather than several and changing every instance of the editor throughout the application.

  protected override void OnPreRender(EventArgs e)
  { 
    foreach (RadEditorPlaceHolderControl editor in FindRadEditor(Page))
    {
     editor.Style.Add(”display”, “inline”);
    }

   base.OnPreRender (e);
  }

 Now it’s fixed everywhere and the CMS seems to be running well in the new environment.