A major assignment might look something like this with its components in place:
The individual assignments themselves are barely different from a stand-alone assignment (as they should be), except that they point to the larger assignment. For now the reference to the major assignment is by number, but I intend to use a database query to retrieve the assignment name in the future.
This morning I decided that today is the day to begin working in GITI again, primarily adding functionality that I feel will be crucial to the structure of graduate school work. The feature I intend to add is assignment dependency, which essentially means that major assignments could be broken down into smaller assignments that could have independent due dates and assignment information.
The first thing I decided was that for initial UI I would use only existing GITI pages, and not create a new workflow of any type, given the impending implementation of v3’s framework. The existing pages in GITI that would be used are the basic assignment edit and assignment view pages. The pages would simply receive new queries to handle the change. Starting this process I discovered something I had forgotten… the edit page is absolute crap. The edit page received no major help after being moved to v2, it still retains a lot of v1’s style, especially the gross overuse of the plain text field…. even though those fields now get translated before going to the database. One of the least sensible things about the form itself is the way that files are handled. The field implies it takes multiple files… it doesn’t, but the overall file record system does, so its one of those things where the user interface is awful for a feature that isn’t so bad (it tracks filenames for assignments, increasing the efficiency of organization).
Surprisingly, that complicated input comes with a pretty clean-looking output:
In this particular example, the fields that aren’t used are simply not displayed, but for the edit form, that simplistic approach doesn’t work, since GITI isn’t psychic and does not know what the user needs.
I am going to have to clean things up if they are going to make any sense to the overall workflow of an assignment in GITI.
I’ve been putting off the upgrade to GITI v3 for a while now. Chris has written an absolutely beautiful background framework upon which I can build the new version of GITI, but unfortunately, things just haven’t been clicking with me. I was talking with Chris last night about the end of the semester (which only differs slightly from the end of the known universe), and it was discussed that perhaps GITI needs a few updates for handling the complexities of graduate school work, and perhaps I need something to do to keep myself occupied in the awkward gap between academic activities (I think most people call it “Summer break”). So, a plan has been devised.
I am not quite ready to move on to version 3 of GITI, it is simply too hard and there is no motivation to do so as long as v2 works fine. Last night I just happened to recall that v2 didn’t just poof into existence, it happened as a gradual transition. Sure, I had the new v2 interface ready and had already given thought to the way it would work, but it didn’t really get off the ground by cold-converting modules. GITI v2 came into being as a very slow migration from v1, in a little phase I referred to last night as GITI 1.5. I barely remembered it because it was short lived. It was just the process of getting used to calling commands and not files (utilizing the, at the time, new interface table). At some point in there, I also dabbled in dynamic menu generation. Switching from static menus and static links is really no different than switching from manual database calls to a database-driven framework. The entire process is aimed at making the modules easier to use and maintain, and to speed up the implementation of new modules.
The motivating factor for leaving v1 behind was simply productivity. There was no room to move anymore and the only options for additional menu items was to add new pages. It was also determined that the old system didn’t allow for working between modules very well, resulting in an overall slow experience. Frames just didn’t work. My motivations for moving to v3 aren’t as significant. I feel that I need to move so that some of the older code can be weeded out and so that some of the inconsistent behaviors of the modules can be resolved into a unified process. I learned things while writing v2 that made its newer modules better than the old, and while I’m sure that the same will happen to v3, it will be nice to at least start with all of the new functionality implemented from the beginning.
One issue I didn’t have for v2, but have for v3 is Chris. Chris is difficult when it comes to programing. I cannot get away with some of my sloppy short-cuts and so much has to be discussed with him as a result of his vision for v3 (as the creator of the framework, he has the right to have his ideal methods considered). The biggest issue I’ve had so far with him is in the use of “cross-module” modules, or as I like to think of them “system modules”. These are modules that have functions across GITI, but may or may not have a purpose of their own. My favorite of these is ItemJournal. It has its own interface and its own data, but it also has a cross-module component that allows other modules to call it for the purposes of storing relevant data. I consider it to be indispensible. Chris considers it to be clutter. This also goes back to some of his concerns over data ownership and “where things are stored”. Things like the ‘fields’ table is horrendous for this, since it stores everything from constants for days of the week, to information about a user’s preference for what modules appear on the welcome screen. It is just a heaping mess. Maybe its what works, maybe it isn’t. Its an issue that has to be discussed and battled on.
No matter what the issues, on April 30th I’m going to give v3’s conversion a shot. I’m going to start work in v2 to prepare the existing modules for moving to v3, and perhaps get a chance to utilize the new database structure that has been written for some of the modules. It is a complete pain in the ass to re-write my queries with a new table structure in mind, but I think module-by-module, it will be doable. With all of this considered, I should be done with v3 shortly before I have to utilize GITI Doc v3 to write my doctoral dissertation.
Ever since I met Sarah Scott at UNC-Charlotte, I have had to consider the option of a situation where an assignment entered into GITI might not work out exactly as planned, and then the “Instructor Hold” status was born. Internally the status was originally called “scott” (valid codes were “yes”, “no”, “drop”, “inc” and “scott”). Originally the code had to be implemented in short order, due to the time constraints of being in the middle of the semester when realizing that sometimes assignments would end up in an unknown state because of instructor error or oversight. Most often the hold occurs when an assignment comes to its due date and either a rubric has not been issued or there is some other limitation to completing the assignment. In these cases the instructor is the only one who can really provide a resolution (either by giving a new date, or my dropping the assignment). The way that statuses are implemented is a really bad hold-over from GITI v1. First of all, the field is really called “complete”. I suppose originally it was a binary field that expected to know if the assignment had been finished. Over time it grew to have other meanings, including to accept the idea of dropping assignments from grade calculation. The second issue is simply the fact that “hold” and “drop” do not effectively relate the status of the assignment, they are supplemental information not related to the completeness of the assignment. Also, GITI does not presently recognize the idea of an assignment in-progress (something as a grad student I will likely appreciate).
I am considering reworking the entire assignment-control system and making it better at handling a student’s needs. I will correct the issues stated above, including adding the ability to enter an assignment, have it marked as “complete”, but also allow it to be dropped from the grade matrix. I will also implement the “Instructor Hold” properly, including prompting the student for the reason for the hold. Finally, the system was NEVER designed for the types of assignments thrown at it. It was originally designed for “homework” (as its table name in the database proclaims), so short-term assignments. The idea was to enter assignments from school and have the electronic record at home. To greater support other assignment types I intend to add the ability to set up time requirements on the items. Assignments that might not be due for another week, but have a greater time requirement (papers, projects, study for tests), would appear before assignments that are due on the same day, or perhaps even earlier, in the list. This would allow for the budgeting of time for the assignments until such time as a GITI’s schedule utility can be fully integrated to with other modules to assist in scheduling discreet blocks of time to work on the assignments.
As I approach the end of GITI’s useful life for me (for education anyway), I am seeing a lot of things that need to be done to make it useful for other people who may use it in the future. I used to spend my summers and breaks working on code for GITI, making it better for the future semester, but that hasn’t happened in the last year and I fear that the overall success of GITI is in jeopardy because of it (for GITI, success = being able to be used by someone other than the creator).
So far in this course I have 2 grades, an autobiography discussion post and an extra credit assignment which involved replying to the instructor’s message. GITI’s calculation of such grades is a bit imprecise. If 100 is an A+, and 92 is an A, what is 600? In this particular course the grading is based on a points rubric, something that GITI doesn’t quite have a grasp on. GITI does better at a weighted course, where it will provide the final average in this situation as only 105%, not 600%. For a points based system the correct score at the moment should be something like 6%, also not 600%. GITI currently interprets points-based courses as being only out of their existing, scored material, to help correctly construct an average for a class, which assists in determining outcomes. Being told that 6% of a course’s points have been obtained is rather clumsy. GITI has operated its points-based system this way since it was created (and for 2 years it only supported points).
I suppose the proper course of action is to list the amount of points that have been earned as well as the present average based on work completed. Ah, more coding work for the weekend.
I have never been one for much security when it comes to my technology. I like to keep my network secure, but I’m not one to necessarily have a lot of different passwords or use things like virus scanners or firewalls (outside of a firewall router). This makes me a not very good person for doing things like figuring out how the access rights side of GITI will operate when considering external uses of data via the SecretKey system. At this time there is exactly one SecretKey application, and it isn’t even really part of GITI, it is an adjacent application under the pcfire.net domain that just happens to have the same users as GITI, and therefore can use the SecretKey system without using the whole GITI login routine. In addition, I wanted the application to be something that could be accessed without having to be greeted with a credentials prompt every time it is accessed. I’m told that allowing a page to be accessed with a plain text password is bad, as it compromises everything, so I’m using the keys.
My concern now turns to the aspect of key security. Is one key good enough? Basically the way things work now is that each user is issued a key and with that key they can theoretically access limited GITI resources. The key is supposed to be used in a condition where the data is not sensitive and where things are read-only. For the current implantation there is a non-sensitive use where the data is pretty much one-way. There is only an input, not a modify, and thus no records to corrupt. Of course I log the IP addresses used for access so in the event of a problem it is possible to drop rows from the database made from any IP address not owned by the owner of the account. This being said, if the key is compromised, it is easy enough to have GITI to reset (“roll”) the key, but then all other services that use the key must be updated. I find myself wondering if each service should be able to be assigned a GITI key independently. Currently Google assigns a unique API key to each service that it “authorizes”, but it is a standard OpenID implementation, so I’m not sure how much stock I put in that process. It does seem rational though, to be able to use multiple keys and cancel them at will. I have considered using a different key for each service, allowing the user to issue however many keys they want or just leaving it as is, with each user having one key. Oh so much to consider.
I have many times in my past thought of starting a personal journal. I started at first a long time ago with a paper journal, and considered keeping a word processing document, but nothing ever seemed to work for me. In August 2004 with the opening of this blog I got a little closer to being able to do what I wanted to do, at least on the external perspective. I still do not have anything personal. I tried to do it in GITI for a personal way, but I just could never remember to write stuff and it just didn’t quite seem as together and coherent as I would like. I am now considering writing a software that will reside on a desktop computer, but will be able to write information somewhere that GITI can access it. The reason I feel I need to write my own software for this is that I want to keep more information in a journal than just a daily narrative and other plain text information. I want to be able to store sample photos from the day, and maybe a tracklog and other information that seems relevant to the events of the day. In some ways it would be nice to form my daily journal entries from a variety of little pieces of information and just have them grouped by the date. Those pieces include:
In some ways social media stuff handles a lot of this, except for the more private aspects, but I do not want something like a journal stuck in the cloud. I want control of the information and I do not want to be bound to some type of information system that can loose data, change control or in some other way be subverted by an outside force. This is probably crazy and excessive, but it will give me something to work on in my spare time.
I have been thinking about my “status” architecture for GITI. At present I can tell GITI my status directly, through the UI, or by sending it an email (must be done from my phone at this time, as it only accepts 1 address). GITI will in turn post to Twitter, which Facebook picks up on. I was just thinking the other day that it seems that this practice may have become quickly outdated. While being totally out of contact I post status updates by emailing GITI, what about when I don’t have my phone close, but I am near somewhere with WiFi and have the iPod with me? It would make most sense to open the Twitter app on the device and post my status there, and let it be disseminated out, but what about GITI? What happens to GITI’s records? They are forgotten and so is any web app that uses my status from GITI. Perhaps the key here is to let GITI check Twitter and sync my statuses for me.
Sometimes I get distracted, so distracted in fact that I forget to do things that one might consider important, especially when writing code. It would seem that about a year ago when I wrote code for adding batches of assignments to GITI I thought far enough ahead to add a “batch stamp” to the assignment records so that assignments added together could be traced together. The failing here is that when I remembered to write the code to make the stamp I failed to remember to write the proper code to actually use the stamp for anything in the UI itself. Chris accidentally added a batch of assignments to the wrong course (nothing wrong with it, I did it at least 5 times when I first started using the batch add system), and short of checking all of their little boxes on the pending assignment page and doing a bulk change there is no good way to assign them to a different course (and at this moment, I try to recall if it will change the course serial number or just the course code on the assignment). So, oops… I forgot to write the code to call back a batch of assignments. I guess I add that to my list of bugs to workout as Education crosses over to the v3 platform.
So far not a lot has been done on GITI v3. Chris has taken charge of the new back-end, most notably, giving me a sane framework to work from. It’s like having a really stripped down version of .NET, except it runs on PHP (so far it handles my database calls a lot more efficiently). I have not yet picked a menu system or even decided exactly what v3 will look like. Many of my readers will likely recall a lot of the really goofy early designs for v2. So far I’m not doing any better than that for v3 and honestly, I was hoping for some of Chris’ brilliance to pop out in the form of a really cool menu system. Guess I’m just going to have to locate one that can be modified to work in GITI.
Anyway, the point of this post isn’t the GITI problems, its to point out the readiness status of modules for the new version.
Education – first module to be added to v2 and will be the first module I try to convert for v3 as well. Without it, GITI just isn’t GITI. It should be easy enough to audit the code and make it compatible with v3 and just bring it over for the most part. There are some additions that need to be made such as making it support the idea of multiple academic careers. As I am planning to soon be a graduate student, this addition means a lot to me.
Schedule – I think at this point its safe to call this module “trouble”. I believe the intention for this module is to rewrite it before moving it into v3. This is the type of rewrite that involves throwing out the book and starting from a new concept. The module is severely limited in what it does and in many ways is too one dimensional.
ToDo List – v3 will be the demise of the traditional TODO module that was nothing more than a glorified notepad with dates attached. The ToDo List module is in its infancy in v2, but should be easy enough to mature into a functioning module for version 3. Chris has taken a liking to this module, mostly because he wants to have the ability to assign todo items across users. I suspect I will regret letting him take on that module as it will give him much power over how that works, but I’m willing to see what he does with it.
Footwear Collection – This module is mostly feature complete in itself. There are a few tweaks that need to be made, but otherwise the module is good to upgrade and transfer. Not shocked, its Chris’ module.
Status – I really want to see this module develop more, so I will be working on it before it is scheduled to be moved. I like the general function of it, but I want to see more power from it. I want more ways to be able to update my status when away from the Interface, and I want tagging ability to have discretion over destinations, in some ways I want to be able to utilize it a bit as a journal, say if an update is tagged as #PVT. It would also be cool to make something more robust as far as management, perhaps the ability to cancel a status by sending a follow up message to the system commanding it to remove the previous entry.
Library – this is the abandoned wasteland of GITI. I often fail to remember to enter things in it and in general do not find it useful. If I did not believe it was possible to have it be useful, I would likely remove the module, but I see it as having potential and having a purpose. I will be working on expanding the module to be more useful to all of its users. I have been promising some people a better version of library for a while now. I also have to make sure that I include some type of adaptive CSV or plain text bulk input, as some users have other lists which need to be converted to the GITI Library system. A lot of users could benefit from check-in/check-out functionality, which I seem to have misplaced since the old code.
Cookbook – This module will be moved to v3 almost as it is now. Its not complete, but its complete enough to be fully functional. The module will eventually improved, but it is a low priority in the v3 upgrade.
Journal, Address Book, Keychain – These three are pretty much feature complete and other than an update for their current level of usefulness they are ready to be upgraded. Keychain is likely to receive an additional feature set upgrade and application counterpart soon after v3 is completed.
System Modules: Item Journal, Tags – Item Journal al is called upon by numerous modules and thus, it is important that it is ready. Tags was nothing more than experimental in GITI v2, having no real use or purpose, but some GITI items did receive tags. My plan is to ask Chris to work with me on integrating these two modules into the framework in some way, perhaps as part of his grand plan for things to allow all modules to call them with minimal difficulty.
I originally wanted to have things at least partially functional by 10 days from now, in time for the new semester, but things have gotten behind and will likely have to be worked on throughout the semester. If its great and ready by Christmas I will be happier than if its rushed and kind of lame and works by convocation.
