Most things I do in GITI are not that difficult to code, actually, everything I do is very simple code. There is nothing object oriented or even anything more complex than a few simple arrays, it keeps GITI sane to work on to not write it differently (and I’m not sure to what extent PHP would be flexible to other constructs), but there are areas of complication in GITI.
Usually these complications are in the form of logical process or user interface considerations. Last night I did something I have considered doing for a long time, I copied all of the instructors and their email addresses from the class items to the address book system to prepare for a more efficient way to store more information about instructors, including their pictures, office hours, office location, etc. My problem comes in the form of how I want to handle the way GITI thinks about this storage of information. For some unknown reason I wrote some really complicated code last night to break apart instructor names from the single-field format to work in Address Book’s more complicated multiple field format for a person’s name. The code is pretty reliable, have a look at http://users.pcfire.net/~curtis/class_INSTRUCTOR.php.
Now the issue that I have to deal with, which apparently does not involve that code at all, is when, and how to put the instructor in the address book. GITI now supports a multiple step academic procedure going though: planning, registration, semester activation and semester closing/grading. This process means that I have multiple locations where I could make this insertion, but I have to pick the right one. The largest problem I am facing is that users are not required to go through the process, they can do their course statuses manually still, insert a class, and then change its status as needed. For the process, I have thought about putting instructor information in the address book during semester activation, , but I am almost afraid that would be too invasive of that part of the process and perhaps even an unfriendly burden on the user when given the option to do that for all instructors at the same time. During the registration process might be a little more ideal, as it is more of a calm setting, usually involving a lot of waiting after registration itself; but there I run into the issue of instructors changing between registration and course activation. The third possibility I have considered is adding a new step to the process, this process would be a per-course process to be handled after semester activation, something I have temporarily called the “Syllabus” step. This step would give the user the chance to update course descriptions, add special notes about the instructor’s policies, as well as add grading information to GITI. Optionally, I can also let the user finish the process off by adding a bulk insertion of assignments at the end. For users who would change their course information manually, I can check against the database manually at the time course info is edited and let it catch things and process them as needed, since I may end up doing the same thing with edit anyway (as a simpler way to change instructor info than visiting the address book management tools).
The education module is at this point very robust and every decision I make about the way things function will impact its future development. It is now possible to streamline the entire process of documenting academic information in GITI. We are so far beyond adding individual courses and then adding assignments to them (or better yet, adding assignments and associating them with an array of courses stored in a file on disk somewhere).
Once I get over this decision hurdle and then put all of my functionality in a logical order with itself I will spend a good amount of time with Visio or another tool and rebuild the native GITI menus for the module, as well as its own internal index and the “Edu Bar” on the side of all module pages. There is a lot of stuff burried in the module that it is not revealing in a useful way.