Instance Configuration

[mlitzkow]

I would like to use BLTI to connect up my school's Moodle instances
with Apple's iTunesU. This would allow students in Moodle courses to
download or subscribe to their podcasts based on their Moodle
authentication without providing additional credentials to iTunesU
(single sign-on). It would also allow instructors of Moodle courses
to manage content in their iTunesU courses based on their "teacher"
role in their Moodle courses.

I implemented this a year or so back with a custom block for Moodle
1.9. Access to the iTunesU resources is provided through a "delegated
trust" model between the administrator of the iTunesU instance and the
administrator of various Moodle instances on our campus. The block
implements the shared trust relationship by passing a cryptographic
secret from the Moodle site to an authentication server associated
with the iTunesU site. Now I would like to extend this for Moodle 2.0
and think that using BLTI would be better than maintaining my own
custom block for this job. As you can imagine, much of the code in
the custom block is concerned with the cryptography needed to protect
access and that's already managed by BLTI and most likely in a more
secure way than I did it anyway.

So my problem is this. I need each instance of the BLTI resource or
activity to contain information about which iTunesU course should be
access by the instructor or student of the Moodle course where that
resource or activity is located. I think the LTI terminology is that
I need to pass the TP a custom parameter. If I understand correctly,
BLTI allows me to pass a custom parameter, but it needs to be
configured at the site level. I need to pass a custom parameter that
is configured at the instance level.

I am new to BLTI and LTI in general. Does this make sense? Is there
a reason not to implement instance configuration for BLTI resources
and activities? I would be willing to work on this, if it seems in
line with the intended model for BLTI and LTI.

regards,
-- mike

[csev]

Mike,

Thanks for the note.

The notion of instance configuration is one that comes up a lot. We have avoided this because it is something that many LMS's don't want to expose to the instructor in the UI - so in Desire2Learn and Blackboard they want the Instructor configuration dialog boxes as simple as possible leaving most configuration to the administrator who can hopefully cope with the greater UI complexity.

Sakai actually gives the instructor more flexibility than Moodle - but that is the exception in UI design. But is a bit clunky in Sakai as a result.

I have been talking with folks about the notion of adding a per-tool-instance storage (say 8K in a VARCHAR) and allowing the tool to make a callback to allow the tool store this information in the LMS.

The scenario works like this:

a) Admin places tool with key and secret
b) Instructor places tool with very little config
c) Instructor launches tool
d) Tool pops up some instance configuration bit
e) Tool stored instance data in LMS
f) LMS launches the tool for student or instructor and includes the instance configuration bit with each launch.

A key to this approach is that the user might see the per-instance config bits fly by during the form post. But you could encrypt it if you wanted to hide it from prying eyes.

Does this sound at all interesting? It allows far more flexibility and works without adding a bunch of UI flexibility.

Technically, we add one VARCHAR column to the BLTI table and use the same pattern as outcomes to secure a REST-style data transfer. We would make it so the too could write, read, or delete they config.

A key thing is that we only get one of these per instance (i.e. there is no per-student-per-instance data).

I still am not quite clear as to how you plan to use BLTI to make the iTunes Integration easier - you still need some glue code to go between BLTI and iTunes - I don't know where that might run and if it needs any storage.

/Chuck

[mlitzkow]

Dr Chuck,

Thanks for the reply. I think what you are suggesting has a lot of
value, but doesn't solve my immediate problem nor a class of similar
problems where the instructor needs to supply "context" information to
the learning tool. Looking specifically at my situation with
podcasting, it's important to understand that different groups of
folks administer the iTunesU site and various Moodle instances on my
campus. While this arrangement may be specific to my campus, I don't
think it's unusual. An instructor wanting to use podcasting in their
Moodle course needs to first request a space for their podcasts from
the iTunesU team (an iTunesU course), then make those podcasts
available to students in their Moodle course. Somebody has to
associate the correct iTunesU course with the proper Moodle course,
and it needs to be done on an instance by instance basis. It's not
reasonable to expect iTunesU to set up this instance configuration
since Apple did not build in that functionality and we have no access
to do it ourselves. This information needs to be supplied at the
Moodle end. Furthermore, it's the instructor, not the site
administrator who has the information. It would make sense that the
instructor supply the name of the iTunesU course when adding the
iTunesU (BLTI) activity to their course as part of the configuration
of that BLTI instance.

