Category: Programming

It has just occurred to me that something about the way I handle assignments in GITI is a little off. While the concepts for the assignments are the same as are used in regular classes or even online classes, they do not always truely reflect the work flow and other features of the student’s side of an assignment.
An example of this can be seen in the paper I am presently preparing for. I have a certain part of that assignment due on the 8th (although, I have GITI making it due tomorrow to give myself time). The assignment is to prepare an APA style title page, abstract and reference page for the paper. That is all that is due tomorrow. The problem I see is that that stuff is shoved into Assignment # 1342, even though it is technically for the completion of Assignment # 1348 (due March 24th). There is no mechanism for moving the completed stuff (the “Docs”) to the other assignment and no way to incorporate notes or anything else I add to assignment 1342 into the final paper assignment (#1348). Last semester I had a similar problem, in American History there were 3 “research projects” that led up to one final research paper. There more than here, there were useful things that I could have used in the final assignment.
This analysis brings me to two new types of assignments that I would like to add to GITI. One is “dependant” assignments that can recieve information from other assignments (maybe using GITI’s Link functionality). The other is “marker” assignments, these assignments exist to receive grades, but do not necessarily need to appear on the schedule. The “markers” are due to a discussion board assignment in one of my courses (Art History) that will almost certainly always be done at the same time as my quizes, and therefore, are redundant to appear on the schedule proper.
Another potential change is the addition of a control on the GITI Home (Summary v2) display for assignments, which would prevent the display of any assignment whos “Date Assigned” date had not passed, giving the user the ability to actually use the field for something useful, such as entering that date to be the date an assignment will be active. In online coruses this could be quiz activation dates or any variety of things like that. The idea being to bring more relevant assignments to the front and supressing assignments that can not be dealt with yet. This function may also at some point come with the ability to “surpress” an assignment, such as a test or quiz that is to be taken in person that has already been prepared for, even though it has not been finished.

GITI has many nice features, including its ability to track file names for assignments and in general be responsible for holding information about the majority of my academic work, but there are some areas where functions that are not directly part of the Education module, but that it relies on, have failed to be developed as well as the Education module components itself. Today the external dependancy that I am pissed at is the GITI ‘Doc’ module. ‘Doc’ is a simple module, always has been, with its primary functionality to be allowing the writing of lengthy documents within GITI itself. I was attempting to work on a research paper for Cognitive Psychology and found that I could not easily do a page break without having to add a new document to the assignment for each page. This is somewhat less than ideal. I also found that there is no concept of spacing for things like vertical centering because it is not something easily done in HTML (except with tables, which I suppose might be my best bet here?). I do love Doc, but sometimes its simplicity becomes a hinderance to my work flow, since I sometime have to find creative ways to do what I want to do in it. That being said… Doc is a lot less annoying that Microsoft Word for a lot of tasks. Word has this thing about pagniation that no matter what setting you put the thing on, it still recognizes that it is on a page and hints at this (if even only by little dashes across the document). GITI Doc has more of a flow and I can type most of my formatting without fighting with Word’s complicated controls for that type of thing. I don’t have to loose flow and use the mouse to do things like bold my text, or apply an underline, I just type <strong> and <u&gt where I want it to be :-).
I need to spend some time working on things that are not part of Education, I might one day leave the world of academics and have a need for some components of GITI for other things.

I feel like I have rewritten the ToDo module so many times, but it probably has only been two of three rewrites. None of my rewrites have been anything useful, or anything I have even really looked at after it was written. There was even one revision that once completely finished, I rolled back to the original version of ToDo. Now I think I have something that might work well. I have moved away from my traditional GITI item manager style of writing a module and moved to a somewhat smaller implementation. The module’s current entire UI is displayed below. All there is to it is a list, each item with a checkbox, a method for deleting unwanted items and a way to add new entries. As with any GITI module, this is not as far as it is planned to go. This is just its primarily implemention, on the GITI summary (home) page. Additional functionality will be added to allow items to have a deadline, as well as add a verbose description.

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.

