Andre Roberge wrote:
On 5/14/06, Andrew Harrington <aharrin@luc.edu> wrote:
Navigating Between Lessons
I have been reading the discussion and trying the prototypes for Python content delivery with great excitement. On seeing how well you were doing on the content delivery, my imagination took off and I wrote down a whole bunch of brainstorming ideas below on an important independent aspect of an interactive learning environment. Just tonight the "Only Python" thread touched on the area I have been thinking about with the idea of choosing what comes next after evaluating code in the Crunchy Frog.
[snip - snip - snip lots of interesting material cut out.]
There were a lot of great ideas expressed in this brainstorming tsunami.
Thanks!
I will latch onto a single theme.
For this to work, we need tutorials "snippets" ... lots of them.
For sure. Snippets is a good term, too.
I don't think we need to worry too much at this point about complex links between them, nor about the "syntax" required for those links. I believe this is going to be the easy part ... after enough tutorial snippets are written. If it is web-based, the whole machinery pretty much already exists. One way might be to embed keywords, including "difficulty ranking", inside tutorials and use a search engine to decide where to go next. Or, rather than using a search engine, a "mind map" type of visual index can be created, with some automatic updating whenever a new tutorial snippet is added, or a keyword is added to that tutorial. A variation on the them is that keywords inside a given tutorial could be given some relative weighting factor.
All of those methods could be used inside a particular lesson generator like Crunchy Frog. I was certainly thinking of embedding stuff in the html for Crunchy Frog. Having everything there is part of the elegant simplicity of generating data for Crunch Frog.
Regardless of the chosen method ... lots of tutorials will be needed. Until then, I think that trying to come up with the ideal method to link them is probably pointless; a case of premature optimization....
André
Certainly much of the elaboration of an engine is mostly useful after there are lots of lessons, and certainly the stuff about using learning histories to tweak the engine is WAY in the future. A major point I did not consider, that fits into your caution about premature optimization, is that Crunchy Frog is the only delivery mechanism at the moment, so all data comes through it, and we can concentrate on Crunchy Frog understanding data embedded in a Crunchy Frog Web page lesson. I see data embedded in meta data, your custom vlam attributes, and classes identifying types of content: The meta construction in the heading is a fine basic descriptive format for use by Crunchy Frog. It is important that the format is clear: agreeing on what name attributes are used and the meaning of the content attribute that goes with a name. We could make skills binary as in <META name="prereqs" content="ifElseRead, comparisonNumeric, assignment"> <META name="outcomes" content="ifElseUse"> or as I prefer, with a numeric rating, maybe with the number left out meaning 100 (mastery) and 0 meaning exposure. The following might be in a testing module on understanding the flow of control in an if-else construction, assuming an earlier expository introduction: <META name="prereqs" content="ifElseRead:0, comparisonNumeric, assignment"> <META name="outcomes" content="ifElseRead"> There is much meta data about a lesson that I think is useful, even when our total number of lessons is small. A lot of the data is most obviously considered while creating a lesson, when I find it easiest to add classifications, and to edit them from a copy of a similar template lesson. If we are piecing together snippets of tutorial, I think it is important to be conscious of what the prerequisites are and what is being taught. I would be happy to give a first pass on a consistent pattern for naming basic and composite skills for introductory programming in Python. I still like the idea of short names for composite skills, so a persistent structure is needed to store components of compound skills. One simple approach would be to use a text file with Python dictionary syntax and list value "loops":["forLoop", "whileLoop"] "booleanExpression":["booleanExpressionAtomic", "andOp", "orOp", "notOp"] Other conventions, use keywords, author, and version. For example: <META name="keywords" content="drill, javaAnalogy"> <META name="author" content="Andrew Harrington"> <META name="version" content="0.3"> I need more research on what is relevant and practical, but I imagine various measures of the speed and creative ability needed of the learner, maybe difficulty (pretty general) or more specifically speed, repetitiveness, number of new ideas together, number of solution steps the learner must put together independently, .... Even if names are agreed upon here, the initial measures are subjective, and probably only make sense being added when comparing a number of lessons. This is an area where I look to have an eventual system make tweaks dynamically based on statistics from learner histories. I imagine one lesson having multiple screens, and maybe multiple paths if help is given for wrong answers. I treat the final page of a lesson covering a defined topic as being different from the others. I imagine a "Next page" or other buttons in intermediate pages, as I mentioned in my recent Crunchy Frog wish list, and a "Next lesson" button at the end. Data associated with the Next Lesson button might include several lessons of the authors that could logically follow independently. Maybe the first one would be chosen if there is no further basis for choosing added. I would like to get to a point where the objectives of the learner are part of the state, and that affects the choice of the next lesson. I have looked through many narrative tutorial introductions, and I still like the idea of being able to extract a reference on what has been introduced so far. I like the idea of marking new syntax and summaries in the expository text, maybe with a <div class="syntax">, and <div class="summary">, making them easy to extract with Elementtree, and consistent in their display. It would be nice for these summaries to pop up in a separate window or tab if requested. I do not know if that fits in with the Python localhost interface. If there had been any of these elements in lessons so far, I would put Syntax and Summary buttons somewhere, at the bottom of the lesson page or on a separate reference web page, or in a separate frame. There is an embedded style in Crunchy from pages. Styles for syntax and summary could be added. Again, some agreement on a starting scheme is useful. Other people's suggestions/agreements much appreciated. -- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin@luc.edu Chicago, Illinois 60611