Category: Getting It Together Interface

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…

“Welcome to The Interface”
“Good Evening, Curtis. Today is Saturday, September 18, 2004”
It took so many lines of code and so much time coding to get those 2 lines to show up exactly like I wanted. That was over a year ago, when GITI was still under primary development. GITI PIM – Gettting It Together Interface Personal Information Manager has been a primary project of mine since the joint completion of Address Book Database utility in Spring 2003. In my quest to learn PHP I started the project. It is now one of my most prided accomplishments, but I find that its needs are quickly outgrowing its current limitations as well as my developmental knowledge. GITI v2 was esablished a few days ago in its own little development space. So far its design is becoming more complex, but at the same time more limiting as far as GITI module inclusion. Im going with the file drawer approach with little tabs used for navigation, there is potential for more than 1 row of tabs, but moving to 3 rows would be pushing asthetic design rules I impose on myself.
For GITI v2 I invision a smooth design with all menu options availible from all pages via a hover menu. Catagories (or Classes for EDU module) should be located on the side of the page where they can be easily accessed when needed. GITI will have to become a lot more user customizable (for additional users as well as for my own convienience). Because of the reinvention of GITI I will be able to fully utilize CSS and make GITI able to have themes. This could be really cool for holidays and stuff.
In additional to the layout changes I have some proposed modules that could be added: Shipment status (via XML manifests availible from shippers), Recipe Manager (per my mother’s request), Wardrobe Inventory (this one might not make it if the usefulness isn’t there), Bookmarks, and a re-write of Journal. One of the things I have considered is having the ability to link all items between modules if needed. This would be most helpful between Schedule and Journal I believe. I theorize that based on the concept that GITI keeps a running record of your life, so why not let it also keep your narratives about it stored in relation to scheduled events in your life?
After I started working on the screen shots for my last post (which are still availible at http://curtis.kularski.net/GITI) I determined that GITI is a very good record keeping system for knowing all of my past events and other things. I didn’t think of it that way when I originally created it and as such doesn’t have nearly as many datestamps in it as it should. I think with version 2 I will have a lot more notations and transaction tracking. I am sort of inspired by IETF’s Internet Draft Status tracker for that aspect. Every major action that occurs with a document that is submitted for the RFC Editor is logged. This could be a nice system for tracking the status of different types of records in GITI. Recipes in the theoretical recipe module obviously wouldnt need it, but ToDos and schedule items could use that ability. A lot of the statuses themselves were written to be binary values, but through much experience with GITI I have determined that statuses can’t be Yes, No or On, Off. There are a lot of in-betweens. More In-Progress things would probably be helpful.
In preparing for this redesign of GITI I am learning a lot more about practical coding than I ever thought I would. I will be posting more screen shots of GITI as it nears being ready for active use in v2.
I guess I will be off to my world of writing GITI for now…