[Edu-sig] An engine to navigate between lessons

[Andrew Harrington]

Andre Roberge wrote:
 > On 5/14/06, Andrew Harrington <aharrin at 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 at luc.edu
  Chicago, Illinois 60611