Your question about the "glue" code between Moodle (or BLTI) and
iTunesU is apt. We do indeed run a web service (the Auth Server)
which has that function. Currently we have a locally written Moodle
block which talks to the Auth Server, and the Auth Server has all the
credentials needed to make requests of iTunesU. So, iTunesU trusts the
Auth Server, and the Auth Server trusts certain Moodle instances which
it knows through a configuration file. In turn, those Moodle
instances trust persons with the Instructor Role to configure a Moodle
block with Instructor and Student level access to iTunesU courses.
Once an iTunesU block is added to a Moodle course and configured,
Instructors can manage content on their iTunesU courses from Moodle,
and Students can download podcasts or subscribe to the RSS feed. There
is a home-grown secure protocol between the Auth Server and the Moodle
block. My proposal would not eliminate the Auth Server, but it would
eliminate the locally written Moodle block and replace it with the
more general and powerful BLTI module. This would eliminate my need
to port my block to Moodle 2.0 and also get me out of the business of
implementing a secure protocol between the block and the Auth Server.
Instead I would upgrade the Auth Server to work with OAuth and BLTI.
In the process, BLTI would become available for connecting Moodle to
other learning tools on our campus.

Lest you think that my particular situation with iTunesU is too
specific to influence the design of the BLTI user interface, I want to
describe another project I'm working on where BLTI could also play a
key role. http://engage.wisc.edu/sims_games/index.html describes a
project which has developed a series of educational games that teach
content in a wide variety of disciplines. In one of the games,
students role-play cryogenic engineers who are assigned to work on a
variety of design problems ranging from MRIs and Mine Detectors to
Space Cryogen Depots. The instructor would like to assign several
instances of game play, one for each of the scenarios, at the
appropriate week or topic in their Moodle course. BLTI would be the
perfect way to make the connection between Moodle and the game, but
again, the instructor needs to supply "context" information specific
to each game scenario the students should play. I also happen to be
working on a game simulating use of the commodities futures market as
a mechanism for risk management for farmers, ranchers, and agri-
businesses. The instructor wants students to take on the roles of
"small grain farmer", "feedlot manager", "ethanol plant", etc. on a
weekly basis throughout the associated course. Again, BLTI seems like
the perfect connection point between Moodle and the game, but the
instructor needs to supply the context information of which scenario
the students should play each week. I'm sure if you think about it,
you will be able to imagine many other similar scenarios where a small
bit of instance configuration needs to be supplied by the instructor.

Now we come to the question of how should the BLTI user interface
accommodate these scenarios and how to make sure the interface is not
overwhelming to the instructor. My suggestion is that on the site-
wide BLTI administration page for a particular activity type, e.g.
iTunesU or CryoGame, the site administrator should enter a list of
context variables to be subsequently filled out by the instructor.
This could look similar to the "Custom parameters" box that's part of
that interface now, but instead of specifying site-wide parameters it
would specify place holders for instance configuration. In the
iTunesU example, the only place holder specified would be "iTunesU
Course" and in the cryogenics game the only place holder would be
"Game Scenario". Then when the instructor adds an instance of an
iTunesU or CryoGame BLTI activity to their course, they would have a
blank on the form with an appropriate label so they should understand
what information needs to go there. If they have done their homework
and have already requested an iTunesU course or already familiar with
scenarios of the game they're assigning, they'll know how to fill in
that blank. It won't be overwhelming.

I have some experience with Moodle coding, and it is possible I could
help out with both upgrading BLTI to Moodle 2.0 and extending the user
interface to accommodate this kind of instance configuration. That
would, of course, depend on our agreement that what I'm suggesting
would likely be of value not only to me and instructors at my
university, but also to other BLTI users in the future. Please let me
know if what I'm suggesting makes sense to you, and if you would like
to try to find a way to work together toward this end.

best regards,
-- mike