Category: Programming

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.

The current active user-visible modules are as follows:

• Address Book
• *Administration
• #Email
• Cookbook
• Education
• Schedule (+v3)
• Footwear Collection
• Health
  • Exercise
  • Nutrition
  • Sexual Activity Log
• Library
• Journal
• Notepad
• Documents
• Software Keychain
• #ToDo
• ToDo List
• Inventory
• Site Engine Administration
• Project365
• Weather
• Home/System
  • Games
  • Time
  • About

In addition there are other modules that the users do not directly interact with that provide inter-module functionality:

• Item Journal
• Tags
• Quick Access
• *Fields

# = A module to be discontinued and hidden

* = Not truly a module, but part of the structure of GITI

In writing the previous post, I reviewed a few of my past posts about GITI, specifically the ones mentioning changes in approach or some type of concept for its development. A lot of concepts were out of my reach before, but now I feel more prepared to take on those things.

A module I have considered adding is ‘History’, which would essentially be a general log that may be contributed to by all modules to report on actives of the user. The log would include things in a short narrative of the activity, for example, it may say something like “Curtis completed Exam 4 in Behavior Modification on July 14, 2010 at 17:10”.  The idea would be that a user could look back over the records for the past day and determine what they have done.

In a similar intention as the ‘History’ module, I believe that it should be possible to interact with the interface in a journaling method. While some modules are for output to the user (education, schedule, todo list), there are some modules that are more input based (meal record, masturbation log, journal, status) and stay silent unless the user adds information. For that reason those modules that are for output do not normally appear on the main summary page for GITI, which limits their usability.

I am hoping to perform a systematic review of the state of all modules and examine how they are used during the v3 development process and somehow integrating them all in a meaningful way so that they can be as valuable as possible to the users (me and my alternate selves).

I have a lot of ideas involving social networking, but they are not things that I can take into account permanently in the interface because as far as I’m concerned, they are just a current fad and one day will fall. This does not deter me from wanting an “external services” module of some type that would perhaps do things like gather my Flickr stats or other pieces of information like that. One of the ideas behind GITI was to be more of a portal, something you set your browser’s home page to and that will help you get your session started with relevant information. I have to manage to do this without turning into a social network of one though. The modern APIs for many services make the portal idea more feasible.

Fields is an area that has been an absolute main in the ass since the day the idea for it was conceived. Fields is a convoluted collection of categories, custom items and other little things that tend to be user specific, and some that are system specific and some that are very general (in PHP, getting days of the week from a database is so very easy compared to other methods). Currently the management area for fields is pretty well hidden from the user, except for a small form that barely works. That form is the only way for the average user to interact with the fields, and as a result, most of the interaction I have with the fields system is done by connecting to the database server directly and making the changes manually. I’m glad GITI has no actual users. What I would like to do for this problem is for version 3, give the major modules the ability to edit their fields from within the module. I am thinking of a universal form, but something that each module would call to allow changing things specific to it, so that the user isn’t left entirely without context for what the field value applies to (I wrote a lot of my fields about 7 years ago, do you think I remember what they all mean?). The desire for the modules to handle their own fields has been around a while, as it was documented in GITI Ideal #4.

I mentioned above the Journal module being primarily an input module. This in itself is all well and good, except for the fact that the module comes across as intimidating. For such a simple module, that’s a bad thing. It seems like you should have a 500 word essay to write in the thing, when that’s not the way the module is designed. I want to refine this so its a more welcoming module. On the other side of things, its cousin, Item Journal, is integrated into a few modules and gives very little space, making the user feel like they can only put in tiny bits of data. This is a problem that really does not seem to have a correction for this version. I do however, think that item journal should be more present in other modules, and I do wish to work on that during the upgrade.

Doc is a very techie kind of module. It uses a standard HTML text area to accept the user’s document. The area has been carefully designed to appear exactly the same as a blank document in Word XP as far as columns and rows for a 1 page document. I want to move beyond that. I want to have better editing tools in the UI itself, even if the back end storage stays the same. Of course, it should be possible to suppress any advanced features so that it is possible to write a simple, clean text document.

In the previous post I made mention of a way to make things like social features easy to turn off or ignore, as part of the effort to consider that, I am implementing a new GITI Ideal:

Modularity of Service Functions (#7): GITI modules that utilize any data functionality to an outside service or module, beyond communication with its own database table must perform such functions in a segment of code stored in an external file from the primary module functionality.

Only July 20, 2005 the GITI v2 project was conceived and on was transitioned to on December 19, 2005, with conversions continuing until August 2006. A lot has changed in life and in the world since that release, and as a result, GITI is now ready for a new overhaul.

About the Development Process: Because of the way that GITI is structured, the interface itself does not get modified much during its normal lifecycle, it gets a bit of cleaning and polishing here and there, but for the most part, it doesn’t get touched. All development that happens while a major version is active is for the expansion and refinement of individual modules. The interface itself is merely a vehicle for the modules. Its less code and more concept. The development of a major version seems to be mostly a re-evaluation of the way the system operates and then running all of the modules back through being reworked to match the new goals (or the mysterious GITI “Ideals”).

For the 3rd generation of GITI my primary goal for the interface is to address the issue of module overcrowding. Currently there are a lot of modules and the number of them present is growing. It is very difficult to use the current menus to get to everything effectively. The next major goal is to implement some sort of security system, including the ability to generate users on request and have a default security context that is as safe as a playground. Another big thing for me is getting things to be more “socially capable”. Per-user settings for Twitter updates for more aspects of things would be cool, but I don’t want to write code that locks us into any specific social format, I want to write something that is extensible and terminable (if Facebook dies, the components for it should be easily neuter-able). The social component also includes the ability to do more things from a mobile method. I’m also hoping version 3 is the version that will carry a mobile-compatible version of GITI itself.

Here are some of my pet objectives.

• Better “interface”
  • Resolve module overcrowding
  • Better menus
  • Improve the “quick” menu item
    • better internal documentation
  • There should be less page changing for editing
  • Details from “summary” should not require a page change
• Security
  • Groups, permissions and all of that fun stuff
  • Ability to administer users
  • Key-auth for RSS clients (read only)
  • Capabilities for authenticating GITI users to external services
  • Establish a single, authoritive, domain name
• Documentation
  • Documentation in the code for later modification
  • Ability to keep documentation for modules in GITI, to be turned on my COMMAND at user request
  • Written protocol for how modules should behave in the context of the interface
• Module Specific Updates
  • New Module ‘ToDo List’ needs to be finished
  • Old Module ‘TODO’ needs to be exercised and destroyed
  • Schedule needs to accept invitations both ways
  • Schedule v3 needs to be completed (or is it started?)
  • Docs needs to have a better way for assigning where to store the ‘doc’
  • Reactivate ‘Inventory’, make is more universally usable
  • Library needs to be finished
• Mobile/Social
  • Expansion of the status theory for things like schedule items
  • Allow other modules to Tweet
  • Create a standard way for modules to speak to various social mediums
  • Investigate options for GITI mobile, as well as usefulness evaluation
  • Create a standard way for a module to send email notifications
• Public
  • Relevant modules should have an easy way to be sharable through GITI public
  • Public should take on at least a resemblance to the rest of the interface.
• Burry the dead
  • Unused modules need to go
  • Modules that haven’t been changed since v1 need to be updated or be dismissed

The version 3 update will not likely include anything as groundbreaking as GITI v2’s ‘COMMAND’ structure, but hopefully it will result in a more useful tool.