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.