As I mentioned in a previous post the SUNY Learning Network currently uses a home-grown learning management system built on top of Lotus Notes. And while there is a web interface to the system, many of the current users are quite attached to their fat client.
This may sound quaintly outdated at the moment. However, I strongly suspect that we’ll see fat(ter) LMS clients in the near future. There are some wonderful affordances that come with a more robust client-side component to the system. Up until now, those affordances have come with the relatively steep price of having to develop, install and maintain fairly heavy-duty (and often cross-platform) client-side software. But that’s changing. These days, the browser and the operating system themselves are increasingly able to function as client-side platforms for richer functionality. Add to this the blossoming of web services and the small, simple client-side tools that they enable, and we have the potential for what I would call “lean clients,” “plump clients” and “chubby clients.”
“Lean Clents” is what I’m calling web-based systems that afford richer interfaces using only the client-side technologies that come bundled with your computer, i.e., your operating system and your browser.
Here are a couple of examples:
- Gmail: Anyone who has used webmail is familiar with the pain web intefaces. The simplest tasks take forever. This is because, under normal circumstances, web pages can’t just update the information that changes; you have to refresh the entire page just to, say, seen the preview of the next email you click on in your inbox. Gmail solves this problem. Using a relatively new web browser command called XML HTTP Request Object, Google’s webmail service updates only the information that changes on the page. It’s the kind of thing that needs to be experienced in order to understand the value of it. GMail doesn’t feel like webmail. It feels like a desktop application. And it’s the first webmail implementation I’ve seen that I would consider using on a regular basis. In the context of a learning management system, where teachers often have to perform tedious administration tasks, an implementation of XML HTTP Request Object in the admin interface would take a lot of the pain away.
- Apple iDisk: iDisk feels like you’re working with a local disk drive (or, at worst, a network drive in the Windows world). But it works over the Internet using a technology called WebDAV. WebDAV is native technology on the Mac, as it is on Windows (where it is called “Web Folders”). In the context of a learning management system, this would allow teachers to create, edit, and organize their content on their local machines and then essentially batch upload their content to the LMS as easily as they would copy it to a second hard drive. (And by the way, at least two LMS’s –WebCT and dotLRN– currently support WebDAV.)
There are still times when neither slim clients nor chubby clients are sufficient. Sometimes the best solution is still to develop a client-side application. But the movement these days is toward small, specialized applications that are loosely coupled to the server via standardized web services rather than heavy client-side platforms that work through some proprietary client-server protocol. This approach makes the cost of developing and maintaining the client-side component managably small compared with the benefits.
Here are a couple of examples of great chubby little clients:
- Gmail notifier: One of the great things about email is its ability to fit into our multitasking worklife. My email program sits in the background, quietly monitoring my email as I work, and then yells at me to let me know the minute something new comes in. While this can be done in a web environment, it’s awkward. Google decided it would be much easier to develop a small, specialized client-side application that does nothing but watch your Gmail account and yell at you when something new comes in. Because it’s small, Google can keep up with developing and maintaining it, even on multiple platforms. And because it’s works with a small number of published Gmail commands, it would be easy enough for other developers to build their own Gmail notifier programs, or build a notifier feature into some other program. In an LMS, this kind of little notifier function would be useful for alerting professors (or students) to new content additions or to who is currently online.
- Flickr photo uploader: Much like iDisk, the Flickr Uploader lets you work with and organize your photos offline and then easily upload them. However, because Flickr lets you add categories (tags) to your photos, a WebDAV interface wouldn’t be enough. So Flickr built a smail client-side interface that lets you upload pictures and attach the appropriate tags. This is a great type of tool for any content that is best created/organized offline but needs some specific metadata attached to it when uploaded. Which brings us to…
- Ecto: Ecto is an offline blogging client. Like the Flickr photo uploader, it allows you to work with files offline (in this case, text and HTML files) and upload them to your online system (in this case, your blog) along with category tags and other specialized metadata. I could see using something like ecto for many of the content management tasks that teachers face within most LMS systems. And because they use open standards for communications protocols, you could always swap out one client for another (like MarsEdit, for example) based on your needs and preferences.
To Sum Up…
Gmail and Flickr show that the fat client/thin client distinction is eventually going to go away. What you’ll see instead is a seamless blend that allows the kind of rich functionality that has historically required a fat client while minimizing the amount of specialized client-side code that has to be maintained. I fully expect that the next generation of learning management systems will take advantage of these technologies to make the mechanics of teaching and learning online significantly less painful.