Category: Getting It Together Interface

I have been fighting myself on the topic of the GITI v1 to v2 migration for far too long now. I have three weeks in which I don’t have to do anything, and I think it is time for me to dedicate some time to finalizing the transistion and letting v1 go to rest permenantly (minus the administration functions, which will serve for v2 in the interim). I have been dragging out the conversion for way too long. I dont need to have v2 complete, I just have to get all of the modules assebled and as functional as they were in v1. So far I need to finish out education and schedule, then convert todo, notepad and email. Once those critical pieces are finalized, everything should be a go for packaging up GITI v1 permenantly.

GITI was designed as an idea on June 16, 2003. GITI’s primary objective was to be a place for me to keep up with things I do, hence the original module being the schedule module. Part of the idea of GITI is that I could be more social, keep track of my events and perhaps start feeling good about myself. The oringal plan was very simplistic and didn’t involve me working on GITI for more time that I am out being social. In addition to making me more social GITI was also supposed to keep me more organized, well… it met that goal without a problem. I have never been as together as I am now that I have GITI.
Now, GITI is a wall for me to hide behind, as long as there is something popping up in the summary view, then there is something to be done, an excuse for why I can’t do something social. In addition, there is never a sense of completion, or a sense that ive done something worthwhile that will make me feel better about myself, because everytime an assignment gets marked complete, another one comes up from the bottom of the list to take its place, which makes completing assignments seem like an infinite loop.
while (x>= 1)
{
worry = true;
x=x+1;
complete_assignment();
x = x -1;
}
the only way to get away from it is to have nothing left in the queue to do, but that has only happened like once in GITI’s history, and that was at the end of Spring semester this year. Every other time in its life, there has been something in it to do.
In short, I think GITI is beginning to slowly ruin my life.

It would appear that as long as a mistake in logic is consistent, then there is no real error. It would appear that I have been storing ID info for “time” journal entries incorrectly, I have been using all values of the date for them, but omittiing all leading zeros, hence, today is 2005916, not 20050916. Upon looking at the problem closer, I noticed that GITI is retrieving the entries using the same stupid mistake, so I guess as long as all is consistent, it doesn’t give a shit how far off it is… If this does become a problem though, im moving to a less problematic time system… perhaps seconds since Unix Epoch and getting info for an entire day using a range… or maybe Star Dates, at least they use decimals and not some multi-part orgy of numbers for identifying something so solitary as a day.

It finally happened, I am now to the point where I can’t stand GITI version 1. It is hard to navigate, a pain to develop for and lacks any form of logical structure. GITI Version 1 has been perfectly fine for me the entire time it has existed until now, and I think im falling in love with version 2’s ease of use and simple navigation. In addition, now that I have the ability to make GITI function uniformly, developing for it is a lot more fun (the “command” module). Version 1’s time is nearing an end. As soon as I have time I must convert all modules to version 2, especially now that v2 has its own modules (Library primarily). A lot of things from version 1 will be joining the Do-Do bird soon, this includes the “Journal” module, it is being replaced by only the “item journal” stuff, since I can treat a day as an object (funny how 20050915 resembles something like 0734 isn’t it?). GITI will remain under the Pythagorean system of organization (numbers, only numbers), so there is no problem with any of that. Another problem area is the concept of making GITI v2 multi-user. In version 1 of GITI, everyone is the same and everyone has access to all functions for their own accounts. This is all well and good for those of us who can ignore superfolous [movable type needs spellcheck] features, but for some users it is confusing. Currently for v2 I am experimenting with a group-driven system, which i plan to expand to group+user-specfic. Yesterday I added my mother to GITI as a member of the “librarians” group, so she has only access to menus specified for that group, which at the current time is Home and Library. I am a member of a group that I called “System”, im not sure why I called it that, but I should probably go back and call it “Full” or something equally non-confusing. At the current time all of the menus are done by client-side JavaScript using a SQL query. This works for group based stuff, but it wont work for group+user specific, unless I want all of the user-specific stuff at the end of the menu. I will probably end up using a standard array for this, so I can have the ability to sort a second time before thowing the information to the Javascript.
On my way home tonight I began considering the many options for replacing my main summary on GITI, which is highly restrictive currently. It isn’t the first time ive gotten ideas for ways to better use the space that is availible to me in v2. I like the ideas of utilizing columns instead of just a centered table with very little information. I have roughly 1024 pixels I can utilize for that page, why should I use just 500 in the middle of the page, and none anywhere else? Before GITI’s summary was called “summary” it was called “GITI Today”, indicating that it was supposed to cover roughly 1 day, maybe 2 at most I think. I have been feeling so overloaded with the stuff that GITI has been showing me, even though some of the stuff can be as far away as 15 days. I shouldn’t feel like my life and ability to do stuff is impeded by the fact that I have 5 things that must be done in the next 15 days. I have time, time for fun, time for whatever the hell I want between now and then. Either GITI must address every possible aspect of my life, or it must be configured to not make me feel like i have some sort of obligation all the time. Since I am not planning to write a module to handle every possible thing I might want to do in my life, then I must get GITI to chill out a bit. I am a very non-motivated and tend to try to stick to my obligations only, this is a very bad practice.

