April 18, 2003
Heterogenous RSS Versions
So today I downloaded SharpReader, a .NET news aggregator. I've tried Radio Userland and didn't like it for too many reasons to go into in this post, as well as Amphetadesk. I really don't like a news aggregator that runs in the browser. I'll probably also test out Syndirella and NewzCrawler, for comparison.
One thing I noticed immediately is that in RSS 0.91 feeds, the posts all have a time/date stamp that is the time the aggregator downloaded the item. That's ridiculous. Is that a SharpReader problem, or is that part of the RSS 0.91 spec? RSS 1.0 posts actually have the time of the post as the time/date stamp, which is how it should be.
The nice part of SharpReader, which I don't believe Radio or Amphetadesk have, is the ability to group your feeds, and view them in an aggregate group view. That approaches the "personal newspaper" model, so I get a variety of people's posts mixed together. Default sort is reverse chronological, but I can also sort by source. Of course, RSS 0.91 feeds screw that all up, because you'll have a big chunk of those authors posts plopped in the middle, since they're all tagged with the download time, instead of the actual posting time. :-/
With that in mind, I'm publishing an RSS 1.0 feed for this weblog, in addition to the RSS 0.91 feed I had. I'd get rid of the 0.91 feed, except that some people may have already subscribed to it. I'd recommend the 1.0 feed.
Posted April 18, 2003 02:12 PM | Permalink
April 16, 2003
The Pain of Multiplicity Heterogeneity
First, a note: If you're just catching up on this conversation via the blurb in Online Learning Daily, you might want to start with George Siemens' post, then my response, then back and forth. I'm putting out one more attempt at clarity, then dropping out of this thread. :-)
George wants to point to complexity as the enemy of standards. Stephen Downes said "Complicated standards result in complicated and inflexible software, exactly what people don't want and don't choose." I agree with Stephen's point, and I want to make it clear that I don't think complexity should necessarily be the ultimate goal, in and of itself. However, neither do I think complexity is the enemy.
The "pain of multiplicity" I referred to comes about when we wind up with with either multiple, heterogenous standards or multiple, heterogenous versions of the same standard. The "pain of multiplicity" could also be expressed as the "pain of heterogeneity." Come to think of it, heterogeneity is really the term I should have used, instead of multiplicity.
In our field, we have an alphabet soup of standards (IMS, AICC, SCORM, ARIADNE, LTSC LOM, SIF, etc.) that only overlap somewhat, nevermind being interoperable. The goal should be to bring the work that has been done together, to homogenize that heterogenity. It seems to me that these standards bodies are making progress on bringing these standards together. I'd like to see that process reach its end before we scrap it. Is the way we're getting ot the end -- i.e., resolving a half-dozen different specifications -- the best route? Probably not. But it's where we are; I don't see going back to the starting point or introducing yet another new "simple" standard as a solution that moves us away from the heterogeneity.
I would hate to see the form of heterogeneity we have now (multiple standards) be replaced by a different form of heterogeneity (many multiple versions of the same standard). I think that situation can be caused by rapid release of different versions of a simple standard, as George appears to advocate. I think of the "Best Viewed With ___" buttons that arose in the mid-nineties browser wars, while Netscape and IE proliferated multiple browser versions, each with their own quirky takes on the simultaneously evolving HTML standard. Or the fiasco around the RSS 0.93/1.0/2.0 iterations last year that froze anyone want to do RSS development. This is why I argue that standards definition can't follow the open source software development credo of "release early, release often" and remain effective as a standard while doing so.
A simple standard? Sure, I'm all for that. I think we'll see if the recent work with RSS and RLOs will bear fruit, so maybe the proof is in the pudding (to mix my food metaphors). I think we all probably agree that complexity, in the sense of multiple, heterogenous standards, is problematic. However, I believe that complexity, in the sense of standard that obtains its flexibility through richness and depth, is preferable to flexibility obtained through rapid, iterative releases.
The latter has the potential to result in a situation where we have different software or tools that support different versions of the same standard. Choice is best provide when different software supports the same standard. That's when the end users win.
[Please note: this post wins the award for All-Time Most Instances of the Word "Heterogeneity." In accepting this award, I'd like to thank the academy for teaching me to use five-dollar words like "heterogeneity" and "serendipitous" and "masticate."]
Posted April 16, 2003 09:24 PM | Permalink
April 15, 2003
The Pain of Multiplicity
George Siemens responds to my comments. He writes:
the standards are being built ahead of use...."we build it...you move in".I don't believe you can create standards like you build software. "Release early, release often" doesn't work for standards. Standards, by definition have to be . . . well, standard! If you release often, you have something that changes frequently, the antithesis of "standard." (Although many would say that's where we are with SCORM today!)Standards should be created to allow for the injection of experience. The open source community has something to offer in this area: build functionality and features as users define them to be important...release early, release often - let the users needs speak to the standards development. It doesn't matter how simple you make the end user process...if the standards haven't reflected their wants and needs - you may have a simple process...but one that's not useful.
Nore are these standards being developed in a vacuum absent any experience with users. SCORM is building on, as David Carter-Tod said yesterday, "the military's long involvement in training and instructional design in the U.S. (basically, the second world war: 'Quick, train several million civilians to be soldiers')." AICC, which forms at least part of the core of most of the other standards (SCORM, IMS, ARIADNE, IEEE LTSC, etc.) comes out of decades of real-world experience with computer-based training. Of course, as David went on to note, these might not be the users people in higher ed want the models based on. I think that's a valid concern that I hope IMS is addressing.
Everyone in the instructional technology community is feeling frustration over this standards stuff. But I don't think the issue is the complexity of the standards, nor do I think the issue is a disconnect between the standards and the functional needs/desires of users.
We are at -- and have been for a decade or more -- the "Beta/VHS" stage of instructional technology standards. There are multiple standards that don't mesh together well. That's nothing new. The difference now is this stuff we call e-learning is becoming widespread. There is an increasing need for stuff to work well together, and it just doesn't yet. The education community is feeling the pain of multiplicity.
George said "the greatest enemy is complexity." I disagree. Complexity in standards is fine; multiplicity is the enemy of standardization.
The good news is, the pain of multiplicity forces standardization to move forward, whether it's Beta losing out to VHS, or all the instructional technology standards coming together under the SCORM umbrella. As George recently noted himself, progress was made at bringing all the various standard closer together at last month's IEEE LTSC meeting.
Keep your fingers crossed. :-)
Posted April 15, 2003 10:11 AM | Permalink | Comments (1)
Don't Bloggerize eLearning
Bloggerize the tools!
George Siemens posts thoughts on complexity at his elearnspace weblog:
We need a simple standard...something that people can actually understand. If instructional technologists have trouble grasping the complexity of standards...the average instructor will NEVER adopt or use them.I don't believe this is correct, particularly the part about the need for a "simple standard." Here's the reason why: users don't use standards; they use software. Think about it: when was the last time you hand-coded an HTTP request? I don't mean typed "http://etc" into the browser's address field, but actually had to go check the HTTP 1.1 spec, to code the request headers, that stuff the browser usually takes care of? Or, raise your hand if you code the XML for your weblog's RSS feed by hand -- or is it automagically generated for you by Movable Type or some other weblog tool? Uh-huh. Thought so.The current gap between those setting standards and those who are supposed to be using them seems to be growing. There is a simple solution. We need to "Bloggerize" elearning. The act of using and posting a learning object should be as simple as setting up an account with Blogger (5 minutes). Make it easy to start...and add complexity as the users request it. Right now, we have the architects building a house...assuming that people will move in once it's complete. Unless they (architects) start exploring the needs of the "tenant"...the tenants will end up building their own.
Unless you're a programmer, you probably never have to understand standards like TCP/IP, HTTP, SMTP, XML, or RSS to make use of them. But, if you're like me, you might make hundreds or even thousands of HTTP requests each day, send dozens of emails via SMTP, syndicate your weblog posts via XML formatted to the RSS spec, etc. . . . but you have never actually read any of the specifications for those standards. Why? Because the software -- the browser in the case of HTTP, a weblogging tool in the case of RSS feeds, etc. -- provides you with an interface that abstracts the standard, allowing you, the end user, to work with it without understanding it.
One purpose of software is to abstract interactions so end users don't have to understand protocols and standards.
Turn this on Siemens' idea. It really doesn't matter how complex the standard is, as long as the software that allows us to make use of the standard is simple. Eventually, no "average instructor" will need to understand SCORM or IMS or the definition of a learning object. The software they use will manage that understanding for them.
The instructors will just launch their ACME All-in-One Wonder Tool For Instruction™, drop some content into the good ol' Wonder Tool, and answer some questions about their content (metadata!). Click the "Done" button, and the Wonder Tool spits out a standards-compliant learning object that can be dropped into any course management system. Or, if they want to share it, they click the "Share" button, select from a list of options of who to share with (individual users, my department, my college, everyone), and *poof!* -- it's available to others. No slogging through dense technical documents required!
No users of the web chooses to adopt or use HTTP. You use it because it's the standard that the web browsers adhere to. You don't say, "I'm going to use SMTP because it's the best email protocol out there!" every time you send an email to someone else on the Internet; you use it (and probably don't even know it!) because your email program adheres to that standard.
Likewise, no instructor will "choose" to adopt SCORM (or whatever standard prevails). They'll use it because it's the standard their content providers, their content authoring tool vendors, and their content delivery systems adhere to.
Dumbing down the standard won't make a difference, except to potentially rob the teaching and learning community of potential functionality. It's not the standards that need to be "bloggerized." Blogger is a tool that makes use of common web publishing standards (HTTP, HTML, FTP, etc.). It's powerful becuase it greatly abstracts those standards (and the processes of using them) to "push-button" simplicity. That level of simplicity is important in the tools that make use of the standards, but it's not necessarily required in the standards themselves.
Posted April 15, 2003 06:13 AM | Permalink | Comments (4)