So, I'm Michael...

To conclude 2010, we decided to take a look at one of the most universally employed tools on our higher ed websites: the course catalog/bulletin. So, a couple months ago we put out a survey and called on you to share some information on just how you’re doing things, in hopes of being able to supply others with some background as they tackle similar challenges. Seventy-four schools took up the challenge, and now we are ready to show you what we learned. Due to the sample size, please take these results as anecdotal, and as always, the results are available in multiple formats under a Creative Commons license.

So, to get started, let’s look at who responded. The lion’s share of respondents (43%) come from low-mid sized schools between 1,000 and 5,000 students. Beyond that, just over three-quarters were some form of four-year school. (FYI: you can click to embiggen any of the graphs on the page.)

Assuming your catalog isn’t currently online, you are in the EXTREME minority (1%). Most schools appear to be getting the whole thing online, while a small portion just do part. Of these, the top two archive methods were PDF (62%) and however their CMS handles it (24%). 18% said they don’t archive their catalog online. I found it somewhat interesting that such a large percentage archived via PDF, however, this likely makes sense given the simplicity of consolidating into a single file. This also likely prevents issues with search wrongly returning results from older catalogs to students looking for current information (assuming you can’t handle that issue in your search solution).

In the spirit of print, not much is happening in the world of multimedia with regard to catalogs. 5% said they are using it only selectively. 64% have no interest in it at all. The rest said they have interest in it, but have nothing to use. We didn’t look at specifically how multimedia was being used, but some suggestions would be things like videos that would assist students in why they’d be using the catalog in the first place: how to do a degree audit, explaining degree requirements, highlighting unique courses. This isn’t necessarily somewhere that you need to “sell” things, think task-oriented stuff.

“For those of us on the web side of things, we HATE the print catalog. Students don’t use it and it takes the print side of our office months to get 4 catalogs done. However, since the faculty are the strongest voice, it doesn’t look like anything will be changing.”

~ Survey Comment

The print world she is a-changin’ as well. 41% of schools that answered the survey said they no longer offer a print catalog. This particular statistic surprised me some, as I knew the trend was increasing, but didn’t imagine it was that far along (again, take this somewhat lightly due to the sample size).  More than a quarter more have started discussions on eventually phasing print out. It seems likely that within this decade, we could see catalogs go entirely print-on-demand.

In the realm of tools, things are more sorted. Just over half (51%) of the schools don’t have any actual application to manage their catalog with. Of those, slightly under two-thirds wish they had something though. Obviously, this is reflected in the number of people doing catalog management manually (you have my sympathies). Besides the by-hand method, the most popular management tool is simply whatever they get with their CMS. A surprisingly low number (10%) indicated that they are using a vendor designed catalog tool. Another missed opportunity – it would be interesting to know if people’s primary issues with vendors are price or feature related.

“We went with Acalog. It looked good. But we’re not happy.”

~ Survey Comment

“Our software that builds a catalog front-end to Banner is open source and available here: http://github.com/adamfranco/coursecatalog/wiki.”

~ Survey Comment

Finally, what I think is the most telling statistic: satisfaction. Only 35% indicated that they were happy with the way things are now with regards to their online catalog system (that includes 5% that said they were happy doing things manually). Everyone else is either looking to change, or wishes they could. Why is that? Because catalogs are effing hard. Translating a print document to the web is one of the all time great challenges of our industry, because while there are so many similarities, the mediums lack parity in too many areas. I think this goes back to being a big driver in the move away from print. Ultimately, it will simply become more efficient to pick a side and stick with it exclusively (a battle the web will always win).

Ultimately, it’s hard to take away a lot definitively that doesn’t reinforce what we already see in current trends. There weren’t any earthshattering discoveries to be uncovered given the sample size.  But, we’re seeing an increase in schools interested in dropping print, and a lot of dissatisfaction with the solutions currently available. Download the raw results yourself if you want to get more information or cross-reference any of the data yourself. Feel free to expand on any of it as well.