This morning I have made a decision about the development of GITI v2, I want it to be something that someone other than me would want to use, not that I expect anyone other than Guy to actually try to.
Version 2 – it looks so much less minute written out doesnt it? It should be. Version 2 of GITI is a major overhaul of the way GITI operates (thinks?). Everything is based on the command system now, which was originally developed as a way to lighten the work required for implementing navigation. One thing I have given consideration to is the way that everything just sort of flows together now in this version because of the implementation of the command system. I want to keep that fluidity and simplicity of design on the end-user side also. I have decided that GITI will no longer use static styles, an external style sheet will be broght in via the header document.
A few minutes ago I just really looked at version 2 for the first time, what started as a UI upgrade has turned into much more. The goal was to kill the framesets and move on to a more open space, well… that part is done, but it resulted in something unexpected, I now have space to play! I began noticing my newly found space a little while ago when I looked at the Add New page of the education module. That page doesn’t use a restriction on the table width like the other pages do, so it was just a wide document, then the new plan hit me. The next thing to go (after framesets), is visible tables. The document looks so much better without the need to be cramped, this gives me room to add a thing or two. One thing version 1 had been lacking in almost every aspect is the ability to do more than just add one item at a time and then return it to you. The complexity of the deprecated schedule module is an example of what can happen in GITI with a little imagination. The class schedule is automatically genereated for me when I enter the class information, I don’t have to propogate each day, or create an entry for every day of the semester, I just select the class days, choose the meeting times and submit it to GITI, everything else is taken care of. One thing about this particular module that is also very nice is that it doesn’t need to be given a database entry for every day that an event must occur, it is treated as a reoccuring event and GITI intelligently uses the information it has about the event to display it when appropriate and not when it isn’t. One more fine point which makes the schedule module an example of what GITI should be is the option to exclude days from a range of a reoccuring event without actually having to specify more than one range. Ain’t that cool? To the expert web developer/programmer this may seem like a trivial accomplishment, but because GITI is my first real project it pretty much thrills the hell out of me, and im proud of what it can do. Unforuntately, the other modules aren’t anywhere near that smart. The education module is about as close to as dumb as dirt as it can get, it cant even generate regularly scheduled assignments, a feature I have many times wished I had taken the time to write. I think a lot of this comes from the part where I actually need the education module functioning, but everything else is safe to let die. As I state that I must ask myself why I haven’t updated the To Do and Note modules, and even better… Why is Note and GITI Doc seperate? I should be able to combine the two and get GITI Doc to support independant documents that don’t need to be called from another module.
My simple modules remain simple, but they are too simple to be useful. In addition to their shortcomings, there is also the limit of usablity. What end user wants to write a date in the format 2005-09-01 when dating a note?

