Curriculum System

part of the ArsDigita Community System by Philip Greenspun

The Big Picture

Surfing the Web can seem like an aimless unproductive activity. This system enables a publisher to establish a curriculum at their site, identifying up to a dozen or so important areas of content that they'd like a user to visit eventually.

Suppose that Joe User comes to www.edf.org hoping to learn something about being an environmentalist. He reads an article or two before becoming distracted by another task. Three months later, Joe User returns to www.edf.org to continue his environmentalism education. He can't remember which articles he has read. The home page has been freshened with news so that the links aren't in familiar places. Joe doesn't know what he should read next and, worse, doesn't feel that he is progressing toward any goal.

With this system, Joe can refer to a curriculum bar that is displayed on every page grabbed from www.edf.org. The bar shows a condensed description of the articles that Environmental Defense Fund wants everyone to read, with little checkboxes by the ones that he has read already. As Joe finishes a section, it is clear from referring to the curriculum bar which section to read next.

Configuration


[ns/server/yourserver/acs/curriculum]
EnabledP=1
; does ad_footer put this in every dynamic page?
StickInFooterP=1
; does ad_serve_html_page put this on every static page?
StickInStaticPagesP=1

What we need to represent

We need to store The overall objective is kept in an optional /curriculum/objective.txt file. This contains an HTML fragment that the publisher wants the user to see.

Everything else is in the following table 


create table curriculum (
	curriculum_element_id	integer primary key,
	-- 0 is the first element of the course, 8 would be the 9th
	element_index		integer,
	url			varchar(200) not null,
	very_very_short_name	varchar(30) not null,
	one_line_description	varchar(200) not null,
	full_description	varchar(4000)
);
We record individual user experiences in 

create table user_curriculum_map (
	user_id			not null references users,
	curriculum_element_id	not null references curriculum,
	completion_date		date default sysdate not null,
	primary key (user_id, curriculum_element_id)
);
You might wonder why we don't use the user_content_map table. We have some good reasons: (a) the table only records static .html page loads, (b) the table is only properly used to record content viewed on our server whereas a curriculum may include content from foreign sites.

Registered vs. Non-registered Learners

The system needs to work for non-registered learners via browser cookies. At the same time, someone who does register ought to be able to claim their curriculum progress when logging in from another browser.

Where displayed

Our canonical location for the curriculum bar is at the bottom of the page, just above the HR tag the precedes the signature. We can get this into most .tcl pages by making ad_footer check for the publisher's curriculum system settings. A modification to ad_serve_html_page in /tcl/ad-html.tcl suffices to make the bar visible on static pages.

When displayed

Once a user has completed the curriculum the bar is no longer displayed unless the user explicitly clears the curriculum history from the /curriculum/ pages.

Performance

Anything that can be memoized is, e.g., the elements of the curriculum at a site. Anything that can be pushed into a browser cookie is. We don't want to hit Oracle one extra time for every page load.

Cookies Employed

For both registered and non-registered users, we keep a browser cookie CurriculumProgress.

This is either a space-separated list of integers (curriculum element IDs) or the token "finished".

Filters

We want to make sure that curriculum progress is recorded even if a user does not navigate to sections via the curriculum bar. So we'll need a filter that checks the URL against the curriculum elements and that checks the user's CurriculumProgress cookie. For the curriculum bar to be up to date, the filter will have to run before the page is served and destructively modify the input header ns_set to make CurriculumProgress reflect the current page.

By default, the filter ought to be run before every .html, .tcl, or .adp page served, if the curriculum system is enabled.

philg@mit.edu