Phpgroupware based E-Learning applications Application: Grades Author: Alex Borges (Lex) alex at co.com.mx Design of the application: Edgar Luna (eald) eald at co.com.mx 1) Foreword We have been contracted to make a set of web based groupware applications oriented to the educational market. The organization that sponsors this is a pretty small (5000 students) and generic (has highschool, undergraduate, and masters programmes) private university in Mexico. Despite this localization, we wish to build this set of applications in the classic Free Software, Bazaar style method of software development. This means that, besides the requirements of the client, we have a set of needs that arise from the fact that this is a project that aims to be developed and further mantained by an international community of development. The first requirement of this later type that comes to mind is internationalization in every aspect. From one side, we will need to support as wide a human language set as possible, and from the other, the applications must be designed so that the educational models of different countries and cultures are easyly programmed, configured or otherwise inserted into the applications. This type of requirements is what compels us to use a good platform, with a healthy community from the start. Also, we have some expertiese in the use of a particular free software groupware development platform so that narrows our options to one: phpGroupWare. The other requirement is very simple and comes from my (LEX) very keen obsession to destroy blackboard. KILL KILL KILL Te BB! 2) Definition of the project Thease are the user roles who use this applications: a) Teachers b) Alumni c) System administrators Thease are the components that must be developed: a) Grades application - Kind of development: From scratch b) School schedule application - Kind of development: Import/Export and mangment module that controls pertinent calendar items. c) Executive Summary Page - Kind of development: Standard view protocol or api for an executive summary page for all applications in phpgroupware. Development may include modifications of said applications d) Integration to a simple content manager per course - Kind of development: Extra layer (wizard?) for the filemanager application so that teachers can easyly upload content to their home directories. This content will be wrapped in a simple cms so that all courses information share the same look. NOTE: THis is not a complete COURSEWARE application only a simple CMS for teachers where they can upload content per course. e) Bulk user creation, categorization and ACL setting for each of the roles and data items that are implied in the design: - Kind of development: Tough. From scratch making of CSV and xls parsers. A way to define and link fields in the incoming documents to data in the phgroupware infrastructure. For example, the document for users may be defined as the account data, the relevant contact data, the role (this are students) and the academic data (this student attends this courses). We will need a way to upload all that into a proposed access control model for phpgroupware. This implies the rewriting or modification of the category code in phpgroupware and a way to have categories that trascend applications... look into the design section for the solution to this problems. Thease are existing components of the platform that are to be used in the deployment: a) EMail Modifications: Perhaps ical detection and importing to the calendar b) Calendar Modifications: ACL improvements so that the administrator can set which user can invite which other user or group. Invitations are to be done exclusively through the contacts backend. This means we do not invite users exclusively contacts (which may be users in phpgw). c) Infolog Modifications: Fixing and collaborating with new mantainer d) Central Addressbook Modifications: Heh....we already did those 3) Requirements of each role per application Teachers: a) EMail Personal usage -Normal personal usage Group usage -Addressbook dependant b) Calendar Personal usage -Normal personal usage Group usage -Should be able to set appointments with the alumni of HER COURSES only c) Infolog Personal usage -Normal personal usage Group usage -Should be able to use it to attach generic information to calendar items and addressbook entries to which she has access to. d) Central Addressbook Personal usage -Normal personal usage Group usage -Should be able to see all the faculty, administration persons but only alumni that are in courses SHE TEACHES. e) Grades application Personal usage -Should be able to see all the grades that she reported (by definition, the grades of the alumni she teaches to) -A mechanism for reporting grades should be in place, preferably a format-predefined document such as an excel worksheet or a csv export of the same. This should, of course, include a page to actually upload the document, revise it, delete it or backtracking and changing grades. Group usage -Its a group application by definition. f) School Schedule Personal usage - Will automatically see her own course schedule (days and hours at which she is supposed to go teach). - Will automatically be given the posibility to invite to dates anyone in her courses but EXCLUSIVELY alumni in her courses. - Will be given the posibility to invite to dates all members of the faculty. g) Executive summary page Personal usage -Applications will show the most relevant data in a limited space so that the teacher can view the most relevant data in a single pageview. As far as weve planned, the teacher will see the 5 closest appointments for today, the five most recent unread emails, the five most recently uploaded grades...and well...whatever. Group usage -None h) Content manager per course Personal usage - The teacher will see links for each of the courses he/she teches and will be given an option to delete/add or edit the content - The content will consist of a set of freely categorized files with a title and a comment for them. - This simple content will be rendered according to a standard phpgw template defined by the school - The final content should be accessible by the students, or even be made publicly available. Alumni: a) EMail Personal usage -Normal personal usage Group usage -Addressbook dependant b) Calendar Personal usage -Normal personal usage Group usage -Should be able to set appointment with the alumni of all courses the user ATTENDS to c) Infolog Personal usage -Normal personal usage Group usage -Should be able to use it to attach generic information to calendar items and addressbook entries to which she has access to. d) Central Addressbook Personal usage -Normal personal usage Group usage -Should be able to see the alumni that attends to the same courses as her -Should be able to see the teachers that are related to her courses -Should be able to see all the administrative contacts for the school e) Grades application Personal usage -Will be a simple school card report telling the grades to date of the student -In the high school environment. Grades should be sent, only once, to a registered email address that is related to the student as an uneditable field. This is the email address of the father or the person responsible for paying the school bill. -When new grades have been reported or the grades have changed, the platform will generate an email message to the student. f) School Schedule Personal usage - Will automatically see her own course schedule (days and hours at which she is supposed to go attend to classes). - Will automatically be given the posibility to invite to dates anyone in her courses but EXCLUSIVELY alumni in her courses. - Will be given the posibility to invite to dates all members of the faculty. - Probably (and this applies to all roles), will see all dates that the school administration wants to put in there. g) Executive summary page Personal usage -Same as teacher Group usage -None h) Content manager per course Personal usage - The student will see links for each of the courses he/she attends to and, if one clicks on those, he will be able to see the generated content page for that particular course. Administrator: a) EMail Personal usage -Normal personal usage Group usage -Addressbook dependant b) Calendar Personal usage -Normal personal usage Group usage -Big Brother c) Infolog Personal usage -Normal personal usage Group usage -Big Brother d) Central Addressbook Personal usage -Normal personal usage Group usage - Big brother e) Grades application Personal usage -Big brother -Can handles all uploads of grades, roll them back, change them, directly edit them...etc. f) School Schedule Personal usage - None Group usage - Big Brother May bulk import, change, delete, add, modify and monitor. g) Executive summary page Personal usage -None h) Content manager per course Personal usage - Big Brother 4.- Design issues a) General Well, all those are the requirments, but the question is that phpgroupware, just as is, does not cover them all. For example, what is this thing we call courses? How can we limit access to them? How do we also categorize cross-application information based on courses (teacher should see only students that go to the classes he teaches, but also should be able to see the calendar entries that he set for her courses...etc.)? Okay, we think courses are phpgw categories, but access to be able to even see those categories should be limited by groups in a one to one relationship. For example, users members of the group CS-1 can access (see) the CS-1 category, throughout all applications. Upon importing courses (through an import/export mechanism based on files), what gets created are categories and user groups. Upon importing persons, their contact information is created, their account information is also created and, through a list of courses the contact attends or teaches, we relate them to their respective group. So, phpgroupware still wont cut it right? Because all global phpgw categories are shown for everybody. Well, thats why categories will need to be rewritten to support ACLs. Now, you might think this would too much verticalize phpgroupware for the educational market? Well, no, we dont want to do it THAT way, we think this same thing is usable for any other collaborative application that deals massivly with groups and big bulks of data. Take an example, a CRM app for a large telemarketing companies (let them all DIE anyhow), they need perhaps to group the telemarketeers (young lushious ladies/lads in bikinis on the other side of the line) in groups of pitches to be thrown (this guys will call to sell this pitch), so the sales pitches may be database entries that are categorized in groups of products, but a manager may need to find a particular telemarketeer extension also by product group. So the same category will apply to both the sales pitch app and the addressbook. Furthermore, a group manager may be able to see his telemarketeers or his product groups in the addressbook, but none other. So, what we want to leverage here is the posibility of applying categories mixed with acl, to actually have acl per data (if you have one category per database entry, you basically have an acl per row... slow, but cool, but not to be abused this way). Now, we already have a way to set a particular piece of data so that it belongs to many categories. We also have a (limited) way of making hierarchies of categories (thats what they are for too). This makes for a really powerfull way to group data because we can have all alumni addressbook data belonging to the alumni category, and to the courses categories that they belong to, and thats just cool. Because sometimes someone will want to search in all of the alumni's addressbook data that he/she has access to...so all he/she needs is to click on the category box and select the alumni category, then search with the search button. Okay...nough ranting. The grades app has to be ready to go for alpha tuesday next week (yeah, you read right). What follows is the begining of a large document that will state the particular designs of all the elearning apps we are building. b) The Grades Application So, we start this part by stating that global, interaplication categories (we call them, trascendental categories, in the style of zen master eald), already are available to us. That magically, the category class already knows which are to be shown to whom. b.1) Back End First, letsdo an exercise.... lets imagine we were developing this as a standard, relational database application. More or less ( we think ) youd come up with this sort of schema: Subject (catalog) v | Are about | - Courses >----attends to-----< Student v | | | Teaches Grade as an attribute of the student/course relationship, among | among other attributes such as 1st period.....etc. - Teacher Well.... many other (certaintly better) ways to model this exist for shure. But this is just to illustrate why didnt we think of any of them (ohm). FIrst of all, if courses are now categories, this all changes a bit doesnt it? Furthermore grades are much more complex than that, especially since we want international adoption. So, long story short....we think this is the way to do this: ------------------- ------------- |Grade | |item ------------------- ------------- |id | _-----|id |alumni_contact_id | - |descr |item_id |--- ------- ------- |scale_id |cat_id | |------/|------------ |value | | ------------------- | | | ---------------- | |scale | | ----------------| | |id |---------------------- |object_handler | |descr | |--------------- Let me show you the data dictionary for this: Grade: Description: Holds all the grades for all the alumni Attributes: -id STFW -alumni_contact_id Descr: id into the phpgw_contacts table Constraint: Should be a user-related record -item_id Descr: id into the item table. Items are weird animmals, will explain in the item table -cat_id Descr: category id, not a straight id of the database but your general CSV list of category ids -value Descr: The actual alphanumerical grade grade item: Description: Holds all items TO BE GRADED. Now, this is interesting its a catalog of the ways you grade something.... this is how eald envisoned it (skewed by how i understood it). Your general grade record would show like this: id descr scale_id transaction_id 1 Highschool WOrkshops 1 43243 2 Highschool Official CLasses 2 432432 3 Highschool Assistance Record 3 32432 Thus, an item is something that describes what we are grading. It is NOT the curse we are grading it is a general description of the WAY we grade a particular curse... It will all become clear when i explain the scale part. scale: Description: Holds the SCALES used to grade ITEMS (GASP!). Abstractly, the scales table knows of ways we treat a particular grade given a certain item. Down to the bowels of it all, this is the data dictionary: id object_handler 1 workshops_scale_MX 2 highschool_official_scale_MX 3 highschool_assistance_record_MX 4 highschool_official_scale_JP So what does this do!!!? Well this is the storage part.... on to the middle, business logic part, so that we can understand it: b.2) Business logic layer The requirements clearly define a view for the teacher (can see all the grades related to courses he teaches) one for the alumni (each can see their grades, and their grades only) and an interface for adding, editing, deleting grades to students as well as a bulk import export mechanism for the admin. UI Okay, the views are clearly ui classes (that was quick) UNfortunatly, we are dealing with universities, highschools, maybe primary schools and kindergardens. All of those potentaily in any country. So, you of course know that grades are given differently depending if you are in highschool versus if you are in college. Some colleges grade from 0-5, other colleges grade from 0-100 others from A-F and highschools and other levels have the same kind of ugly dispairings, even within the same country. Furthermore, there are schools that have trimestral periods, others are semestral, others (primaries) are sometimes yearly, and others (postgraduate) have no regular timeline. How do we code for all of those....well, a chunk of code for each of course. But we also need to keep code reuse to a maximum. So that noone has to mess with the actual grade ui class to add support to japaneese preschool systems (for example). So a plugin system is in order, we call those plugins scales and they are supposed to know basically this things: - How to display a given grade, even the context of the periods it may have - What else to do with a grade when it is inserted (send email to dad if its a failing grade) - What else to do with a grade when its deleted or edited (send email to dad and me if there was a mistake in a grade). So the pseudocode for rendering grades goes like this: grades_for <= get_persons_being_graded() grades_set <= get_grades_for(grades_for) for each in grades_set as value,element,scale_id scale_object= CreateOject(element->scale_id->object_handler) scale_object->display(value) end for each Thats it. We program that part (grades UI for reporting each grade) exactly that way. To report many grades its just a matter of putting that inside another loop. That means of course that we will have a corresponding class."object_handler_name".inc.php in our grades inc directory....with a bit more of coding we can have a modules subdirectory like sitemgr has. Well.... that settles it so far then, this is the directory structure: grades inc class.uigrades.inc.php class.bogrades.inc.php class.sogrades.inc.php class.uiimportgrades.inc.php class.boimportgrades.inc.php class.uiexportgrades.inc.php class.boexportgrades.inc.php class.uiitemcatalog.inc.php (for managing the item catalog) class.uiscalecatalog.inc.php (manages the scale catalog) class.highschool_typical_scale_ULA_MX.inc.php (ula is the school we are making it for) class.highschool_assistance_scale_ULA_MX.inc.php class.hichschool_homework_scale_ULA_MX.inc.php class.professional_typical_scale_ULA_MX.inc.php class.professional_workshop_scale_ULA_MX.inc.php The rest you know