Index: openacs-4/packages/dotlrndoc/WHAT_THE_HECK_IS_THIS.txt =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/WHAT_THE_HECK_IS_THIS.txt,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/WHAT_THE_HECK_IS_THIS.txt 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,5 @@ + +This is the site for documenting dotLRN stuff. Set up by Ben (ben@openforce.net). +Started on 09/04/2001. + + Index: openacs-4/packages/dotlrndoc/tcl/dotlrn.tcl =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/tcl/dotlrn.tcl,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/tcl/dotlrn.tcl 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,14 @@ + +proc dotlrn_header {title} { + return "$title + + +" +} + +proc dotlrn_footer {} { + return "

+


+
dotlrn@openforce.net
+" +} Index: openacs-4/packages/dotlrndoc/www/index.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/index.adp,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/index.adp 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,10 @@ +<%= [dotlrn_header "dotLRN"] %> + +

dotLRN

+

+ +

+ +<%= [dotlrn_footer] %> Index: openacs-4/packages/dotlrndoc/www/style.css =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/style.css,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/style.css 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,42 @@ + + p { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt; } + body { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt; } + h1 { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 20pt; } + h2 { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 18pt; } + h3 { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 14pt; } + h4 { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12pt; } + a { color: #CC6600; text-decoration: none; } + a:visited { color: #CC6600; } + a:active { color: #CC6600; } + a:hover { color: #CC6600; text-decoration: underline; } + a.link { color: #CC6600; } + + a.navigation { color: #000000; text-decoration: none; font-weight: bold; } + a:hover.navigation { color: #000000; text-decoration: none; font-weight: bold; background: #CC6600; } + a:visited.navigation { color: #000000; text-decoration: none; font-weight: bold; } + a:active.navigation { color: #000000; text-decoration: none; font-weight: bold; } + + a.navigationnow { color: #FFFFFF; text-decoration: none; font-weight: bold; background: #CC6600; } + a:visited.navigationnow { color: #FFFFFF; text-decoration: none; font-weight: bold; background: #CC6600; } + a:active.navigationnow { color: #FFFFFF; text-decoration: none; font-weight: bold; background: #CC6600; } + a.readmore { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 8pt; } + + select { width: 100pt; background-color: #EFEFEF; border-style: 1px; font-size: 8pt; } + option { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 8pt; } + .search { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 8pt; color: #CC6600; background-color: #EFEFEF;} + .burst { background: #CC6600 no-repeat center; text-align: center; } + td { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt; } + + div { font-family: Verdana, Arial, Helvetica, sans-serif; } + div.title { font-weight: bold; font-size: 12pt; } + div.heading { font-weight: normal; font-size: 11pt; } + div.body { font-size: 10pt; margin-left: 1em; } + div.navigation { font-size: 10pt; } + div.shortcuts { font-weight: bold; font-size: 8pt; } + div.news { font-style: normal; font-size: 8pt; margin-left: 1em; } + div.highlight { font-size: 8pt; font-weight: bold; color: #FFFFFF; } + div.footer { font-size: 10pt; } + li { list-style-image: url(/images/bullet.gif); } + li.menu { list-style-image: url(/images/bullet.gif); } + ul.menu { margin-left: 1em; } + Index: openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/doc/architecture-overview.adp 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,177 @@ +<%= [dotlrn_header "dotLRN Architecture"] %> +

dotLRN Architecture

+by Ben Adida and Arjun Sanyal, part of dotLRN Documentation. +

+ + +dotLRN is built on OpenACS 4.x, a modular architecture for +community-oriented web applications. dotLRN is also +modular in that new course management functionality +can be added as desired. Since dotLRN modules must function within the +dotLRN architecture, dotLRN modularity must be built on top of OpenACS +modularity. + +

+ +The dotLRN architecture attempts to define a framework within which +learning communities develop. A learning community may take many +different forms, but remains the crux of the architecture. + + +

Learning Community

+ +A Learning Community is architected as a series of +OpenACS components, with a heavy use of the subsite +concept. One community is represented by: + + + +

Class Instances & Clubs

+ +There are two different types of learning communities in the basic +dotLRN release: class instances and +communities (clubs). Both have the same functional +capabilities but have different attributes and roles for their +respective members. + +

Class Instances

+Class Instances are related to a particular class, and must specify: + + +The fist three parameters may be stored as separate items, all in one, +or combined in some way. The current architectural direction is to +separate Year and to group Term and Section, but this may change. In +terms of the global architecture, this isn't very critical. + +

+ +Since all class instances have a common basic set of parameters, the +class instance groups should all be a single core group type, called +Class. The Class group type defines the +attributes above (year, term, section). + +

+ +In addition, in order to group class instances by the class they refer +to, the Class group type is subtyped into further group +types, where one class is itself a group type. For example, +6.001 is a group type, whose parent group type is +Class. Then, 6.001 is the group type that all +instances of 6.001 belong to. 6.001 - Spring 2002, Section B +is a group of group type 6.001. This architecture allows for: + +

+ +

Communities (Clubs)

+ +Clubs are fairly generic Learning Communities, with no specific +attributes. Clubs are timeless, in that they don't start and end on +certain dates. Membership lists evolve, but the clubs remain unique, +without instances. + +

+ +Thus, unlike class instances, the group type structure for clubs can +be much simplified. A root group type, called Club can +encompass all club groups without any additional level of group typing. + + +

dotLRN Packages

+ +Learning communities have various packages of functionality. These +packages are much like existing OpenACS 4 packages, but with added +specifications, special callback interfaces, and predictable APIs that +not every OpenACS 4 package will have. + +

+ +Thus, a dotLRN Package is composed of two OpenACS 4 +packages: + +

+ +

+ +The specifics of creating a dotLRN package are described in the dotLRN Package Creation Guide. + +

The Portal Interface

+ +dotLRN will present most of its interface in portal form. Each dotLRN +package will present its information inside a portlet within +the appropriate portal page. + +

+ +The current Portals package is inappropriate for this effort, given +that there is no clean API for creating portal pages, setting up +portal pages configuration, and rendering portal pages +programmatically. Instead, dotLRN will need a much more programmatic +portal mechanism. + +

A Portal Page

+ +The New Portals Package (NPP) will feature the +ability to programmatically create and edit single Portal +Pages. A single Portal Page will be defined by: + + +

+ +The dotLRN application will then create, configure, and associate +individual portal pages with specific users' sections of the +site. This will allow portal functionality to exist within the dotLRN +application without handing over all control to the portals package. + +

Portlets

+ +The NPP will require portlet packages much like the old portals +package. Each portlet package is responsible for: + + +

The Per-User Interface

+ +Each user will have a single NPP interface which groups information +from all dotLRN classes in one page. Given the subsited architecture +of each class, the per-user interface must be subsite aware, and must +be able to query information across subsites. + +

+ +<%= [dotlrn_footer] %> Index: openacs-4/packages/dotlrndoc/www/doc/detailed-todo.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/detailed-todo.adp,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/doc/detailed-todo.adp 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,62 @@ +<%= [dotlrn_header "dotLRN Documentation: Detailed ToDo"] %> +

dotLRN Detailed Todo

+part of dotLRN Documentation +

+ +This document details the precise steps in moving forward with dotLRN development. + +

+ +

Portals Enhancements

+ + +

dotLRN Course Administration

+ + + +

dotLRN Permissioning

+ + + + +

Calendar

+ +

File Storage

+ +

Surveys

+ +<%= [dotlrn_footer] %> Index: openacs-4/packages/dotlrndoc/www/doc/index.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/index.adp,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/doc/index.adp 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,16 @@ +<%= [dotlrn_header "dotLRN Documentation"] %> +

dotLRN Documentation

+part of dotLRN +

+ +

+ + +<%= [dotlrn_footer] %> Index: openacs-4/packages/dotlrndoc/www/doc/nomenclature.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/nomenclature.adp,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/doc/nomenclature.adp 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,59 @@ +<%= [dotlrn_header "dotLRN Nomenclature"] %> +

dotLRN Nomenclature

+by Ben Adida, part of dotLRN Documentation. +

+ +dotLRN is a Course Management System which means it +helps manage courses, but does not perform the actual instruction of +the courses. This document defines the nomenclature +in the dotLRN project, because the components of a Course +Management System are named very differently by various teaching +institutions. In particular, since dotLRN is being developed for MIT +Sloan, an attempt is made to cleanly work within existing MIT +terminology while being generic enough to use by all. + +

+ +

Class

+ +A class is a topic being offered by the +institution. An example is "Introduction to Micro-Economics". Some +institutions use the term "course", but this conflicts with MIT's +reference to entire departments (Course 15). A class is thus a single +topic that spans across years and does not specify a single offering +of that topic. + +

Class Instance

+ +A class instance is a particular offering of a +class. An example is "Introduction to Micro-Economics - Spring 2002, +Section A". A class instance thus has a very well-defined student +list, professor, and TAs. It has specific material relevant to that +offering of the class, a schedule, news events, etc... + +

Student

+ +A student is an individual who is registered for a particular class +instance. + + +

Instructor

+ +An instructor is one who teaches a particular class instance. An +instructor could be a professor in title or not. The term instructor +allows the system to be more flexible to different teaching +environments. + +

TA

+ +A TA (Teaching Assistant) is one who assists the instructor in the +teaching of the class instance. + +

Administrator

+ +An administrator is one who assist in managing issues surrounding a +class instance, but doesn't play a role in the teaching process. + +

+ +<%= [dotlrn_footer] %> Index: openacs-4/packages/dotlrndoc/www/doc/permission-overview.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/permission-overview.adp,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/doc/permission-overview.adp 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,235 @@ +<%= [dotlrn_header "dotLRN Roles, Sections, and Permissions"] %> +

dotLRN Roles, Sections, and Permissions

+by Ben Adida, part of dotLRN Documentation. +

+ +dotLRN includes significant components of functionality and an +architecture for integrating these components. Around these +components, there must be a coherent and consistent model for roles +and permissions throughout the system. This document defines the +necessary roles, application sections, and rules for access in the +dotLRN application. + +

Roles

+ +Roles in the dotLRN system are considered from a logical +standpoint. It is perfectly conceivable that an actual user take on +more than one role. It is also conceivable that a logical role is +represented by multiple physical underlying roles and permissions. +

+ +

Unregistered Visitor

+An unregistered visitor is simply a user who browses the dotLRN +application without login information. + +

Registered Visitor

+A registered visitor is one who has entered first name, last name, +email address and password information, and how has logged in using +those credentials. + +

Registered Student of an Instance of a Class

+A registered student of a class is one who has requested association +with a particular instance of a class (e.g. Micro-Economics, Spring +2002 Section A), and who has been approved (usually by a professor, a +TA, or an administrator). + +

TA of a Class Instance

+A TA of an instance of a class is a registered user who serves as a +Teaching Assistant for the class, having some administrative +responsibilities. TAs are usually designated by professors or +administrators of a class's instance. + +

Administrator of a Class Instance

+An administrator of an instance of a class is a registered user who +serves to perform organizational/administrative duties for the class, +including registration, schedule and venue arrangements, etc... + +

Instructor of a Class Instance

+An instructor of an instance of a class is a registered user who +teaches the actual class instance in question. Instructors are often +professors, but may not be (thus the use of the more functional term +"Instructor" rather than the status term "Professor"). + +

Member of a Graduating Year

+A member of a graduating year is a registered user who is a student of +a particular graduating year. This grouping may be needed for mass +mailings, alumni clubs, etc... + +

Member of a Community

+A member of a community is a registered user who has signed up (and +been approved) to be part of one of the dotLRN communities. A +community functions much like a class instance, but without the +association to the teaching of a particular subject. + +

Administrator of a Community

+An administrator of a community is a registered user assigned to +coordinate a particular community. + + +

Sections of the Application

+ +The dotLRN Application is composed of a number of sections which +serve various roles. These sections can be described with a varying +level of granularity. The following description matches the necessary +level of granularity for matching permissions and roles. + +

Main Public Site

+ +Every dotLRN site will have a completely public section that describes +the general purpose of the application. This will be mostly +information material, with very little interactivity of any kind. +

+

Permissions

+ + + +

Per-Class Main Page

+ +Each class (e.g. Micro-Economics) will have a section in the dotLRN +application. This section will describe the goals of the class, +general information about it, and will remain unrelated to any +specific instance of the class. +

+A registered student of an instance of that class will be presented +with links to the proper instance-specific sections. + +

+

Permissions

+ + + +

Per-Class Admin Page

+ +Each class will have an administrative section in the dotLRN +application which will enable users to: + + +

+

Permissions

+ + +

Per-Class-Instance Main Page

+ +Each class instance (e.g. Micro-Economics, Spring 2002 Section A) will +have a section in the dotLRN application. This section will look very +different depending on the state of the visitor. +

+For a registered student, TA, or Instructor of the +class instance, the section will present all available options for the +particular instance, including discussion forums, file storage, FAQ, +surveys,etc... +

+For a user not registered with this class instance, +the section will present general information about the class instance, +possibly some public files (like a syllabus), and the ability to +request registration for the class. + +

+

Permissions

+ + +

Per-Class-Instance Admin Page

+ +Each class instance will have an administrative section which will +allow for: + + +

+

Permissions

+ + +

Per-Class-Instance-Package Main Page

+ +Each package within a class instance defines a section of the dotLRN +application (e.g. bboards for Micro-Economics, Spring 2002 Section +A). The functionality for these sections will be specific to the +subpackages involved. + +

+

Permissions

+ + +

Per-Class-Instance-Package Admin Page

+ +By the same token, each package within a class instance defines a +section of the dotLRN application for administration. The +functionality is subpackage-specific. + +

+

Permissions

+ + + +

Per-Community Main Page

+ +dotLRN will also support communities, each of which will have its own +section, much like a class instance. This section will lead to all +subpackages supported by this community. Users who are members of the +community will access all functionality, while other users will only +see basic community information. + +

+

Permissions

+ + + +

Per-Community Admin Page

+ +By the same token, each community will have an admin section that +allows community administrators to manage community membership, +general information and subpackages. + +

+

Permissions

+ + + +

Per-User Main Page

+ +Each user will have a main page that centralizes access to all of that +user's class instances, communities, and all the data within these +sections. This is a personal view on every piece of user-relevant data. + +

+

Permissions

+ + +<%= [dotlrn_footer] %> Index: openacs-4/packages/dotlrndoc/www/doc/permission-overview.txt =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/permission-overview.txt,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/doc/permission-overview.txt 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,81 @@ + +dotLRN Permissioning +==================== + +This document describes the issues surrounding general permissioning +in dotLRN. It defines the roles and access rules for the entire +system. + +Roles +----- + +- Unregistered Visitor +- Registered Visitor +- Registered Student of a Class +- TA of a class +- Administrator of a class +- Instructor of a class +- Member of a graduating year + +- Member of a community +- Administrator of a community + + +Sections of the Site +-------------------- + +- Main Site + +All users can view the page + +- Per-Class Main Page + +All users can see the description of the class in general. Users who +are registered for a particular instance of that class see links to +those term offerings. + +- Per-Class Admin Page + +The sitewide admins can access this section which allows: + - creation of new instances of this class + - assignment of profs and tas to each instance of a class + - editing the main blurb about each class + +- Per-Class-Instance Main Page + +Users not registered for this instance of this class see only an +informational page about the class, including the public files like +the syllabus. + +Users registered for this instance of this class see their full portal data. + +- Per-Class-Instance Admin Page + +Profs, TAs, and admins for this class instance can see the admin section +for a class. This admin section allows management of class membership. + +- Per-Class-Instance-Package Main Page + +Users registered for this instance of this class can see this page, +and that's it. No one else can access this. + +- Per-Class-Instance-Package Admin Page + +Class-Instance TAs and profs can access this. + +- Per-Community Main Page + +Community Members will see the full membership page, much like a class +page. Non community members will just see a general community +description page. + +- Per-Community Admin Page + +Community Admins will be able to determine community membership. + +- Per-User Main Page + +Each user will have access to her main page, which will link all basic +packages. + + Index: openacs-4/packages/dotlrndoc/www/doc/schedule.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/schedule.adp,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/doc/schedule.adp 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,90 @@ +<%= [dotlrn_header "dotLRN Schedule"] %> +

dotLRN Schedule

+by Ben Adida, part of dotLRN Documentation. +

+ +

September 7th, 2001

+ + +

September 14th, 2001

+ + +

September 21st, 2001

+ + +

September 28th, 2001

+ + +

October 5th, 2001

+ + + +

October 12th, 2001

+ + +

October 19th, 2001

+ + +

October 26th, 2001

+ +

November 2nd, 2001

+ +

November 9th, 2001

+ +

November 16th, 2001

+ + +

+ +<%= [dotlrn_footer] %> Index: openacs-4/packages/dotlrndoc/www/doc/subsite-use.txt =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/dotlrndoc/www/doc/Attic/subsite-use.txt,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/dotlrndoc/www/doc/subsite-use.txt 14 Oct 2001 21:42:58 -0000 1.1 @@ -0,0 +1,117 @@ + +Subsite Quicky +============== + +- Group Type: Company +- Group: OpenForce +- Relationship Type: Employment +- Member: Ben Adida +- Relationship: Ben Adida is employed by OpenForce +- Relationship Segment: Employees of OpenForce (cross of one Group and one relationship). +- Site Node: /6.001/bboard is a node of the site + + + +Ideas for Using Subsite for dotLRN classes +========================================== + +- Group Type: class +- Group Type: c6001, parent type class. +- Group Type Arguments for class: Year, enumeration; Semester, enumeration. +- Group: 6.001 Fall 2002 +- Various packages: + /dotlrn/6.001/fall-2002/bboard + /dotlrn/6.001/fall-2001/file-storage +- Relationship Types: Student, TA, Professor (possibly others) +- are relationship types configurable at web level? good question... +- Relationship Segments: students of a class. TAs of a class. Profs of a class. + +- each class has a node, and the packages associated with it are subnodes within it + +- the question is permissions: do we permission /6.001/bboard to those + who are part of 6.001, or do we permission specific bboards? There + are two issues here: + 1. when going to /6.001/bboard, we want only the 6.001 bboards to be + displayed. How we scope this is not yet clear. OKAY! Now it is. If + you say "new application" then it effectively creates a new + scope. So there is an easy way to scope this! Excellent baby. Very + very good. + 2. when going to /6.001/bboard, we want permissions to be applied + correctly with respect to those bboards. That means permissions + should be SCOPED to the specific bboards, but the bboard package + must be scope-aware to only display the appropriate data. + + 3. NEW DATA: Okay, permissions map to each instance of a package. So + we can actually set permissions on the instance of the package, + and then we're all set. This is very good. + +- the issue is how to put together a homepage that encompasses the + various data from all classes for a particular student. We might + have to write some serious custom code there. + +- calendaring information, specifically, where we want to mix in one + view all the events for one student. + +- when creating a class, we'll create a group, we'll mount the right + packages. We'll have to figure out how to create hooks so that + creating a bboard in /6.001/bboard will automatically scope and + permission things correctly + +- we'll create a class manager package that is the basic application + that is mounted at /6.001/. This will have to be scope-aware, to + display the right name and such. This will allow unsubscribed + students to sign up, and subscribed students to immediately see the + right info. This package may simply be an extension of the portals + package. A modified portals package, or a package that relies on + portals. + + +WHAT HAPPENS BEFORE ANY CLASS IS ADDED +====================================== + +- All packages that will be needed must be loaded and installed +- All data model and Tcl files initialized correctly +- We don't ever want to restart the server afterwards!! + +- Group Type "Class" is created with appropriate attributes + - Semester + - Year + + + +WHAT HAPPENS WHEN A NEW CLASS IS CREATED +======================================== + +- A group of the proper type is created for the class +- Admins for this class are created +- A node is created at / +- The Class Manager application is mounted at / +- All chosen packages are mounted at // + + +WHAT HAPPENS WHEN A USER JOINS A CLASS +====================================== + +- user is added to that group + + +SOFTWARE STRUCTURE +================== + +- each package for DOTLRN will be a small package that depends on: + - the main package like bboard + - the portlet package like bboard-portlet + +- so a package will be like dotlrn-bboard + + + +IMPORTANT POINTS TO CONSIDER +============================ + +- WOW: we might want to have a class like 6.001 be a group TYPE, with + each semester being a specific group of that group type. Let's + investigate this some more!! + +==> YES we will do this. +