Higher Ed Catalog Usage Survey Results by Michael Fienen is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at doteduguru.com.

Related posts:

1. [ Survey ] Getting to Know Our Catalogs
2. Online Cataloging Done Right(ish)
3. Image Library: Moving from Extensis Portfolio to Google’s Picasa

Time to kick off the new year with some reader interaction! Since we just released the results of our last survey, it’s prime time to see what we could gather next. This time, we’re diving into the wild world of video, and it’s a doozy. This survey will take a few minutes, but it will be time verywell spent, as we are collecting a broad range of information on video usage in higher ed so that we can see just where we stand as an industry. We also want to help people understand where the baseline currently is for when they are making decisions about hosting, creating, and promoting video.

This survey will run through the month of January, so get your responses in and be sure to share this mamma-jamma with your friends and coworkers. Facebook it, retweet it, Digg it, heck, you could dance with it in a killer dance style retrospective YouTube video if it would help get responses. I’m okay with that. The more responses, the better quality the results – so let’s do this.

Start the Survey Now!

Related posts:

1. 5 min survey: State of the university Web department
2. [Results] State of the University Web Department survey
3. [Guru Survey] Higher Ed CMS Usage

This post will be dual purpose: first, to announce the release of the dotCMS IRC Client plugin, and second to provide a tutorial explaining how to launch a Velocity portlet plugin. Velocity portlets are a relatively simple way of building tools that can be built into the backend of dotCMS and be used as tabs that users can access. In this case, this plugin builds a portlet that includes the Freenode web based IRC client and an extra collaboration tool. We will deconstruct the plugin piece by piece so that you can see the components needed for such a tool.

To start off, you’ll want to set up the files and folders that you’ll need for the plugin. A basic portlet only requires a handful of files. The files listed in italics are required for any plugin – the rest are specific to this one:

• com.learndotcms.plugins.ircsupport
  • /conf
    • Language-ext.properties
    • plugin.properties
    • portal-ext.xml
  • /static_velocity
    • /portlet
      • irc.vm
  • build.xml
  • MANIFEST.MF

The two files in the root of your plugin are required, and extremely straightforward. The build.xml file is just to name the plugin internally, and the MANIFEST.MF file carries the specific details of the plugin. We don’t need to define a deploy class in the manifest file for this plugin, because our portlet stands on its own and doesn’t need to do anything when it’s installed. Otherwise, you can use the Deploy-Class field to list a Java class provided in the plugin that should be ran when the plugin is deployed. This can be done to do things like build a structure, add content, or do anything else that requires API interaction necessary for the plugin.

build.xml

<project name="dotCMS IRC Channel Client" default="build">
    <import file="../common.xml"/>
</project>

MANIFEST.MF

