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.
Standards, Syndication & Aggregation
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.
Read more…
Education, Standards, Syndication & Aggregation
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”.
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.
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!)
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. :-)
Education, Standards
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.
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.
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.
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.
Read more…
Education, Standards