Also, this only touches on Instructors. It doesn't mention Greeters, Live Help, Mentors, etc. However I think with some tweaking - it could also work in those areas (and generate payment for those folks on the very front lines of New Resident Indoctrination!)
--------------------------------------
Proposal to Overhaul the Second Life ™ Education System
Overview
Linden Labs (LL) has made clear that the current system utilized within Second Life (SL) for the processing of instructors and classes is non-scalable in its current form. As the population of SL continues to grow, the educational system must be overhauled.
My proposal would be widespread and require work on LL’s side in order to set up the infrastructure needed, but I believe in the end it would pay off in scalability, flexibility, and growth potential.
Goals:
1) Reduce administrative overhead to Linden Labs.
a. Instructor certification / approval
b. Class certification / approval
c. Class attendance / review
d. Instructor payments
2) Minimize the opportunity to cheat the system.
3) Provide for future growth
4) Provide flexibility for modifications
5) Continue to offer students classes for free.
Goals 1a – 1d will be specifically outlined in this document. Goals 2 – 4 will naturally “fall out” of the discussion and will be noted in some cases.
Goal 5 however, is my own. In a nutshell, I firmly believe that instruction should remain free to the student. Charging for classes forces instructors to compete with each other, reduces the number of classes taught (ie the “fun” classes), and causes the prospective student to make a choice – to pay for a class, or to not go at all. This is a much bigger discussion and is beyond the scope of this document. Suffice to say that in my view, offering free classes is a goal on par with the stated / implied goals of LL.
Details
1a) Instructor certification / approval
First things first, LL should immediately modify their web site to only allow an account to apply for certification once they have reached the minimum required account age (currently two months). This will immediately cut down on the number of requests received that are automatically ineligible based on account age. Regardless of what LL does to overhaul their education system, this step needs to be done.
As far as the actual certification process goes, I do not have enough information to make recommendations. On the surface it sounds as if this will remain a fairly manual process requiring effort by individual LL employees. However, as one requirement for certification is a clean rap-sheet, if there is no mechanism in place within the database to mark accounts with offenses (ie an account offense table of some kind), thus requiring LL employees to do manual searches for each account they wish to investigate, then that is an area for improvement. (I would seriously doubt however this kind of thing was NOT in place!)
There is one new piece however to the certification process – the Linden Classroom Box (LCB) which I will discuss in more detail later. For now, what happens is that upon certification, an instructor is flagged, or a record added for that account in the instructor table, or whatever they do now, and then they are assigned a LCB. Each LCB has a unique number and is for a specific instructor.
1b) Class certification / approval
A new UI form needs to be created that is accessed via a menu. Tools, perhaps – but that is really up to LL. This form will be used by the instructor to create, modify, delete, and schedule their classes. For non-instructors, either disable the menu item, or disable the relevant items on the form. In my opinion disabling the menu item will be easiest.
In most respects, creating a class (for approval) will be similar to creating any other event. As normal events may be created via the SL web site, I suppose educational events could as well (with a site modification), though this document will not address that.
Though I am writing this in Word and could mock-up screenshots, I know I will be copying this to a forum or 3, so I will need to instead describe the new form as clearly as possible.
To visualize the new form, break the form into three horizontal sections: top, middle, and bottom. No need to describe sizes, as this is for illustration anyway.
In the top “section” of the form will be standard descriptions and instructions. Forms can never escape those.
The middle section will look generally like the current Events tab does now – a list along the left, with the details of the selected item along the right. In this case, the list will be the list of Approved Classes, and the details will be exactly that – the details of that class.
The bottom section will contain the buttons: Create, Edit, Delete, and Schedule.
First, only an approved/certified Instructor may create a class. This is controlled by the fact that only instructors may even access the form. In other words, no work required by LL staff to administer this.
Clicking the Create button opens a form where the details of the class are entered (Class Details form). Buttons on the new form are Cancel and Submit.
The fields required for the Class Detail form are as follows: Skill Level, Topic, Course Title, Description, Duration, Mature Flag, and Instructor(s).
Field Descriptions:
Skill Level: Dropdown list for minimum level – Basic, Beginner, Intermediate, Advanced. Beginner- Advanced are fairly clear. Basic though would be for those things that all SL residents should know. Things like Camera Usage, Find Tab Usage, Snapshots, etc. There may be overlap in these descriptions, but that may be worked out later.
Topic: Dropdown list to cover the topic/category of the course – Building, Scripting, Animation, Clothing / Worn, Textures, Machinima, Avatar Modification, SL Foundation, etc. This list will need tweaked a LOT, but I am just throwing out examples.
Course Title: Self-explanatory.
Description: Self-explanatory.
Duration: Self-Explanatory.
Mature Flag: Though not allowed now, I do see a time when mature classes could be taught (escorts, etc). Up to LL of course, but just tossing out the idea.
Instructor(s): The list of possible instructors for this course. Each instructor on the list must be certified (simple lookup upon submission). Note that this is not the list of *required* instructors. If two names are listed, the class does not require two teachers. It just means that two different people are allowed to teach this class. This allows the teaching institutions to create classes and let different people teach them without having to get each one approved.
As a side note - and beyond the scope of this document, but what this may also open up is for classes to be created and then listed someplace – maybe LL control(?) – and instructors could be added / removed from the list. I’m not sure really, but I see that this could be used for far more than how I have defined it. Perhaps the schools could "own" classes and their instructors may teach them. Many possibilities are gained if you build flexibility into the foundation!
When all filled in, the instructor clicks the Submit button and it heads to LL for approval.
Once approved, the class now shows up in the approved class list for all instructors that were included in the Instructor(s) list.
Should the class ever need modified, simply use the Edit button, make the changes, and submit. The OLD class will remain approved, but will change over to the new class description upon LL re-approval. There may be issues here that need resolved, considering that multiple instructors are on the list and what if one decides to change the class. Those details can be worked out later.
To Delete a class, press the Delete button. Obviously there would be confirmation dialogs, and again we open up the issues regarding multiple instructors and one person deleting.
To schedule a class, simply press the Schedule button and fill in the Date, Start Time and Location. It would be up to LL to decide how far in advance the class must be scheduled.
1c) Class attendance / review
This is where the most infrastructure and development will be needed by LL. But once done, it will provide the most savings.
Linden Labs needs to create a device, a “box”, that can be rezzed into the world. This box, the Linden Classroom Box (LCB), may not be modified, copied, transferred, etc. This is important for a variety of reasons.
First, with no ability to be modified by the community, it provides a sense of security that there cannot be any cheating.
Second, since only LL may modify it, they may make changes to it as the game expands to include more things – additional options, more reporting, etc.
Third (similar to the first) is that all the LCB’s remain constant and under LL’s control.
So what do they do?
The instructor rezzes the box at the beginning of class (much like they currently do for supplies). The box then gathers the data that LL wants for review.
Instructor: Since the box is assigned to a specific instructor upon certification, the box “knows” who the instructor is.
Attendance: Each student either touches the box, or just proximity (pros/cons to both) to have attendance recorded.
Class: The class is recorded by dragging the class from the Approved Class List onto the box. (Whisper feedback or such). This may be done in a variety of ways – typing in Class ID, choosing from a menu the box puts up for the instructor, etc. Whatever LL decides.
Upon completion of the class, the instructor chooses (from an option on the box) to submit the report. This goes to LL in whatever format they choose, to wherever they choose, etc. This is the virtue of the fact the LL “owns” the code – they can configure it to do whatever they want, whenever they want, and it will be in place for all instructors from then on. It will always be in the format LL desires, even if they later decide to change the format.
A notes field should be allowed so that the instructor can make any comments or corrections. For example, they may have had a couple of "watchers" and need to note to LL to remove them from the attendance. Or perhaps they totally crashed and the Notes would contain the entire attendance and an explanation. I would also suggest that if the Notes field is used, then it would immediately flag the submission for manual review (below).
On LL’s side, they now have a cornucopia of data to play with – IF they choose. Under most circumstances (other than pure spot-checks), this can immediately approve a payment – though by policy it may be scheduled for a later date.
However, with all the associated data there is plenty to work with for exception reporting. Some things that may raise a flag might be:
A) The same Class (classID) being taught at overlapping times. Obviously this may be perfectly valid, but it may generate a note to have someone pull the data for the two classes to look closer.
B) The same student in classes that overlap. This also may be legitimate if they left one class and went to another.
C) These are just a couple of examples of things that LL may set up behind the scenes – jobs to run the data and flag exceptions for further review.
Simple, automated, scheduled jobs would be run to check all the class reports being submitted. Again, huge savings on LL's part.
Should nothing be flagged – the instructor is paid. The system may even be set to automatically schedule payments for classes that are not flagged. Again, all this is on the LL side and can be done however they wish.
As only the exceptions (and spot-checks) require LL review, this will alleviate a good deal of the overhead.
As can be seen, the majority of the savings will come from the post-class attendance review, since in most cases the payment approval should be automatic. However, this requires the most changes in order to get it to work. But I also believe that it will provide for the most flexibility for later on as the game grows.
Side note: basically, the database and associated software needs to be doing most of the work. Not the game. And most certainly not the employees. They just need to build it.
By utilizing a database record for each LCB with the appropriate “setting” flags, LL could then spot check specific instructors by turning “on” full logging for their next few classes, and then turning it off again when their check is complete. This alleviates being swamped in data they do NOT want, by only recording and sending what they do. And by using a unique record per LCB, which is in turn tied to a specific instructor, the opportunity for further growth is virtually unlimited. As new features are created, new fields/flags can be added to the LCB table, thus opening up those new features for all future – and existing – instructors / LCB’s currently in the game. The key is to build flexibility into the system.
Besides the LCB, every “variable” should be stored someplace. Currently 5 students are required in order to get paid. What if they decide to change it to 7? There needs to be some record someplace with that value that can be automatically looked up by the exception / payment processes. None of this should be manual. And to be honest, if LL is not currently using the database to its full advantage … then that would be a HUGE savings and needs to be done asap! (I am speaking generally of course. I am certain that these most basic principles are in full use, and more.)
1d) Instructor payments
As has already been noted, barring an exception (see above), instructor payments may now be scheduled automatically. This eliminates the class-by-class review process required today for payments.
A word about cheating and the use of Alternate Accounts. One could in theory come up with many methods to try to account for all the possibilities. However, in truth, if LL is willing to open the floodgates by removing the credit card requirement for accounts, then any effort to combat the problem would be treating the symptom and not the disease.
One final change. To benefit the newly-arrived resident who has a desire, and a need, to learn, Educational Activities need to be broken out onto their own tab. This gives the new resident a clear indication that education IS available when they first see the tab on the Find window.