GITI is a pain in the ass to operate when I am not at home, this indicates that I rely too heavily on the admin side of things for it to work properly, consider revising.
The schedule tool is the paitient of ridicule today, I tried reactivating an invitation that I cancelled last night using the Interface, but it just isn’t possible. I am moving away from the raw unfiltered database lifestyle in the current stable (LOL!) version of GITI, so I actually have the chance for things to go hidden from me. I need to establish some sort of rules for how schedule should operate for ‘Once’ events (standard schedule), ‘Week’ events (events that repeat weekly for a period of time and ‘Invite’ events (not real events, invitations to an existing event, entered as a new event). There must be some uniformity and control to it. At the moment the project is about to fall on its ass because I have just been making notes about problems and not actually taking care of the problems.
I guess I should mention that I did finally get the invite moved back to its correct status (from CAN to NO), which in this case is a little weird, because originally that field was based upon whether or not an event was complete, but now NO = Accepted Invitation, YES = Completed event, CAN = Canceled. Its all a bit confuzzling (yes Guy, I stole your word!).

Today I for some reason decided I wanted to work on GITI v2 (maybe because I would like to use it in about 11 days), and I think I’ve finally decided upon a functionality. I am discovering tonight that I have learned a lot since GITI’s original creation, this includes about PHP, my usage and expectations of a personal information manager (PIM), as well as about GITI itself. That may sound strange, me learning about something I created, but its true. There are things I didn’t realize about why I did things the way I did at first, but now that I am diving back into the old code and looking it over again and trying to adapt it for v2, it is becoming much clearer to me. Tonight I managed to complete the transition to the database driven menu system (at least its core), now I just need to add all of the commands, and finally adapt all of the modules and their functions to use the new system. I think this will be a difficult task, but at the same time will make me more familiar with my own code. Hopefully along the way of correcting issues with the code that make it incompatible with v2 I might actually find time to structure the code so it makes sense. On my long-term plan is an intention to rewrite all of the v1 code so that it makes more sense.
I have been becoming very confused with GITI lately, there are so many new functions I want to add, then there is the burden of actually getting v2 100% running (burden for now, but once functional, im sure it will be more than worth it). I have given consideration to things like a ceramics module (keeping piece-by-piece info, firing schedules, etc) and even things as bizare as a mood-tracker that would affect a status indicator on my blog (dont know why anyone would ever need to know my moods?).
One of my main conceptual problems at the moment is the ability to access the course list. I can do it like I used to and it still be making it simpler, but I really want to take it a step beyond that. There is a side-bar that I haven’t used for anything yet in the class/education module that I could probably put a small class list in, as well as move the current “active class activities” include to. At the moment there is just so much going on in my mind with GITI as well as everything else, its getting hard to keep up with my thoughts.
The new journal module (previously itemjournal) is now fully functional and is coming in quite handy for those little notes, and thoughts that I need to throw down somewhere. In a way it is kind of like having a way to use digital post-it notes on a per-item basis. I don’t currently intend to transistion the old journal module to v2, it will die in v1, but I intend to convert all of the current content to the new module, then have the new module to take on the same name as the old module (for both its file as well as its table).
why am i going into so much detail here? its not like any of you are GITI developers or even care what I do with GITI, although I know what some of you wish for me to do with GITI.

Tonight while playing with MovableType (my primary blog engine/publishing platform) I realized something kind of interesting, without much effort or technical screwing, MT manages to allow fairly intelligent editing of a document. Months ago when I was creating some features in GITI’s background (creating them, sort of, but not linking them) I created a module called “GITI Doc”, which for now will take plain text (including HTML) and strip out things like carriage returns, tabs, etc and replace them with the appropriate code. This allows for direct copying from a word proccessor application. While this is useful for document storage, it doesn’t do much for document creation. I think it would be kind of cool to actually have GITI Doc to be able to do basic document editing things and eliminate the need for sending files back to my server when I am working on documents on systems that don’t belong to me (such as the UNCC labs). One possible solution to the problem itself is for me to always have one of my systems with me, another would be to have GITI or something else web-based that is already on my server for that task.
One concern that I have is that this type of thing already exists, in the form of “publishing tools”, such as MT, and Wiki sites. I don’t want to have to end up recoding something that someone else has already written, it would be kinda nice to find something that is fairly simple and already written and just integrate it with GITI (without mixing code). Another concern of writing it myself is that I won’t be able to create all of the functionality I want. I think it would be kind of cool to be able to have my documents have a table of contents (based on anchor names) created from the paragraphs. That is something that is more Wiki-like I believe. The third concern stems from one of my desired results of this utility. I would like to be able to publish my documents automatically to my website (once it is finished), but at the same time I look at all of my old papers and things and I realize that I really think badly of my own work, so once this thing would be completed, that part would still be 100% irrelavant.
I guess that brings me to something else… I really want to make a lot more stuff in GITI be availible publicly. One of the things I have been wanting to experiment with is having my schedule for each day availible via the web. Maybe not the detailed version, but a marking of availible/unavailible for most things, or like “In Class” when I am scheduled to have class time. All of the logic for most of these ideas already exist in GITI’s private parts.

My pet project GITI is back under the knife again, but I haven’t really let anyone in on the details of whats been happening, so here we go:
1. GITI now has the capacity to facilitate 1-way invitations to schedule events. I hope to add an outside functionality for people who know me to be able to file an appoinement/schedule request to request a slot on my calendar. In concept this seems like it will be easy, and I suspect it will be, same form, new method for submitting.
2. Invite contacts to existing event. this is a new feature that was created after seeing how simple it was to complete. This feature works on the backend, but I am still working on the details for the front-end and user interface parts.
3. System-wide journaling. This needs a lot of work, especially where the journals may become a little long, but I know have the capability to add journal information to each and every item in GITI. This seems a little odd on the surface, but it really helps with remembering what happened when and being able to get thoughts together, especially on items that are academicly linked.
4. Modules that are inactive DO NOT appear on GITI Summary anymore. I finally got sick of seeing empty boxes saying “no ____ to complete”, so now the unused little shits aren’t appearing. Because of this change I am also considering something else, which I will mention below.
ok, now that ive blabbed about what ive done, now its time to go into my plans for GITI’s future:
1. GITI Command – think like a small text box, at the base of the GITI v1 menu bar, or at the bottom corner of the footer include for v2. This functionality will take advantage of my over-anal addressing scheme that resembles an object-oriented programming structure. I intend to have the box read GITI addresses, and pass them through a SELECT/CASE structure. Im thinking about making it a double-pass possibility, so that I could use full GITI addresses (root.giti.schedule.add) if I want, or I can pass only the local address (schedule.add) and have it to ammend the interface address, so it comes out like this: “root.giti” + “$command”, where $command == “schedule.add” and the whole command comes back as $command = “root.giti.schedule.add”, which would equate to a valid case. Another thing I thought about for v2 is the ability to have it to know what module it is in, so I could be on a schedule page (lets say “schedule.view”) and have it to accept the command “add”, so then $command = “root.giti.$module.$command” or “root.giti.schedule.add”.
2. New GITI v2 navigation concept. I am having an extreamly difficult time keeping things straight in the v2 menu now that I am driving it from the GITI database. One thing I have given thought to is using the above mentioned GITI Command functionality to propel navigation, since all of the tables already include info for the GITI addressing structure. This will be a very firm step towards GITI becoming modular.
3. Change GITI’s menu ownership from ‘system’ to $user – this will ultimately result in a great flexibility in being able to ignore unused modules or turn others on at will. While this will require a slightly higher number of entries in the database, it will in the end make the thing more flexible. With the way I am conservatively writing GITI you would think I was working with a system with 2MB of RAM or so. Keep in mind, GITI still uses under 1MB of database storage, a very tiny database. The server and technology are capable of much more than I throw at them.
4. Modernize Schedule and Todo! – A lot of the new stuff for Schedule had already been written, I just haven’t implemented it, because im waiting to retire the old forms and things, and create them as GITI module files instead of as independant functionality files.
5. Rewrite GITI EMail functionality (this is unlikely to happen) – the GITI email stuff currently will log me into SquirrelMail in an insecure method, not very impressive, and I can also send email from a fairly featureless text-box composition form. This module needs to either be killed or majorly overwritten.
I think I might post some new screenshots soon, now that things work better. At some point I should probably remember to un-neuter v2 (put its scripts that do stuff back in place) so I can test it fully.