Manifest-Version: 1.0
Deploy-Class:
Plugin-Name: dotCMS IRC Channel Client
Plugin-Version: 1.110106
Author: Michael Fienen (http://learndotcms.com)

From there, you’ll set up the two folders: /conf for the configuration elements, and /static_velocity/portlet which will store the code for our portlet. There’s very little configuration needed, and if you use the Hello World plugin as an example, it’s easy to modify. The language extension file is used to define the name of the portlet that will be visible in the back end:

Language-ext.properties

javax.portlet.title.EXT_IRC_SUPPORT=dotCMS IRC Client

In our portal extension file, mostly we just set the portlet name and the path to our Velocity file that will be used for the portlet. Take note that the portlet-name node (line 3) corresponds to the portlet title value from Language-ext.properties file. You’ll also set the view-template value on line 8 to correspond to your path inside the /static_velocity folder of your plugin.

portal-ext.xml

<!-- Use this file to add portlets and extend the portlet file -->
<portlet>
    <portlet-name>EXT_IRC_SUPPORT</portlet-name>
    <display-name>dotCMS IRC Client</display-name>
    <portlet-class>com.liferay.portlet.VelocityPortlet</portlet-class>
    <init-param>
        <name>view-template</name>
        <value>/static/plugins/com.learndotcms.plugins.ircsupport/portlet/irc.vm</value>
    </init-param>
    <expiration-cache>0</expiration-cache>
    <supports>
        <mime-type>text/html</mime-type>
    </supports>
    <resource-bundle>com.liferay.portlet.StrutsResourceBundle</resource-bundle>
    <security-role-ref>
        <role-name>CMS User</role-name>
    </security-role-ref>
</portlet>

Finally, the plugin.properties file is required, and can be left simply as:

plugin.properties

## The default for the reload.force is true.  If it is set to false the properties will only load once from
## the file. After that they will be stored and maintained in the database.  If true every time the server
## restart the properties will be cleared and reloaded.
reload.force=true

Now, the fun starts. The heavy lifting for this plugin happens almost entirely in the irc.vm file. As a Velocity portlet, dotCMS effectively takes the file you define above in the portal extension file and wraps it in the back end tab structure, making it look nice, and allowing you to use code you are familiar with. We’ll start the file with some simple Velocity code that takes care of checking some cookie values and setting up option defaults:

irc.vm (part 1/3)

## SEE IF A DEFAULT IRC NICKNAME HAS BEEN SET
#set($dotCMSIRCNick = $cookietool.get('dotCMSIRCNick').value)
#if($dotCMSIRCNick)
    ## SET THE STRING USED IN THE iframe SOURCE URI FOR PRESET NICKNAME
    #set($enableNick = "nick=$!{dotCMSIRCNick}&")
#end
## LOOK FOR DEFAULT HEIGHT AND WIDTH FOR THE POPUP CHAT CLIENT
#set($ircPopupW = $cookietool.get('ircPopupW').value)
#set($ircPopupH = $cookietool.get('ircPopupH').value)
## IF NO HEIGHT OR WIDTH DETECTED, USE DEFAULTS
#if(!$ircPopupW || $ircPopupW.length() == 0)
     #set($ircPopupW = 640)
#end
#if(!$ircPopupH || $ircPopupH.length() == 0)
    #set($ircPopupH = 400)
#end
## ACCOUNT FOR THE INNER HEIGHT OF THE POPUP CHAT CLIENT
#set($ircPopupIframe = $math.sub($ircPopupH,22))

Next, we hit some basic CSS for the layout, and a whole lotta JavaScript. The JavaScript handles the popups (for chat and the Collabedit windows), and setting values from the option popup.

irc.vm (part 2/3)

<style type="text/css">
${esc.h}credit {
    font-size:.8em;
    position:absolute;
    right: 0;
}
${esc.h}ircButtons {
    position:relative;
    text-align:center;
}
${esc.h}ircContainer {
    margin:1em auto;
    width:80%
}
    ${esc.h}ircContainer iframe {
        border:1px solid #ccc;
        height:400px;
        margin:1em 0 2em;
        width:100%;
    }
.subNavCrumbTrail {
    margin:-7px 0px 10px;
}
</style>

<script type="text/javascript">
dojo.require("dojo.cookie");
dojo.require("dijit.form.Button");
dojo.require("dijit.form.TextBox");

/* Set up configurable settings based on cookie default values */
var ircPopupH = '$!{ircPopupH}';
var ircPopupW = '$!{ircPopupW}';
var iframeH = '$!{ircPopupIframe}';
var nick = '$!{dotCMSIRCNick}';

/* Set the user options from the popup form */
setCookie = function() {
    /* Get config field values */
    var isValid = true;
    var nickVal = document.getElementById('ircNick').value;
    var popupW = document.getElementById('popupW').value;
    var popupH = document.getElementById('popupH').value;

    /* Validate the fields */
    if(!isAlpha(nickVal) || !isNumeric(popupW) || !isNumeric(popupH)) {
        isValid = false;
    }

    if(isValid) {
        /* Default IRC Nickname */
        nick = nickVal;
        dojo.cookie("dotCMSIRCNick", nick, {
            expires: 365
        });

        /* Default Chat Window Popup Width */
        ircPopupW = popupW;
        dojo.cookie("ircPopupW", popupW, {
            expires: 365
        });

        /* Default Chat Window Popup Height */
        ircPopupH = popupH;
        iframeH   = ircPopupH - 22;
        dojo.cookie("ircPopupH", popupH, {
            expires: 365
        });
        dijit.byId('optionsDiv').hide();
    } else {
        alert('Please check configuration settings');
    }
};

/* Open IRC chat popup window */
openIRCPopup = function() {
    newwindow = window.open('','irc','height=' + ircPopupH + ',width=' + ircPopupW + ',resizable=0');
    var tmp = newwindow.document;
    tmp.write('<html><head><title>dotCMS IRC Client</title>');
    tmp.write('</head><body style="margin:0;padding:10px;">');
    tmp.write('<iframe style="width:100%;height:' + iframeH + 'px;border:1px solid #ccc;" src="http://webchat.freenode.net?nick=' + nick + '&channels=dotcms&uio=MTE9MjM20f"></iframe>');
    tmp.write('</body></html>');
    tmp.close();
};

/* Open options popup */
showOptions = function() {
    dijit.byId('optionsDiv').show();
};

/* Open a collabedit popup */
collaborate = function() {
    window.open('http://collabedit.com/new','collabedit','top=200,left=200,height=600,width=800,resizable=1,status=0,location=1,menubar=0,directories=0');
}

/* Validator functions */
isNumeric = function(str) {
    return str.match(/^\d+$/);
};
isAlpha = function(str) {
    return str.match(/^[A-Za-z0-9_-]*$/);
};
</script>

Finally, we just need to lay out the HTML for the visible part of the portlet. In this case, we use an iframe embed for the Freenode web IRC client (based on qwebirc). Below that, a few buttons that allow the user to open a popup with the chat client in it (created using the openIRCPopup() function above on line 76), open a popup with a Collabedit panel in it (useful for brainstorming or trying to get help from folks in the IRC channel), and finally the options popup. Be sure to note in the HTML the use of Dojo properties on the buttons and dialog to make the look and feel of everything blend in with the rest of the backend.

irc.vm (part 3/3)

<div class="subNavCrumbTrail">
    <ul>
        <li id="selectHostDiv" style="" onclick="window.location='/admin';"><img src="/html/images/icons/globe-grey.png" width="16" height="16" title="global page" align="absmiddle" hspace="5" />Home</li>
        <li><span>dotCMS IRC Chat</span></li>
    </ul>
    <div class="clear"></div>
</div>  <!-- .subNavCrumbTrail -->
<div class="clear"></div>

<div id="ircContainer">
    <iframe src="http://webchat.freenode.net?$!{enableNick}channels=dotcms&uio=MTE9MjM20f"></iframe>

    <div id="ircButtons">
        <div id="credit">
            Brought to you by <a href="http://learndotcms.com/" target="_blank">LearndotCMS.com</a>
        </div>  <!-- ${esc.h}credit -->

        <button dojoType="dijit.form.Button" iconClass="browseIcon" onClick="openIRCPopup();" tabindex="0">Popout Chat</button>
        <button dojoType="dijit.form.Button" iconClass="publishIcon" onClick="collaborate();" tabindex="1">Collaborate</button>
        <button dojoType="dijit.form.Button" iconClass="editIcon" onClick="showOptions();" tabindex="2">Options</button>
    </div>  <!-- ${esc.h}ircButtons -->
</div>  <!-- ${esc.h}ircContainer -->

<div id="optionsDiv" dojoType="dijit.Dialog" title="IRC Options" style="display:none;">
    <p><label for="ircNick">Default Nickname:</label> <input type="text" name="ircNick" id="ircNick" tabindex="3" value="$!{dotCMSIRCNick}" /></p>
    <p><label for="popupW">Popup Size:</label> <input type="text" name="popupW" id="popupW" tabindex="4" value="$!{ircPopupW}" placeholder="w" size="3" />px by <input type="text" name="popupH" id="popupH" tabindex="5" value="$!{ircPopupH}" placeholder="h" size="3" />px</p>
    <div style="text-align:center;">
        <button dojoType="dijit.form.Button" iconClass="saveIcon" onClick="setCookie();" tabindex="6">Save Options</button>
        <button dojoType="dijit.form.Button" iconClass="cancelIcon" onClick="dijit.byId('optionsDiv').hide();" tabindex="7">Cancel</button>
    </div>
    <div>
        <small><em>Clear your cookies to reset IRC settings to their defaults.</em></small>
    </div>
</div>

Now, save all this stuff out, and dump your folder into the /plugins directory in your dotCMS install. From here on out, it’s all simply configuration. Start but shutting down your server, open a command prompt, navigate to the dotCMS directory and run the command:

• ant clean-plugins deploy-plugins

Set up a new portlet on a tab

Then, start dotCMS back up, log in to the back end, and under the CMS Admin tab open up Roles, Tabs, & Tools. How you deploy this particular portlet is up to you. For instance, you could create a new tab and dedicate it to the chat client, or make it a child of an existing tab, such as the Hometab. In the screenshot to the left we have opened up the Hometab and selected the new portlet from the Toolsdropdown list. Click the Addbutton, and you can drag and drop the portlets in the order you want them to appear in the menu (if you create a dedicated tab, you can just put one portlet on it and there won’t be a menu, clicking the tab will just go straight to it.). Refresh the page, and you’re golden. You can repeat this process for whichever roles you want to have access to the client.

The IRC Portlet plugin

Wherever you tell dotCMS to load the portlet, clicking on it will open a page that will read in the source VM file from your plugin. In our case, it shows our embedded chat client, and extra buttons. By researching the setup of other portlet pages in the backend, applying the appropriate markup to the buttons results in a very familiar feel, allowing you to build something that isn’t just crowbarred into the backend (though, nothing’s stopping you from doing it ugly, it’s just really easy to get that extra polish).

Options popup

We also added a Dijit powered dialog box to control the portlet options. All it is needs is a hidden div with some markup, and Dojo handles the rest (lines 24-34 in irc.vm part 3). In some cases, you can hardcode plugin options into the plugin.properties file. That’s fine. In this case, I wanted the options to be specific per user, without going through the effort of tying into the user settings. The answer was simply adding in a little JavaScript to set up cookies that will last for a year on the machine. When the page loads, we read in those cookie values and use them to customize the chat client and its popup.

Overall, this is about as simple a process as you could ask for. Being Velocity powered, you can access anything you would normally be able to get into on web pages. That might be usage of viewtools, pulling content, or utilizing macros. Better yet, you don’t need to learn any complex Struts mapping or Java code to try it out.

[ Download the IRC Plugin (v1.110106) ]

Image Gallery

As I sat at my desk recently looking at parts of our site that need attention, thinking about page layouts and design concepts, a thought came to me. This is not a new thought, nor a groundbreaking one. It is, however, an important one that I think a lot of us, especially at smaller universities or in smaller offices, lose sight of. That is the premise that we need to do less better. Makes sense right? Totally logical. But how to turn knowing into doing, that’s the real challenge.

The problem: the reality of the situation is that in most cases our sites are simply too big for the staffing in place to maintain them (effectively). Yes, we get by. Getting by just doesn’t really seem good enough though, does it? I would argue that it should never be just “good enough.” Like Detroit (sorry Nick), our sites end up a sort of sprawling metropolis that has a reasonably decent core and plenty of interest in revitalization – but behind the curtain is a growing wasteland of urban decay. You try to fix things up, but really, you should be tearing down. People navigating around follow their GPS, but ultimately end up in a bad neighborhood with the sun setting. In our world everyone thinks everything needs to be on the site. That’s not a content strategy – that’s giving up. All it does build up layer upon layer of ROTting (redundant, outdated, trivial) content.

It’s a new year, and what better time to start really looking at your site and how you can consolidate, remove, and focus. One example we are dealing with has to do with campus life. We have a student activities office, campus activities, campus recreation, the union, and a host of other offices and services available that students need information from (I use the word “need” literally because this is, in many cases, stuff they should be paying attention to but can’t under the current setup). The problem is that right now our top level Campus Life page is an unfocused attempt at drawing prospective students. The rest of the information is scattered across the site. On top of it, there’s confusion because we have an actual office named “Campus Life” in juxtaposition to the idea of campus life. The result is a lot of information doing nothing well, with two audiences that we are failing to serve.

In this case, we sat down with the Campus Life office and looked at both the top level page along with all their sub-office sites. We looked at what was there, planned out how to simplify the presentation of the content, broke down a few of the hierarchical walls, started a content audit, and focused on creating simple content that would do a specific job in a logical home. Instead of assorted, generic top level pages, a primary office page, and a bunch of sub-office sites, we distilled it down to a single landing page that will filter down to each individual service (keeping in mind the service is what is important to the students, not the office that provides it). Additionally, we looked at the governance of that content, identifying how we could reduce the number of people involved so that it would be easier to telegraph what was happening.

The benefits of refocusing like this are many:

• Less duplicate and redundant data improves SEO
• An improved and more predictable UX provides a logical destination page
• Less overall maintenance work involved helps ensure content is more accurate and better maintained

With a CMS, we tend to start giving people control of content without thinking about how it serves the overriding needs of the audience. To quote Jurassic Park: “Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” Take a step back and look at your site. Look at the information on it. Look at how and where content and information is being handled. If you’re trying to serve everyone, and you give anyone the ability to create anything, then what is the value of what is being created? When everything is low quality, like a nice home on the bad side of town, the value the important things won’t be appreciated.

I recently discussed this with some folks in terms of a project triangle. You can have your website development done frugally/cheaply, quickly/safely, or successfully – pick two. In many cases, the frugal option has been chosen for us. And obviously we want to be successful. That means we need to throw away the idea of doing everything quickly. Time and effort needs to be put in to the content and sites we make. In most cases, the people put in charge of Office X’s website won’t and can’t put in that time. The value in what we do is not in quantity. Our sites aren’t better because we can get to 100,000 pages and beyond. It would be much better to focus on 1,000 really great pages. It can be a hard fight to take up with people that see the only solution to be the frantic expulsion of as much information as possible, tempered against the desire to not rustle the feathers of administrators.

This whole argument has been set to reinforce my long held belief that content experts are not experts at content. We’ve also got to consider a serious, concerted effort to put in place good web governance. Good web governance isn’t about honoring the university hierarchy, it’s about building processes that create valuable content for your audiences. Making offices and departments happy by allowing them to create as much as they can as quickly as they can is done at the expense creating truly useful, valuable information on your site. Instead, it’s just an ever increasing amount of noise in the channel. Like a cancer, it will eat away at the site until a few years from now you have to start the whole mess over again, and the cycle starts over. Many of us have already been through it one, two, or more times. And yet, it’s so easy to break that cycle. 2011 is a new year, and we are slowly getting better and better at handling visitor needs. We just need to start making one principle a part of our everyday processes, despite the challenges that come with it in the short term.

Do. Less. Better.

Photo credit: Some rights reserved by Phil Manker

Related posts:

1. Learning SEO From Lady GaGa
2. Need a Link Building Strategy? Create Content!
3. The Three Pages That Every Site Should Have