<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Building Bridges To Nowhere</title>
	<atom:link href="http://mfeldstein.com/building_bridges_to_nowhere/feed/" rel="self" type="application/rss+xml" />
	<link>http://mfeldstein.com/building_bridges_to_nowhere/</link>
	<description>What Michael Feldstein Is Learning About Online Learning...Online</description>
	<pubDate>Sun, 12 Oct 2008 10:21:02 +0000</pubDate>
	
		<item>
		<title>By: Jesse Ezell</title>
		<link>http://mfeldstein.com/building_bridges_to_nowhere/#comment-533</link>
		<dc:creator>Jesse Ezell</dc:creator>
		<pubDate>Fri, 20 Oct 2006 13:25:51 +0000</pubDate>
		<guid isPermaLink="false">152639189#comment-533</guid>
		<description>I think building awareness of the issue--the fact that we need to start from the ground up and make better specs next time around instead of yet another more complex version of an outdated and failed spec--is the best place to start. What RSS did to content publishing we need to do to eLearning. We need simple specs that get the job done without trying to solve the world's problems. Maybe CC is a good short term solution, but anyone who is going to promote it should promote it as a bandaid on top of broken specs, not a good solution that fixes the core issues.</description>
		<content:encoded><![CDATA[<p>I think building awareness of the issue&#8211;the fact that we need to start from the ground up and make better specs next time around instead of yet another more complex version of an outdated and failed spec&#8211;is the best place to start. What RSS did to content publishing we need to do to eLearning. We need simple specs that get the job done without trying to solve the world&#8217;s problems. Maybe CC is a good short term solution, but anyone who is going to promote it should promote it as a bandaid on top of broken specs, not a good solution that fixes the core issues.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Feldstein</title>
		<link>http://mfeldstein.com/building_bridges_to_nowhere/#comment-530</link>
		<dc:creator>Michael Feldstein</dc:creator>
		<pubDate>Thu, 19 Oct 2006 04:37:40 +0000</pubDate>
		<guid isPermaLink="false">152639189#comment-530</guid>
		<description>These are fair points, Jesse. So what would your advice to faculty be? How can they use their clout to advocate effectively for change that will lower costs, increase competition, and make their course content reliably portable?</description>
		<content:encoded><![CDATA[<p>These are fair points, Jesse. So what would your advice to faculty be? How can they use their clout to advocate effectively for change that will lower costs, increase competition, and make their course content reliably portable?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse Ezell</title>
		<link>http://mfeldstein.com/building_bridges_to_nowhere/#comment-529</link>
		<dc:creator>Jesse Ezell</dc:creator>
		<pubDate>Thu, 19 Oct 2006 03:14:34 +0000</pubDate>
		<guid isPermaLink="false">152639189#comment-529</guid>
		<description>You're right, teacher's shouldn't worry about how hard specs are to implement... however, they should be aware of the reason why their LMS is so expensive. They should also think carefully about supporting a standard made by the same people who offered promises of a land where everyone's content works on everyone's system the last time around. SCORM was supposed to give us portability. QTI was supposed to give us portability. They didn't.

If SCORM didn't really solve the problem it was supposed to solve and QTI didn't really solve the problem it was supposed to solve, then why are we going to add another spec mandating that we use these failed specs? By supporting a needlessly complex spec like this, you are raising the bar for entry into the market and thereby reducing the amount of innovation that happens and increasing the costs of future products. Of course, Blackboard doesn't care that the bar is so high, nor do any of the other companies trying to push million dollar LMSes down your throat. They've already spent that millions dealing with all the messy SCORM and QTI issues and writing adapters for everyone's content. By keeping these specs on the table, they save themselves the hassle of really having to code anything all that innovative or new and they make it extremely difficult for anyone to come in and replace them or offer a decent alternative. Why would they promote a spec that makes it easy for some kids in their garage or some hot new startup to blow them out of the water?

It's time that people knew why they spend an arm and a leg for basic functionality. It's time that people realize why their LMS seems so old and stale. A lot of it boils down to the elephant in the living room, the standards that just about everyone admit are horrible but no one is willing to replace.

In any case, just to give you an idea of how needlessly complex QTI is. Consider the following QTI XML to define a simple question (IMO, it shouldn't take 75 lines of barely comprehensible XML to define a simple multiple choice question):

&lt;item title="How hot is it?" ident="I0003" maxattempts="1"&gt;
&lt;itemmetadata&gt;
&lt;qmd_itemtype&gt;choice&lt;/qmd_itemtype&gt;
&lt;fieldlabel&gt;qmd_itemtype&lt;/fieldlabel&gt;
&lt;fieldentry&gt;&lt;![CDATA[choice]]&gt;&lt;/fieldentry&gt;
&lt;qmd_toolvendor&gt;Articulate&lt;/qmd_toolvendor&gt;
&lt;/itemmetadata&gt;
    &lt;presentation&gt;
        &lt;answerfontsize&gt;14&lt;/answerfontsize&gt;
        &lt;material&gt;
            &lt;mattext texttype="text/html"&gt;&lt;![CDATA[&lt;FONT SIZE = "14"&gt;How hot is it?&lt;/FONT&gt;]]&gt;&lt;/mattext&gt;
        &lt;/material&gt;
        &lt;response_lid ident="I0003_RL" rcardinality="Single" rtiming="No"&gt;
            &lt;render_choice shuffle="Yes" minnumber="1" maxnumber="3"&gt;
                &lt;response_label ident="I0003_1"&gt;
                    &lt;material&gt;
                        &lt;mattext texttype="text/html"&gt;&lt;![CDATA[Very hot]]&gt;&lt;/mattext&gt;
                    &lt;/material&gt;
                &lt;/response_label&gt;
                &lt;response_label ident="I0003_2"&gt;
                    &lt;material&gt;
                        &lt;mattext texttype="text/html"&gt;&lt;![CDATA[Not very hot]]&gt;&lt;/mattext&gt;
                    &lt;/material&gt;
                &lt;/response_label&gt;
                &lt;response_label ident="I0003_3"&gt;
                    &lt;material&gt;
                        &lt;mattext texttype="text/html"&gt;&lt;![CDATA[cold]]&gt;&lt;/mattext&gt;
                    &lt;/material&gt;
                &lt;/response_label&gt;
            &lt;/render_choice&gt;
        &lt;/response_lid&gt;
    &lt;/presentation&gt;
&lt;resprocessing&gt;
        &lt;outcomes&gt;
            &lt;decvar vartype="Integer" defaultval="0" varname="qmscore"/&gt;
        &lt;/outcomes&gt;
        &lt;respcondition&gt;
            &lt;conditionvar&gt;
                &lt;varequal respident="I0003_RL"&gt;I0003_1&lt;/varequal&gt;
            &lt;/conditionvar&gt;
            &lt;setvar varname="qmscore" action="Add"&gt;18&lt;/setvar&gt;
            &lt;displayfeedback feedbacktype="Response" linkrefid="I0003_FB_1"/&gt;
        &lt;/respcondition&gt;
        &lt;respcondition&gt;
            &lt;conditionvar&gt;
                &lt;varequal respident="I0003_RL"&gt;I0003_2&lt;/varequal&gt;
            &lt;/conditionvar&gt;
            &lt;setvar varname="qmscore" action="Add"&gt;0&lt;/setvar&gt;
            &lt;displayfeedback feedbacktype="Response" linkrefid="I0003_FB_2"/&gt;
        &lt;/respcondition&gt;
        &lt;respcondition&gt;
            &lt;conditionvar&gt;
                &lt;varequal respident="I0003_RL"&gt;I0003_3&lt;/varequal&gt;
            &lt;/conditionvar&gt;
            &lt;setvar varname="qmscore" action="Add"&gt;0&lt;/setvar&gt;
            &lt;displayfeedback feedbacktype="Response" linkrefid="I0003_FB_2"/&gt;
        &lt;/respcondition&gt;
&lt;/resprocessing&gt;
    &lt;itemfeedback ident="I0003_FB_1" view="candidate"&gt;
        &lt;material&gt;
            &lt;mattext texttype="text/html"&gt;&lt;![CDATA[Correct]]&gt;&lt;/mattext&gt;
        &lt;/material&gt;
    &lt;/itemfeedback&gt;
    &lt;itemfeedback ident="I0003_FB_2" view="candidate"&gt;
        &lt;material&gt;
            &lt;mattext texttype="text/html"&gt;&lt;![CDATA[Incorrect]]&gt;&lt;/mattext&gt;
        &lt;/material&gt;
    &lt;/itemfeedback&gt;
&lt;/item&gt;</description>
		<content:encoded><![CDATA[]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Feldstein</title>
		<link>http://mfeldstein.com/building_bridges_to_nowhere/#comment-528</link>
		<dc:creator>Michael Feldstein</dc:creator>
		<pubDate>Wed, 18 Oct 2006 19:05:10 +0000</pubDate>
		<guid isPermaLink="false">152639189#comment-528</guid>
		<description>You certainly won't get any argument from me about the complexity of SCORM. (I can't speak to QTI, since I haven't been involved in any QTI implementation projects.) I guess the question is what teachers should do about the situation, since that's the audience I am addressing in this post. Most teachers don't know and shouldn't have to care about how easy or hard the standards are to implement. They *should* care, however, about how seamless and ubiquitous those implementations are. If we create market demand for this, then there will be more motivation to fight the inertia inherent in having an established specification and fix remaining problems.</description>
		<content:encoded><![CDATA[<p>You certainly won&#8217;t get any argument from me about the complexity of SCORM. (I can&#8217;t speak to QTI, since I haven&#8217;t been involved in any QTI implementation projects.) I guess the question is what teachers should do about the situation, since that&#8217;s the audience I am addressing in this post. Most teachers don&#8217;t know and shouldn&#8217;t have to care about how easy or hard the standards are to implement. They *should* care, however, about how seamless and ubiquitous those implementations are. If we create market demand for this, then there will be more motivation to fight the inertia inherent in having an established specification and fix remaining problems.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse Ezell</title>
		<link>http://mfeldstein.com/building_bridges_to_nowhere/#comment-527</link>
		<dc:creator>Jesse Ezell</dc:creator>
		<pubDate>Wed, 18 Oct 2006 08:11:27 +0000</pubDate>
		<guid isPermaLink="false">152639189#comment-527</guid>
		<description>Michael, I think you are right to some degree... . I agree that the goals of CC project are right on target. However, building a standard that standardizes on top of poor specs is hardly the way to get off on the right foot. SCORM is plain bad any way you cut it. QTI is technically better, but is needlessly complex. Building your own LMS even with the CC spec will be horrendously difficult. There is no good reason that creating a simple LMS that supports everyone's content and gives you 5 or 6 basic reports should be much harder than creating an RSS aggregator. So yes, CC does solve some problems, but it solves them in the wrong way, by creating specifications that say how to use a bunch needlessly complex specifications together, rather than starting clean and solving the root issues.</description>
		<content:encoded><![CDATA[<p>Michael, I think you are right to some degree&#8230; . I agree that the goals of CC project are right on target. However, building a standard that standardizes on top of poor specs is hardly the way to get off on the right foot. SCORM is plain bad any way you cut it. QTI is technically better, but is needlessly complex. Building your own LMS even with the CC spec will be horrendously difficult. There is no good reason that creating a simple LMS that supports everyone&#8217;s content and gives you 5 or 6 basic reports should be much harder than creating an RSS aggregator. So yes, CC does solve some problems, but it solves them in the wrong way, by creating specifications that say how to use a bunch needlessly complex specifications together, rather than starting clean and solving the root issues.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Feldstein</title>
		<link>http://mfeldstein.com/building_bridges_to_nowhere/#comment-526</link>
		<dc:creator>Michael Feldstein</dc:creator>
		<pubDate>Wed, 18 Oct 2006 06:28:33 +0000</pubDate>
		<guid isPermaLink="false">152639189#comment-526</guid>
		<description>I don't see this as an either/or issue. Both are important. And both can be helped along by active lobbying from teachers.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t see this as an either/or issue. Both are important. And both can be helped along by active lobbying from teachers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse Ezell</title>
		<link>http://mfeldstein.com/building_bridges_to_nowhere/#comment-524</link>
		<dc:creator>Jesse Ezell</dc:creator>
		<pubDate>Mon, 16 Oct 2006 06:49:56 +0000</pubDate>
		<guid isPermaLink="false">152639189#comment-524</guid>
		<description>While the common cartridge spec is an intersting idea, it is far more important that we get better specs than SCORM, QTI, etc. Even if your tags are imported just fine, the content communication specs are still so horrible and complex that you're still going to have to cross your fingers and pray that the content will work on your LMS after it is imported.</description>
		<content:encoded><![CDATA[<p>While the common cartridge spec is an intersting idea, it is far more important that we get better specs than SCORM, QTI, etc. Even if your tags are imported just fine, the content communication specs are still so horrible and complex that you&#8217;re still going to have to cross your fingers and pray that the content will work on your LMS after it is imported.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.521 seconds -->
