Documentation
E-Learning |
Hey everyone--
I'm new to the eGroupWare team (though I've done some translating for a bit). For my Master's Thesis, I'm going to be writing some eGroupWare software focused upon education. After discussions with Reiner, we've decided to make this an official application.
Initially this application will focus upon keeping track of assignments, grades, etc, with a major extra feature (explained below). Eventually this will hopefully incorporate (maybe as a different application, maybe within this one) distance-learning abilities, allowing courses to be taught online through eGW. It's a lofty goal and I don't expect it to happen soon (especially because my primary focus at the moment will be what I need to get implemented to finish my thesis, since I need to graduate by May).
I'm posting this as a request for comments and also a slight introduction -- being new to programming with eGW, and having only a small amount of PHP and SQL experience, I will likely need bits of help here and there from some of the more experienced team members. Currently I'm reading all the developer documentation I can find, so hopefully I'll figure out most of it on my own.
I hope to have a basic application written by the mid January 2005, with a fairly full-featured one by mid March 2005.
Following are some features that I will definitely be incorporating into this application.
Please list any comments you may have.
Thanks,
Jeff
_________________________________________
Comments from dragob (30th November 2004)
Very nice to hear from this application. It is a complement of something we (actually Mitja) have been doing here in Slovenija: our app (Virtual university) has students, classes and subjects, but nothing about submission and grades: its purpose is that it allows the teacher and the students to exchange public files and news about their subjects (basically, allows the teachers to maintain their subject's web page). Virtual university works through the sitemgr for public access and as a standalone app within egw. Together with your application it would really be a very interesting tool.
Some comments on the above:
... Eventually this will hopefully incorporate (maybe as a different application, maybe within this one) distance-learning abilities, allowing courses to be taught online through eGW. ...
Here the part Mitja did fits in nicely. Fortunately they are complementary, thus you still have to do your thesis :)
... Teachers should be able to create classes. ... create assignments ... define Teaching Assistants for the class. ... control who has access to the script repository ... need to either be Admins, or they will have to be defined by Admins. If they are defined by Admins, it will have to be determined whether an Admin also defines which other users are in each class, or whether the Teacher is able to.
A real life experience from our project Virtual university (which Mitja ported to this eGW app): teachers will never do this administrative job on the net: they will have their assistants to do it, or some secretary. The teachers will at most review the submissions and put in the grades, but not do administrative work. Thus (in the view of your description of the teaching assistants), the default issue shall probably be that assistants can do everything for themselves and their teacher, however, if the teacher wants, he can limit their abilities.
...Each class should have a seperate set of students, teaching assistants, and assignments (and maybe separate script repositories). This way, a teacher using eGW teaching multiple classes can keep things organized...
Wrong. For the students and assistants point of view, this is very disorganized, as a single student and assistant must log in/out to several classes, for instance, when submitting different results. Will you give them separate usernames for each class? I would drop the assumption that the sets of students and teaching assistants are separate, and replace it by a many-to-many relationship. However, an assignment logically belongs to a single class.
...assignment should be a document (perhaps written using a KB-style WYSIWYG editor, eventually) that are required to be completed by a specified due date (perhaps with a start date as well) ("fixed assignemnts")...
A start date is useful. I hope you thought about submitting files as well.
...Answers will probably have to be submitted using the same system as the assignments are created (i.e. in a text box, possibly using the WYSIWYG system from the KB) because if they are stored as files Teaching Assistants may not be able to access them, or it will require a lot of group setup, which defeats the purpose of dynamic Teaching Assitant assignment on a per-class basis....
This I dont understand. Who has access to the submitted files is fully under your (programmers) control.
...There should be a seperate "class" of assignments that do not require submissions. These could be, for instance, quizzes and tests. This way a student can receive a grade for quizzes and tests completed in-class without needing to file a bogus submission...
Here I would propose an generalization of the polls application (with various types of questions and a possibility of several questions in a single poll=test); questions having predefined point values for various (choice) answers or for corredct replies (after being checked by a teacher/assistnat).
...Grades...
If it is appropriate for your application I would suggest that the students are represented by a student code, and then all information about grades is made publishable through sitemgr module in a sitemanager website (like it is now with the wiki module). This way you achieve that the students do not need to login to see their grades and can list grades on the subject's website. Of course when the students are logged in, they only see their own grades, and the teachers/assistants can see the grades together with names (when logged in).
...ScriptRepository?...
To me this sounds like parts of the current workflow application. There the data can be taken from anywhere and then undergo some process. Maybe take a look at it, if you have time, and then you could reuse or at least make it compatible.
In general I find your application very interesting and useful, and wish you much success with your thesis!
Drago
_________________________________________
Comments from jefferai (30th November 2004)
...It is a complement of something we (actually Mitja) have been doing here in Slovenija...together with your application it would really be a very interesting tool...
I will make sure this is acceptable to my advisor but if it is then that sounds fantastic. We will have to figure out a way we can all talk and sort this out, because I do need at least the functionality I outlined...so if we collaborate, we may need to, for instance, change the database tables, etc. This would also help me in other ways if I was collaborating with some people, because I'm honestly extremely confused by how to do a lot of things in eGroupWare and working with someone else would really help me get started. Be warned that until I get my bearings you'll be pestered with questions :-) Also keep in mind that the functionality I stated is what I need to do for my thesis, so I'd work first on getting those things to work, and then features could be added.
...the default issue shall probably be that assistants can do everything for themselves and their teacher, however, if the teacher wants, he can limit their abilities...
Probably a good point. I know that I myself do most of that stuff for my teacher :-)
...Wrong. For the students and assistants point of view, this is very disorganized, as a single student and assistant must log in/out to several classes, for instance, when submitting different results. Will you give them separate usernames for each class? I would drop the assumption that the sets of students and teaching assistants are separate, and replace it by a many-to-many relationship. However, an assignment logically belongs to a single class...
Sorry, I think you mistook me. I didn't mean that each eGW username (i.e. student) should only be allowed in one class. What I meant was that when a student opens the E-Learning application, they should see a view that shows them which classes they belong to. Upon clicking a class, they can see [their current assignments, peer evaluations they need to complete, etc]. What I meant by "separate set of students..." was that every person defined as a student should not automatically be a student in each class.
...A start date is useful. I hope you thought about submitting files as well...This I dont understand. Who has access to the submitted files is fully under your (programmers) control...
I thought about submitting files...but I wasn't sure how file access would be controlled. If the file is stored in the vfs and accessable through the file manager, you may have a random set of users that should be able to access it (a teacher, teaching assistants, and peer evaluators, for instance). Maybe if the file could be stored as a BLOB in the database...?
...Here I would propose an generalization of the polls application (with various types of questions and a possibility of several questions in a single poll=test); questions having predefined point values for various (choice) answers or for corredct replies (after being checked by a teacher/assistnat)...
That's certainly a possibility.
...If it is appropriate for your application I would suggest that the students are represented by a student code, and then all information about grades is made publishable through sitemgr module in a sitemanager website (like it is now with the wiki module). This way you achieve that the students do not need to login to see their grades and can list grades on the subject's website. Of course when the students are logged in, they only see their own grades, and the teachers/assistants can see the grades together with names (when logged in)...
This could work. When a student is associated for a class they could be given a student code for it (either a random one or one they pick, perhaps). A project for later at the moment.
...To me this sounds like parts of the current workflow application. There the data can be taken from anywhere and then undergo some process. Maybe take a look at it, if you have time, and then you could reuse or at least make it compatible...
Workflow application? Is that part of the HEAD cvs and not on the general release one yet? Or did I just miss it somehow? :-) Either way, that could maybe be done...but for the moment probably I'd keep it simple. The script repository, even if it sounds fancy, is pretty simple at its core. Probably whether I hook it in to workflow from the start would be a factor of time.
...In general I find your application very interesting and useful, and wish you much success with your thesis!...
Thanks!
_________________________________________
Comments from dragob (30th November 2004)
...I will make sure this is acceptable to my advisor but if it is then that sounds fantastic. ... we may need to, for instance, change the database tables, etc...
The way I thought it out is that we define a common database system and then develop the apps separately (discussing any possible changes in the DBs). This way we will be compatible and you will be able to say you did your thesis alone. Mitja is preparing some documentation and you'll have to do it for your thesis anyway.
... Be warned that until I get my bearings you'll be pestered with questions :-) Also keep in mind that the functionality I stated is what I need to do for my thesis, so I'd work first on getting those things to work, and then features could be added...
Within our time limits, I am sure we will answer your questions.
... What I meant was that when a student opens the E-Learning application, they should see a view that shows them which classes they belong to...
Great, this is exactly what Mitja did by now. His examples will surely help you.
... Maybe if the file could be stored as a BLOB in the database...
This is a good option. However: take a look at how the File Center by Frank Alcantara works (Reiner can help you get in touch with that).
...This could work. When a student is associated for a class they could be given a student code for it (either a random one or one they pick, perhaps). A project for later at the moment...
At our uni nad I would assume at most of the others the students have some sort of student ID. We use that code.
...Workflow application? Is that part of the HEAD cvs and not on the general release one yet? ...
Yes.
Another concept that may be useful: what I do to my students is that they must register in the eGW via the Registration application which is accessible as a module in the SiteMgr or as a link at the login form. After they all register, I assign them appropriate group and then they have access to the apps we use (FUDForum, Wiki, TTS, Email, Projects).
I'm new to the eGroupWare team (though I've done some translating for a bit). For my Master's Thesis, I'm going to be writing some eGroupWare software focused upon education. After discussions with Reiner, we've decided to make this an official application.
Initially this application will focus upon keeping track of assignments, grades, etc, with a major extra feature (explained below). Eventually this will hopefully incorporate (maybe as a different application, maybe within this one) distance-learning abilities, allowing courses to be taught online through eGW. It's a lofty goal and I don't expect it to happen soon (especially because my primary focus at the moment will be what I need to get implemented to finish my thesis, since I need to graduate by May).
I'm posting this as a request for comments and also a slight introduction -- being new to programming with eGW, and having only a small amount of PHP and SQL experience, I will likely need bits of help here and there from some of the more experienced team members. Currently I'm reading all the developer documentation I can find, so hopefully I'll figure out most of it on my own.
I hope to have a basic application written by the mid January 2005, with a fairly full-featured one by mid March 2005.
Following are some features that I will definitely be incorporating into this application.
- Roles
- Teachers, Teaching Assistants, and Students
- Teachers should be able to create classes. They should be able to create assignments (more on this later). They should be able to view all student submissions for an assignment. They should be able to assign a grade to each student or group for each assignment. They should be able to define Teaching Assistants for the class. They should be able to control who has access to the script repository (more on this later as well). Note that because of the nature of the access and control Teachers will need, they will likely need to either be Admins, or they will have to be defined by Admins. If they are defined by Admins, it will have to be determined whether an Admin also defines which other users are in each class, or whether the Teacher is able to.
- Teaching Assistants should be able to create assignments, read student submissions, assign grades, and control access as well, with the difference being that their ability to do these four things are controled by the Teachers. For instance, a Teacher may define Teaching Assistants for a class that can read student submissions for an assignment but not assign grades to students.
- Students will be able to complete assignments by submitting answers. They should also be able to run scripts in the script repository if given access.
- Teachers, Teaching Assistants, and Students
- Classes should be the highest-level "container" in the application. Each class should have a seperate set of students, teaching assistants, and assignments (and maybe separate script repositories). This way, a teacher using eGW teaching multiple classes can keep things organized.
- Assignments
- One type of assignment should be a document (perhaps written using a KB-style WYSIWYG editor, eventually) that are required to be completed by a specified due date (perhaps with a start date as well) ("fixed assignemnts"). Another type would use forms to allow on-demand or scripted checking of assignment answers; this could be added later ("free-form assignemnts").
- An assignment should be assigned as either an individual or group assignment (using groups defined in the normal way); if a group assignment, the grades should be able to be given to a group as a whole, or each individual in the group seperately.
- Answers will probably have to be submitted using the same system as the assignments are created (i.e. in a text box, possibly using the WYSIWYG system from the KB) because if they are stored as files Teaching Assistants may not be able to access them, or it will require a lot of group setup, which defeats the purpose of dynamic Teaching Assitant assignment on a per-class basis.
- Each assignment should have a flag stating whether a student is able to edit a submission (so that they can do their work within eGW) until the due date or whether they can only submit once.
- There should be a seperate "class" of assignments that do not require submissions. These could be, for instance, quizzes and tests. This way a student can receive a grade for quizzes and tests completed in-class without needing to file a bogus submission.
- Each assignment should be able to have a breakdown of grading -- for instance, the Teacher should be able to define it as being out of 50 points, with 10 for x, 10 for y, etc. When the grading form is shown to the Teacher or Teaching Assistant, then, it should show the proper fields. Fields should be checked to make sure the values entered are appropriate.
- Assignments should be able to be defined as "peer evaluated," i.e. by other students or groups. In this case, there should be the following:
- A scale as to what percentage it is peer evaluated. If 50% of the score is peer evaluated, the Teacher or Teaching Assistant's grade should account for the other amount.
- A breakdown of which students or groups should be evaluating the assignment. It will be assumed that each student or group will have equal weight.
- Grades
- All classes of roles should be able to see a graphical distribution chart of grades for each assignment.
- Students should be able to see their grades for their assignments (including non-submission assignments).
- Teachers should be able to see grades for all students for all assignments.
- Teaching assistants should be able to see grades for all students for any assignments for which they are assigned to grade.
- Teachers should be able to change any grade given by a Teacher or a Teaching Assistant (or peer evaluation), or do a "force" of any grade to any value (within normal limits). If this occurs the grade should be marked as "forced" and not calculated from its constituent parts, and any other grade that depends upon it (such as a final grade) should use the forced value. If the grade is unforced it should again be calculated as normal.
- Script Repository
- This is something that may cause some pause for several of you. It did for Reiner and Frank initially, but after discussing it with them, they decided that it's a good idea, so long as users are very aware of the dangers of using it. All access would be denied to the repository by default, so it would be up to the admins to enable it. Also, the Script Repository is necessary for my thesis :-)
- eGroupWare currently lacks user extensibility. This is generally a good idea, except that in some cases (such as in a class I'm in right now), eGroupWare provides "almost enough" functionality. For classes which may want what eGW has to offer in terms of the groupware solution but may have special needs, this can be a problem. In my case, I used eGW's users and groups features to provide access control to a hardware testing platform, essentially making a web interface to some of our hardware. However, to do this, I had to modify home.php and some other files to add the features I needed for my class, which means that I had to break CVS compatibility.
- The idea is to have a way for users to add small amounts of functionality to eGW. If they have access to the Script Repository, they should be able to click on a link (say, in the navbar on the left). This link opens something like <egroupware-path>/elearning/scriptrepo/index.php. This directory and file is created by the installation but is not maintained in CVS. The index.php file would be a very basic file (a placeholder, really) that should be modified.
- Any functionality that the Teacher wants to add should be placed within this folder, and any files linked to from the index.php file (which could itself be modified to provide functionality). Writing to the directory does not need to be controlled by eGW, at least not initially; we'll assume initially that the Teachers can provide the admins running the servers with the appropriate files to place in that directory, or that the Teachers themselves can be given access to write to that directory through the normal operating system.
- In doing this, the scripts can either be normal php scripts to do whatever is necessary, or by adding a few lines, can take advantage of eGW's environment for access control, etc.
- This does of course mean that someone could write scripts to delete all databases, for instance, should they wish it. But we're going to assume that if the admins okay the use of the script repository that the person writing to the filesystem is trusted and taking responsibility for eGW, and with a big red warning somewhere we can make sure that this is understood.
- If my experience is any indication, what a Teacher (or whoever has access) is likely to do is query eGW's normal tables for user information (or get it through the $GLOBALS method) and create their own tables to store whatever extra information they need.
- Allowing this type of behavior gives the admin/user a large amount of power to hook into eGW without needing to write an entire application to do so, making it more attractive for classes that like what eGW has to offer but need some extra functionality. Since the person writing the scripts will need access to the directory through the operating system anyways, it can reasonably be assumed that they either are the admin or have been given permission by the admin, and as such will be competent and responsible for what they write.
Please list any comments you may have.
Thanks,
Jeff
_________________________________________
Comments from dragob (30th November 2004)
Very nice to hear from this application. It is a complement of something we (actually Mitja) have been doing here in Slovenija: our app (Virtual university) has students, classes and subjects, but nothing about submission and grades: its purpose is that it allows the teacher and the students to exchange public files and news about their subjects (basically, allows the teachers to maintain their subject's web page). Virtual university works through the sitemgr for public access and as a standalone app within egw. Together with your application it would really be a very interesting tool.
Some comments on the above:
... Eventually this will hopefully incorporate (maybe as a different application, maybe within this one) distance-learning abilities, allowing courses to be taught online through eGW. ...
Here the part Mitja did fits in nicely. Fortunately they are complementary, thus you still have to do your thesis :)
... Teachers should be able to create classes. ... create assignments ... define Teaching Assistants for the class. ... control who has access to the script repository ... need to either be Admins, or they will have to be defined by Admins. If they are defined by Admins, it will have to be determined whether an Admin also defines which other users are in each class, or whether the Teacher is able to.
A real life experience from our project Virtual university (which Mitja ported to this eGW app): teachers will never do this administrative job on the net: they will have their assistants to do it, or some secretary. The teachers will at most review the submissions and put in the grades, but not do administrative work. Thus (in the view of your description of the teaching assistants), the default issue shall probably be that assistants can do everything for themselves and their teacher, however, if the teacher wants, he can limit their abilities.
...Each class should have a seperate set of students, teaching assistants, and assignments (and maybe separate script repositories). This way, a teacher using eGW teaching multiple classes can keep things organized...
Wrong. For the students and assistants point of view, this is very disorganized, as a single student and assistant must log in/out to several classes, for instance, when submitting different results. Will you give them separate usernames for each class? I would drop the assumption that the sets of students and teaching assistants are separate, and replace it by a many-to-many relationship. However, an assignment logically belongs to a single class.
...assignment should be a document (perhaps written using a KB-style WYSIWYG editor, eventually) that are required to be completed by a specified due date (perhaps with a start date as well) ("fixed assignemnts")...
A start date is useful. I hope you thought about submitting files as well.
...Answers will probably have to be submitted using the same system as the assignments are created (i.e. in a text box, possibly using the WYSIWYG system from the KB) because if they are stored as files Teaching Assistants may not be able to access them, or it will require a lot of group setup, which defeats the purpose of dynamic Teaching Assitant assignment on a per-class basis....
This I dont understand. Who has access to the submitted files is fully under your (programmers) control.
...There should be a seperate "class" of assignments that do not require submissions. These could be, for instance, quizzes and tests. This way a student can receive a grade for quizzes and tests completed in-class without needing to file a bogus submission...
Here I would propose an generalization of the polls application (with various types of questions and a possibility of several questions in a single poll=test); questions having predefined point values for various (choice) answers or for corredct replies (after being checked by a teacher/assistnat).
...Grades...
If it is appropriate for your application I would suggest that the students are represented by a student code, and then all information about grades is made publishable through sitemgr module in a sitemanager website (like it is now with the wiki module). This way you achieve that the students do not need to login to see their grades and can list grades on the subject's website. Of course when the students are logged in, they only see their own grades, and the teachers/assistants can see the grades together with names (when logged in).
...ScriptRepository?...
To me this sounds like parts of the current workflow application. There the data can be taken from anywhere and then undergo some process. Maybe take a look at it, if you have time, and then you could reuse or at least make it compatible.
In general I find your application very interesting and useful, and wish you much success with your thesis!
Drago
_________________________________________
Comments from jefferai (30th November 2004)
...It is a complement of something we (actually Mitja) have been doing here in Slovenija...together with your application it would really be a very interesting tool...
I will make sure this is acceptable to my advisor but if it is then that sounds fantastic. We will have to figure out a way we can all talk and sort this out, because I do need at least the functionality I outlined...so if we collaborate, we may need to, for instance, change the database tables, etc. This would also help me in other ways if I was collaborating with some people, because I'm honestly extremely confused by how to do a lot of things in eGroupWare and working with someone else would really help me get started. Be warned that until I get my bearings you'll be pestered with questions :-) Also keep in mind that the functionality I stated is what I need to do for my thesis, so I'd work first on getting those things to work, and then features could be added.
...the default issue shall probably be that assistants can do everything for themselves and their teacher, however, if the teacher wants, he can limit their abilities...
Probably a good point. I know that I myself do most of that stuff for my teacher :-)
...Wrong. For the students and assistants point of view, this is very disorganized, as a single student and assistant must log in/out to several classes, for instance, when submitting different results. Will you give them separate usernames for each class? I would drop the assumption that the sets of students and teaching assistants are separate, and replace it by a many-to-many relationship. However, an assignment logically belongs to a single class...
Sorry, I think you mistook me. I didn't mean that each eGW username (i.e. student) should only be allowed in one class. What I meant was that when a student opens the E-Learning application, they should see a view that shows them which classes they belong to. Upon clicking a class, they can see [their current assignments, peer evaluations they need to complete, etc]. What I meant by "separate set of students..." was that every person defined as a student should not automatically be a student in each class.
...A start date is useful. I hope you thought about submitting files as well...This I dont understand. Who has access to the submitted files is fully under your (programmers) control...
I thought about submitting files...but I wasn't sure how file access would be controlled. If the file is stored in the vfs and accessable through the file manager, you may have a random set of users that should be able to access it (a teacher, teaching assistants, and peer evaluators, for instance). Maybe if the file could be stored as a BLOB in the database...?
...Here I would propose an generalization of the polls application (with various types of questions and a possibility of several questions in a single poll=test); questions having predefined point values for various (choice) answers or for corredct replies (after being checked by a teacher/assistnat)...
That's certainly a possibility.
...If it is appropriate for your application I would suggest that the students are represented by a student code, and then all information about grades is made publishable through sitemgr module in a sitemanager website (like it is now with the wiki module). This way you achieve that the students do not need to login to see their grades and can list grades on the subject's website. Of course when the students are logged in, they only see their own grades, and the teachers/assistants can see the grades together with names (when logged in)...
This could work. When a student is associated for a class they could be given a student code for it (either a random one or one they pick, perhaps). A project for later at the moment.
...To me this sounds like parts of the current workflow application. There the data can be taken from anywhere and then undergo some process. Maybe take a look at it, if you have time, and then you could reuse or at least make it compatible...
Workflow application? Is that part of the HEAD cvs and not on the general release one yet? Or did I just miss it somehow? :-) Either way, that could maybe be done...but for the moment probably I'd keep it simple. The script repository, even if it sounds fancy, is pretty simple at its core. Probably whether I hook it in to workflow from the start would be a factor of time.
...In general I find your application very interesting and useful, and wish you much success with your thesis!...
Thanks!
_________________________________________
Comments from dragob (30th November 2004)
...I will make sure this is acceptable to my advisor but if it is then that sounds fantastic. ... we may need to, for instance, change the database tables, etc...
The way I thought it out is that we define a common database system and then develop the apps separately (discussing any possible changes in the DBs). This way we will be compatible and you will be able to say you did your thesis alone. Mitja is preparing some documentation and you'll have to do it for your thesis anyway.
... Be warned that until I get my bearings you'll be pestered with questions :-) Also keep in mind that the functionality I stated is what I need to do for my thesis, so I'd work first on getting those things to work, and then features could be added...
Within our time limits, I am sure we will answer your questions.
... What I meant was that when a student opens the E-Learning application, they should see a view that shows them which classes they belong to...
Great, this is exactly what Mitja did by now. His examples will surely help you.
... Maybe if the file could be stored as a BLOB in the database...
This is a good option. However: take a look at how the File Center by Frank Alcantara works (Reiner can help you get in touch with that).
...This could work. When a student is associated for a class they could be given a student code for it (either a random one or one they pick, perhaps). A project for later at the moment...
At our uni nad I would assume at most of the others the students have some sort of student ID. We use that code.
...Workflow application? Is that part of the HEAD cvs and not on the general release one yet? ...
Yes.
Another concept that may be useful: what I do to my students is that they must register in the eGW via the Registration application which is accessible as a module in the SiteMgr or as a link at the login form. After they all register, I assign them appropriate group and then they have access to the apps we use (FUDForum, Wiki, TTS, Email, Projects).