by Karl Loren
Started Saturday, January 3, 2004
Last Revised 5:25 PM Thursday, January 8, 2004, PST
Changes Made
On XX January Inserted Below In This Type Style Bookmarked:
1 2 3 4
Changes Made On YY January Inserted
Below In This Type Style Bookmarked:
5 6 7 8
This is the page where Karl Loren has written about the joint collaboration between Karl and Gordon Bateson, on the development of a "Learning Management System" for use with eCourses to be administered on this web site.
(This page includes Karl's revisions in line with Gordon's first reading of this page and Karl's comments back to Gordon.)
The Primary Purpose is for Gordon to use his knowledge and skill with Hot Potatoes, Moodle, MySQL, PHP and other similar resources to create and implement a "Learning Management System" based on the design, or conceptual, features of that System set forth here and in various other pages of this web site -- those features mostly authored by Karl Loren.
More specifically, Gordon will be building the Learning Management System, "LMS," (or "System"), by using Moodle as a basis and modifying it as needed to meet the design concepts. Gordon's work includes the creation of MySQL tables needed to hold the eCourses and System data, and the writing of PHP script needed to handle and administer that data so that "Users" and "Administrators" can work with it.
The primary unique feature of this LMS, in contrast with any others found, is the eCourse design concept developed by Karl Loren, specifically having to do with the criteria for "passing" quizzes, and the concept that study material should be broken into "chunks" with the second such chunk not be available for the student until the PHP script has recorded the fact of the student passing the quizzes associated with the first such hunk, and passing that quiz (or those quizzes) with the passing criteria as established in the Course Table for that quiz.
(Another major design concept of these eCourses is completely administered within the HP quizzes -- and does not require any particular support from the LMS. This concept has to do with insisting that the student use a good dictionary and look up definitions, and further that the eCourses are designed to instill a "habit" in the student for using a dictionary for this purpose.)
In many cases this passing criteria can be referred to as 5x100% which means that the student must eventually attain a 100% score (all correct answers -- no incorrect choices) when he does a quiz. Further this "same" quiz, with a different set of questions each time presented, will be presented to the student repetitively until the student has attained the 100% perfect score on EACH of five successive passes through the quiz.
This criteria for passing is acknowledged, here, as a level not seen within any other LMS found.
More generally, this LMS is intended to control the access to eCourses and the progress through them based strictly on the PHP script being written by Gordon.
First, this web site is especially designed to deliver eCourses (electronic courses).
Next, these eCourses are intended to be promoted primarily on other web sites. For instance, I have about 25 Vibrant Life web sites, more than 100,000 pages. I intend to create eCourses related to various pages scattered throughout my webs. Generally I will continue to provide web pages at no cost to the browser, but also suggest that the reader may understand that material better if he pays a fee and takes an eCourse related to that material. That would give rise to a link to these eCourses.
Major Purpose #1 deals with who is the "public" for this web site, this LMS and the eCourses offered here.
Basically our "public" consists of both "internal" and "external" people. "Internal people will be those who are staff members for Vibrant Life or any client who hosts his eCourses here. "External" public would be anyone else -- not staff.
Of interest to Gordon is the fact that I want the LMS to accommodate different "clients" who could each have a section of this web for eCourses of their design. Generally this means that users who are interested in the eCourses offered by some client must be able to access that section of the web and not bump into eCourses or students from other clients.
Presumably they would access "their" eCourses through a direct link, such as:
http://www.vibrantelectroniccourse.com/C/A/1/index.htm
However, the actual first entry link would undoubtedly be to an introduction and registration page for that client.
Initially there are two "clients" consisting of
I have one further prospective client and there could be many more. Probably every client would have both categories of students -- internal for staff of that client and external for customers and the public.
I presume that a table within the LMS MySQL database would be something like:
client table
client_id
home_page index page within some folder on this web,
uniquely assigned to this client
name presumably company name, could be an individual
url client main web site
contact_1 further information
contact_2 further information
top_administrator_assigned
staff_id for top administrator
date_started as a client
The client_id would then be a "foreign key" in virtually all other tables. If I understand this correctly this table would allow ONE database and ONE set of tables to be used for all clients, all eCourses, all users, etc.
The second Major Purpose is to provide a user (prospective student) with a smooth experience for "logging in" to the restricted area and "registering" as a (prospective) student. The user would probably arrive at this site with an idea, already, of what course he will want to take. Thus it is not vital that he be immediately presented with a long list of possible courses.
The initial "log in" will involve the person having to receive an eMail at his home address and then clicking to "activate" his account. He would then be a "registered user." The further "registration" as a student would not require further eMail notification. After completing the information for student registration, he would be called a "registered student."
When he is a "registered user" he will have accepted a cookie which can then be used to configure a user_home_page customized for him.
Even though he changes from "user" to "student" the "user_home_page" can continue to be used, configured to reflect his status.
This would be "his" home page whether or not he had completed the registration to be a student. If he has not yet registered as a student, this home page would advise him to do that and provide a link. Once that cookie is working properly there should be no further "log in" required for that person -- other than a brief verification of the password before the person is allowed to use points to select a course.
Registration as a student would require about the same information as is required to enter and process a credit card purchase (of points, for instance). A "user" becomes a "student" simply by adding in this additional information -- into his profile. (He would not have to enter his credit card number since this web is not secure.)
"His" home page will provide his name and any other information about previous courses he has started, or completed, number of points available, if any, and whatever other information seems appropriate. (I note that Moodle forum includes the opportunity to provide a photo of the person -- sounds like a good addition to the registration process. Such a photo could be part of the user_home_page.)
For the new student this home page will advise him (by name) to take one of the several free sample courses or the "How To Use A Dictionary" eCourse as his first course. He should be able, however, to click to look at other eCourse titles and descriptions.
The number of distracting options for a new user should be held to a minimum -- and after a student has completed any one course "his" user_home_page could include more options of choice. This page must be very simple for the new user.
He could pay for eCourse Points prior to or after registering as a student. If he has no points in his account, then his home page should include a link to the shopping cart and a notice that he needs to purchase points. Note that students may transfer and earn study points. That will not be much of a factor for the LMS, but it should be understood as one of the actions of an Administrator to handle. Click Here to learn about earning and transfer points.
Although it may take a day or so to insert recently-purchased study points, the newly registered student could immediately do one or more of the free sample courses. This would be a good idea anyway, since the first course that costs money is planned to be the "Dictionary" course at $250. Taking a few free courses, particularly that demonstrate some parts of the "fee" course would be good marketing.
(There is a functioning shopping cart now on the web. It is not ideal since for now it probably insists on adding "shipping charges." It will be changed. It is at:
http://www.vibrantelectroniccourse.com/ShoppingCart/index.htm )
The immediate practice will probably be for Vibrant Life staff Administrator to insert the student points purchase manually into the student's student account when it exists. Vibrant Life will be "awarding" points on the basis of purchases and other actions, so these "insertions" may not have involved a shopping cart purchase.
As suggested by Gordon, there needs to be a web-form interface so that the Administrator can adjust the study points for any student.
There should be some sort of table to reflect the details of any manual insertion (or other changes) of points -- including the date and who was responsible for that insertion, and even a note of the reason.
insertion table
student_id
staff_id
number_points
date_inserted
staff_name_inserting
note room for perhaps 250 characters of text
(The above reference to "staff_id" suggests another table for assignment of a staff_id to any administrators who has access to student reports or records. Any insertions should be validated against existence of a valid staff member with authority to access student accounts.)
staff table
staff_id
client_id
staff_name
staff_email
staff_detail
date_started
Presumably there is also a "permissions" table that would link to the
staff table. Not everyone in the permissions might need to also have a
staff_id entry.
As much as possible at this early date this "insertion" procedure should be configured so that later it can be automated.
The "smooth experience" continues for the new student, with or without points, and encourages him (on the student home page) to do one or two sample eCourses, free.
There should also be a link to a further explanation of the "How To Use A Dictionary" eCourse, including why it is so important (which will involve a link that leads to various articles in or out of the restricted area).
Finally, the smooth experience includes "selecting" a course -- presumably the "How To Use A Dictionary" eCourse. When he selects that course the appropriate points are deducted from his student account and he is given access ONLY to the first study segment of the eCourse.
The student home page could provide a link to the "types of reports" which he will be able to see once he has started an eCourse, or to the actual reports for eCourses he has started.
One piece of additional information MIGHT be the option of linking to a section of testimonials from other students (when that section has enough testimonials to make it worthwhile). However, this web site is not a "communal site" where people "hang out," but rather a very personalized eCourse delivery system -- the student should feel that the entire web site is devoted to HIS use and success.
Once he has selected and started any course, then his home page should prominently feature summary type reports (or links) on his course progress, and minimize other data. Once he has started any eCourse he should be encouraged to move through that course quickly. This can include a message on his home page, such as, "You last worked on your eCourse, "How To Use A Dictionary" on XX date when you spent XX hours/minutes" or some such message customized to his situation.
It appears to me that there could be four different student home page configurations, pre-established and which of these four are presented would depend on his status.
User, not yet registered as a student
Registered Student without points
Registered Student with points
Student who has started a course
The third Major Purpose involves the smooth experience of Administrators.
Each client can appoint one or more "Administrators," and they, too, should have a smooth experience when it comes to administering their section of the web site. (In some cases Karl Loren may be the Administrator for some client. He would register as an Administrator for that web section, in any event. This raises the question of whether name duplications will be allowed in the system, or how to allow one person to be the administrator for two different sections.
First the "Administrator experience should not require any PHP or MySQL knowledge. All the work by Administrators should be on PHP screens, or HTML screens which are coded to make the appropriate entries and changes in the MySQL tables.
There should be an "administrator_home_page" for each Administrator. His cookie, and the "permissions table" would identify him as an Administrator. Because of the greater access given to Administrators there should be at least the same amount of information for him as is required of a student. The verification process should be more strict, probably requiring restriction to a particular URL if that will work for him. He should be required to enter his password every time, even though the cookie pre-identifies him.
Must students can be presumed to have little or no knowledge of HTML, or any coding. Administrators will probably vary more widely, with some being skilled web designers and others having little or not knowledge of even HTML.
At first there won't even be any other clients than me, so this feature is not time-urgent, but either now, or later, the PHP screens for use by the Administrator should be very user-friendly.
The method of "uploading" an eCourse, particularly, needs coverage. I have looked briefly at what Moodle seems to provide and it doesn't seem at all compatible with HP.
I assume we need to be able to allow a HP author to develop his eCourse on his local disk, and publish it, in whole or in part, to an assigned web address. The LMS should be able to "assign" a web folder that is empty and is then "reserved" for future use by some author to publish into. The client could get permission ONLY to publish into this designated folder.
Since the Moodle system does not provide for this functionality, this "ease of publishing" will be a large part of Gordon's PHP coding work.
It will probably be important that these eCourses follow the naming convention I have established (here). Adherence to this convention will facilitate administrative handling of new clients and new eCourses. That naming convention includes the fact that every eCourse folder contains a "sub-folder" for all the images used in that eCourse. In other words the main folder is completely self-contained -- it has ALL the files, including all images, for that eCourse. It would be possible to have links to web pages on entirely different sites, but this should be discouraged as a matter of eCourse design. It allow loss of control by the LMS of the progress through the eCourse.
The fourth major purpose involves the strictly followed procedure for handling eCourses, including the capturing and storage of data, the requirement of meeting "passing" criteria, and the presentation of ONLY the next authorized segment of an eCourse.
I have previously written that I could see no value in capturing the individual questions and answers every time a quiz is done. However that opinion was based on an assumption that when you select 5 out of 25 possible questions, and present those five in a shuffled order, that the "number" on the screen would NOT be the number in the static form of that quiz. If this is true, then the number, alone, would not relate to any text that could be recovered.
However, if the capture procedure looks "below" the quiz on the screen, and captures the original (static) number for a question, and an answer, then the storage of information about each question and each answer would seem quite practical, and possibly worth doing.
In any event, the main question here is WHAT is the event that triggers the beginning of a "capture of data" action.
I would suggest that the triggering event would be the first click, of any sort, after a quiz is loaded onto the screen.
In most cases this would be a click on "show all questions" or a click on an answer. There could be other clicks, even including the browser refresh button.
All quiz pages include a "restudy" button, which, when clicked, should trigger a beginning of the recapture, and a means of recording WHAT was done. Presently I don't see the need of capturing what type of event the triggering event was. The only captured events would be answers to questions, right or wrong. If the refresh button is clicked before any questions are answered the capture on this segment would be zero score and no results captured.
I would like any of these actions to trigger a start to the capture, noting the date and time of that start. If individual questions and answers are NOT captured, then the end of the capturing action would be answering the last question, correctly, or closing the window, or refreshing the window. At that end of capture whatever score that has been generated would be captured including whether or not all questions had been answered with correct answers.
Once a quiz has been answered, all questions, with 100% score, one time, and that event captured and entered into the proper MySQL table, there needs to be a counter that keeps track of the number of SUCCESSIVE 100% scores attained for that segment.
After the first 100% perfect score, the same quiz is presented again, with a new selection of questions. If any of those questions are answered incorrectly, the "counter" is reset so that there needs to be a "NEW" first time through at 100% correct.
Some quizzes are "timed" and include a "counter" showing a time, declining from a number of starting minutes. The counter stops counting when all the correct answers have been selected for the questions on the quiz.
The passing criteria for each quiz is governed by a field in the table for that eCourse.
When the a quiz segment would then be followed by a study segment, the successful completion of that quiz would then change the access by the student to BOTH the next study segment, and the next quiz segment. The student will click on "quiz" to advance from a study segment to the first following quiz segment. (This means that study segments each have a link to the first quiz that next follows.)
There are "summary type quizzes" with large inventories of questions and there is a "final type quiz" that covers the entire course. The same 5x100% standard applies to the summary and final quizzes.
Finally, after all this success with quizzes the student is STILL required to send an eMail message to the Course Administrator (currently me). The program cannot evaluate what type of comments are written, but the Course Administrator grants a "final graduation certificate" only after the standards have been met on the quizzes, AND there is a "favorable" eMail message from the student --- "good report" message. The Course Administrator will personally handle and debug any bad reports.
Even though part of the motivation for this course is that there is no refund of the $250 because of failure to complete the course, or any other upset, the Course Administrator certainly has the authority of making a refund if appropriate.
It appears that the databases and tables at this address:
http://www.vibrantelectroniccourse.com/lms_admin/mysql-database-report.html
are what were probably put there from loading Moodle, and not what Gordon may have designed personally.
I think I will re-assert the change in definition that Gordon first used, relating to "segment" and "quiz."
An eCourse consists of:
which are generally held in a MySQL table, not available to a student, with files presented to the student depending on passing criteria contained in the field for each quiz in the table.
That table might be something like this:
course table
course_id
client_id
course_name
course_simple_reference (such as "Study
101") (The course_simple_reference
should be unique for any one client and can be used to precede the
course_name, such as "Study
101 -- How To Use A Dictionary")
Any course consists of study segments and quiz segments. There are also files that are not considered segments -- generally files that are called up from inside a study segment or a quiz segment.
Thus, there is then also a
segment table
segment_id
course_id
segment_file_name
segment_file_address
segment_passing_criteria
And, a
result table (only for quiz segments)
segment_id
course_id
student_id
segment_timer_end_count (in minutes and seconds:
xx:xx)
segment_start_date
segment_start_time
segment_result_1 (there is probably a better design, since this
would call for 40+ such fields)
segment_result_2
segment_result_3 (etc. as necessary to cover each question and each
answer)
segment_score (less than 100% means not
perfect)
segment_number_correct (may be unnecessary)
sucessive_correct_segment_counter (goes up and down until it reaches 5
for most segments)
segment_end_date
segment_end_time
There is need for the student to be able to see a list of all segments he has
already either passed per the criteria, if a quiz, or read, if a study segment.
He should also be able to see any segment he has been working on, but not yet
completed. All other segments should be unavailable, even if he fishes
around for a web URL.
A student will be strongly discouraged from taking any fee course when some other fee course is incomplete. Approval to do this will require a personal eMail message as to why the student wants to do this -- with assurances that he is not bogged on the incomplete course.
Thus it appears that we need a "permission" that can apply to one file at a time.
This next major purpose relates to the restrictions and permissions function.
I have covered this previously HERE.
This purpose relates to the type of reports and analysis that will be available to Administrators and students.
I have not completed my consideration on this subject, but my preliminary thoughts are that what I have seen in Moodle seems quite fine to me. This would have to be modified, possibly, by the fact that we have different clients, each of whom would only be able to see reports relating to their web section.
This Major Purpose relates to the availability of MySQL tables and the PHP source code to me and my staff -- presuming that we could understand them and be able to make revisions. In this regard I would want Gordon to add any explanatory notes to his coding to help someone else understand it and be able to revise it.
Gordon has already responded to this Major Purpose, and this will be no problem to implement.
As I recall PHP coding does not "survive" the publishing process -- I believe the server converts all PHP code into the appropriate server commands, not found on the pages being presented in a browser? If this is so, Gordon should find a way to place the PHP coding into a location where it does not get processed by the PHP engine (?) and remains intact so that we can download it here on our hard disk, explore it and ask questions of Gordon about it.
I want to lump in here also the purpose of acknowledging the important role played by Gordon Bateson. His name and background, including links, should be included in an "About" file in a help section. He will be free to use this LMS as a reference of his work.
This purpose also covers my desire to maintain this LMS as a proprietary service. Whatever part of it is "Moodle," of course cannot be proprietary, but as I understand the open license we can make changes in Moodle, and add PHP, etc., and this whole LMS can be considered proprietary. I believe the fact that the PHP code does not survive the publishing activity means that the PHP code, itself, is not available to anyone even who has access to the server.
I have raised the possibility of creating a "joint venture" with Gordon, particularly with regard to using this LMS for Japanese language eCourses, either hosted on my server or his. That possibility remains open.
It also remains open for Gordon to continue to provide programming services for this LMS or for other Vibrant Life needs -- to be explored.
There is a testing of the final product, by Karl Loren, and the opportunity of finding bugs, if any, and getting them corrected within this original specification.
I assume that I would simply enter the web as a new person, follow the registration process, pay for some points, select a course and take it all the way through, and then take a look at the student (and the Administrator) reports available.
Gordon has commented that a much more thorough testing should be done. I'll be looking into that.
This major purpose may well be icing on the cake. I figure that Gordon can also make many of these pages "pretty" and to incorporate clever drop down menus and other navigation features that will enhance the appearance of the entire web site.
My own published pages were composed in Front Page, but carefully not using any of the proprietary features of FP. Likewise, I do not yet know enough of Dream Weaver to use any of the features it might have for page enhancement.
To any degree that Gordon can enhance the page appearance, particularly within the LMS, I would like that very much.
I notice that Moodle has many features which are not now being implemented. It may be that some of them seem worth implementing. My present feeling is that either we will ask Gordon to revisit the scene, or that we may feel competent to do whatever new PHP coding or MySQL work that would be needed for these features.