Getting It Together Interface… I never get tired of typing it out like that. In the past two days I have been working on GITI, primarily in the education module. I have made almost no progress towards the mobile version, but at the same time, there is no immediate need for it.
At this time, I am grasping a very strange notion that has just occured to me… the Education module is essentially finished. All of the functions I had hoped to include in it are in place and everything works now. There are a few buggies to tweak here and there, but nothing major, no huge goals to accomplish, everything is in. Last time I felt like this, I threw out a few sample interfaces for GITI v2… I don’t see v3 coming out of this or anything, but I do need to spend some time assessing GITI’s other functions that do not rely on me having an academic career to keep attention to, although, that isn’t likely to be an issue (more on that later). The most neglected things on my roster right now are things derived from the Notes system in GITI. This includes KeyChain (software license key manager), Item Journal (personal and per-item journaling), To Do (to do list, needs a good whacking) and Doc (think like Word, except allows HTML formatting and no damn paper-clip). KeyChain does what it needs to do, but nothing else. It won’t even edit keys once they are added. Item Journal is nearly non-existent in its stand-alone form. It needs work in that form, as well as in Blog Integration. To Do, is it version 3 or 4 now? To Do is a lost cause in all of its present states. It doesn’t do anything unique from Schedule (which has been delegated to another developer at this time). I have some ideas, but they will require a lot of baking before they become a good GITI module. Doc is a healthy component. It has its standalone functions, as well as its integrated functionality. All of it works, sometime really well, but I think I need to document it a little more before I can let it be truly “complete”. It relies on the user having the ability to read and write in HTML, something which works great for me, but might be a little excessive for some people.
In general, GITI is healthy and functioning well. Even with one module complete, there are still plenty more that call to me (especially Health and Fitness for some reason).

Today I started a project I have been meaning to work on for years, a mobile version of GITI. I kept holding out, waiting for myself to learn how to write the application to not be Internet dependant, but for the most part, there is wireless access almost anywhere that I will need GITI. My iPAQ is the target platform for GITI Mobile.

So far I have completed the conversion of the login page, and the command evaluator. They are the foundations of GITI. In addition, I have modified one of my C# projects to be an effective simulator for the mobile device. With JavaScript off and the smaller window size, its a perfect representation (at least for the limited features GITI uses).

Since June 2003, when GITI was created, it has been an interface of seriousness and record keeping… last week I decided to deviate from that just a touch. I have added a few games to the interface using some games from Google Gadgets. I’m hoping to write some games of my own to put in GITI soon, but for now these interactive versions of PacMan, Tetris, Frogger, Invaders, Hangman and Mario are keeping me entertained.  Unfortunately, there is not yet a Google Gadget pong… or it would have been in there too.

P.S. No one make fun of my score… I was trying to get an interactive-looking screenshot and that isn’t easy with those things chasing you.

I think I have the solution to the GITI crisis.

1. GITI will register the special cases in its "fields" table

2. Education will follow the new v2 protocol for managing its own fields entries, allowing it to take over inserting records about institutions and maintaining information about them, including their grading system.

3. GITI will loose all "combined" GPA and "quality points" functions… since they aren’t really valid anyway.

4. All current GPA calculations will be modified to cause a database check for the existence of a grading scale, if found, it will be referenced  for all calculations, if not, the default grading scale will be used, and a further check will not be run for the situation.

5. All grade input screens will be modified to use the special systems in their lists… this will be done on an array to prevent the database from having to handle a query for each course on the record. As in #4, defaults will be used if no special case has been logged.

I really hate how GITI feels like i’m flying by the seat of my pants when shit like this comes up. I guess I have to work harder at expecting this type of thing.

All of this sounds good in theory at the moment, but I’m way too tired to code this fucker right now. 

GITI’s education module was written to be very simple, it understands standard letter grades (A, B, C, D, F) as well as a few other concepts (Pass [P], Incomplete [I]), but it doesn’t know how to deal with anything other than whole letters on a 4 point scale. Currently this is hard coded in GITI, and there is no flexible grading system stuff available. Perhaps this was short sighted when I originally wrote GITI. When I think about it, there are a lot of problems here, including the absence of understanding for "Credit By Exam" grades… those are currently handled as "Pass" with a note on the course’s record. Yet another area I have missed is "Satisfactory/Unsatisfactory" grading as might apply for a graduate program.

There are just too many grade systems to try to adapt for, so maybe on GITI’s next update I should bring in the ability to attach a grading system to each course using the fields module (which has handled way too few things lately). It would be cool to let the thing use a different scale attached to each school (but fall back to standard 4.0 when none is specified). I had a way not fun trip through the website for the UNC Registrar’s office the other day, finding stuff like graduate programs that use grades like H (High Pass), HP (Above Average), L (Low Pass). Each school at UNC has its own grading system. It would be impossible to interpret all of these possible systems and integrate them into GITI, so a per-school system input would be the only way to make this work.

When did it become so hard to just get an "A"?

I just hope I don’t have to figure out how to tell GITI how to handle the possibility of me getting an "A-" in Digital Photo.