Getting It Together Interface version 2 (GITI v2) is now in an almost functional state. I have fully implemented the Education module on the v2 test site. A lot of the componentes are merely rigged together to function now, but that will be chaning soon. I have a lot of work still left to do, but the existing GITI modules are converting to v2 with minimal effort. I have moved away from the module-specific design of GITI v1 and moved toward activity-centric (add, view current, view all, etc). This should be make the navigation easier for the user as well as for administration and development.
The next step in the development of GITI v2 will be actually establishing the menus that will be attached to my cute little tab items. Once that goes into place there is nothing that GITI v2 can’t do that v1 can. This is where the project becomes a truely forked code base, once I transplant all modules and convert them they will start taking on characteristics of v2 and become farther from v1. I am having problems controlling myself on v1 when I do something really cool to v2, I feel like I need to do it to v1 also, but I have to remind myself that v1 is to be locked except for bug fixes and extending functionality where it is imperitive that such functionality exist. For example, if I write decent custom field value modification code, then I will connect it to v1 also, if it is compatible. I spend a lot of time on GITI as both an end user and a developer, mostly as an end-user. Because I am the #1 GITI user it is a lot of fun watching things in the GITI code break as I manipulate GITI. One huge difference in v1 and v2 is that v1 was the only GITI that existed during its development, there was no stable code, only the crap I was producing at the time. Since then GITI has grown and has become mature in v1. As I develop v2 I can spend a lot less time worrying about time management (an imaginary clock ticking, reminding me I need GITI running by X time), and more time developing high quality functional code.
My vision for GITI eventually is something like the borg queen, an all-knowing entity that makes everything make more sense and has a desire to get as much information as possible. One aspect of the borg queen that I don’t want in GITI is the lack of free will. The GITI user should have complete control of scheduling and be able to manipulate it as they like. GITI needs to be very reliable, but also allow for flexable scheduling and alterations in a user’s schedule.
The biggest pain with GITI will be the conversion and intergration of the Address Book Dastabase system. It was never desgined for a multi-user situation, especially not like GITI. The end-user portion of the utility WLL NOT be changing, it is how it is because thats how it is. The admin components will likely become less adminish and more of a split end user system. At the present time ABDB (Address Book DataBase) relies on the information in the database itself for authenticating users for updating their info. One thing that I have given thought to is integrating the addressbook table and the users table of GITI, having a single reposity for all information, and sort of making all users peers of each other. In doing this I would probably find it neccessary to have a seperate GITI contacts tool, which is sort of duplicate, but sort of not. At this point I just don’t know. There are so many aspects to explore for the module. GITI and ABDB work perfectly for me at the current time as they are because they are both designed to be focused on me and my needs. One thing is certain though, if I make ABDB become a multi-user tool I will have to make the username system a little better for it, so that more than one user can have the same real name as another. I know that if I didn’t then in the first week of GITI being accessible by more than just me we would run into John Smith syndrome.
Many more lines of GITI remain until I can rest…