Friday, November 04, 2005

On killing off apps to be supported and doing something new

Sorry about not posting for a week. I started to write a longer essay last weekend and it didn't turn out to my liking, so I got a case of writer's block. I might get back to that piece in a while, but for now will stick with somewhat more modest themes.

*******

I want to do a little stroll down memory lane with the hope of providing a lesson for here and now.

I started to run the organization called SCALE (Sloan Center for Asynchronous Learning Environments) in September 1996. Within the next 6 months or so, not recalling this all too well, we killed off support of an application called PacerForum. This was a very popular Mac-based conferencing system. But it relied on AppleTalk protocol rather than TCP-IP and it was unable to make the transition. The company that made PacerForum went belly up. We continued to support it for a while after they went bankrupt (a bad idea) but that was untenable so we dropped it. Our users knew nothing of this. They just knew they liked the software and we stopped supporting it. So we were the bad guys.

That same year we started to support a Web based conferencing program called WebNotes from the company Sypglass (which got the Mosaic license from the University). At the time our mainstay conferencing system was FirstClass, but that required a dedicated client at the time. FirstClass was pretty popular, but some people wanted a Web system, even in 1996 when I believe the browser was Netscape 2.0. There was some uptake of WebNotes (I used FirstClass in my own teaching) but the product was a dog and after a year we dropped it for an alternative, WebBoard.

We continue to support WebBoard to this day. And we continue to support Mallard. Those were the mainstay apps I used in teaching my intermediate microeconomics course. I switched from FirstClass to WebBoard perhaps in 1998, primarily because there were some support issues with the students installing the FirstClass client. Many other of our users did likewise.

FirstClass did come out with a Web client but it was not sufficiently differentiated to justify supporting it. So we did end the FirstClass service in December 1999. There were only a few dedicated users at the end, but I think we lost those people permanently to other environments. I don't believe they came over to WebBoard or the CMS products we had started to support.

What is the lesson? It is that if we start to support something we really can't stop supporting it unless the product is a dog or unless the provider no longer supports the product. There is an implied commitment to ongoing service. One might think that we can go to something else that is "better" but beauty is in the eye of the beholder and loyal constituencies form for any environment that has been useful to the instructors.

We are now in a situation where new apps are appearing in abundance and there are many alternatives from which to choose. Moreover, it is apparent that things are changing at a rapid pace. Is this the time to "lock in" to a particular path, say to hosting Drupal or Movable Type?

Now let me do a tiny bit more history. In fall of 2003, Educause Review published a review/critique of a piece that appeared earlier that year in Harvard Business Review called "IT Doesn't Matter," which is reprinted in that same volume of Educause Review. That article depressed me quite a bit, because I bought much of the argument. The essence is that if the IT organization is providing utility services that are really "commoditized" then IT doesn't matter. So a second question is whether the new collaboration technologies are commodities, which the market should provide, or value added applications, which campus IT should provide. Personally, I lean toward the commodity side in answering that question.

When talking with college level administrators who support IT, they might very well conclude likewise. When talking with early adopter faculty, these lessons are extremely frustrating. They are immersed in the new collaboration technologies and want to see the campus right along with them. My final question, one I don't know the answer to, is whether that is the nature of the beast or if there is some other way to frame the issue so the early adopter folks feel more comfortable with what the campus is doing.

2 comments:

John Murphy said...

I'm an early adopter and I've used WebCT CE at two universities and Vista for the last year to supplement traditional f2f classes. I'm switching to Drupal because I like the flexibility and individualization it offers (like student blogs, comments througout the site, collaborative writing, and RSS feeds) and the challenge of learning to use Drupal, MySQL, and PHP (not to mention the satisfaction of being "master of my own domain"). I don't expect the rests of the faculty who use Vista to switch to Drupal. I've heard the argument in favor of Vista that it offers students an interface that is consistent from class to class. But students these days are comfortable with learning new interfaces for myspace/facebook/livejournal/xanga/whatever comes next. I'm not comfortable with WebCT/Blackboard deciding what tools I will be able to use. I want a site that is as individualized as my teaching style and my students' styles of expression, and I like the fact that there are a large number of modules available for Drupal and the interface is easily modified with CSS.
Lanny asks "if there is some other way to frame the issue so the early adopter folks feel more comfortable with what the campus is doing." This early adopter is comfortable with the campus doing whatever it wants (I think Vista is an excellent commodity) while allowing me the freedom to experiment.

Lanny Arvan said...

John - Thanks for the comment. (I'm posting my response Monday evening.)

You've hit on something in allowing instructors who so desire to experiment with whatever technology they choose. I'd like to find a way to do that where there is a bit more cost sharing than what you propose, where you are bearing all the support cost.

Here we don't know how to do experiments that might not become services, even if they are successful, so the issue is somehow to cut the tie between experiment and commitment to future service.

But of course if there were enough of you who try Drupal and really like it, then it should become a service.