Category: Getting It Together Interface

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.

If you are sick of hearing about me talk about GITI and her problems, upgrades, etc, feel free to skip this entry (unless you are Chris, in which case, boyfriend, your help is required).

I am having problems with GITI, but not on the level of things technologically working or not working, it’s more a matter of things not being philosophically right with it. It is one thing to record academic assignments in a fairly plan way, that’s all there is to it, you enter an assignment, do the assignment, then enter a grade for it. No big deal, no crisis, everything is self contained. Now, this philosophy does not hold for components of the Health module. Logging meal records and workout records that way is good for record keeping sake, but it is lacking for usefulness in life improvement. The masturbation log is probably ok as is, not much to it beyond a journal entry. My primary concern with these things is that GITI is not being as useful as it could be. A select box of exercises is fine for the most part, but it is lacking in depth. I find myself wishing I could have GITI describe the workout to me, or better yet, give me a description with a picture. This of course would require me being able to supply the information to GITI, but that shouldn’t be a problem. As it is now, I have no ability to add such information, mostly because of the limited nature of fields, but how much do we want to expand fields. Is there a use in other modules for that particular functionality? I think there could be. Category icons could be useful, and would certainly be something that might be welcome in GITI v3. As for the meal log, it is difficult to access and utilize. There is no clear way to retrieve data from it, other than entering a date by hand and that is not very user friendly. I know that GITI doesn’t have access to a huge nutritional database, but it would be nice if something simple could be added, but looking at the module, I do not know where such a function would be placed. I find myself looking at other modules and thinking that their functions are so simple, most have the functions of insert, update, view, and when we are lucky, delete. They do not tend to contain more than one major type of data, which in my opinion makes them less useful than they could be (with the exception of Education, that monster is self contained and everything makes sense in data structure land, just not in the UI).

A few days ago when preparing a user account and also when packing up GITI for a theoretical off-site implementation, I realized how little GITI actually does. Without user data GITI is a cold, barren place. It doesn’t even look like itself without user data. Perhaps having more information available in GITI would be useful. Obviously information that would have to be licensed would be out of the question, but yet, simple things that are fairly common knowledge (or can be easily obtained from Wikipedia) may be useful. Why should a user have to leave the site to figure out what a particular exercise is? At the moment there is no construct in GITI to allow for The Interface itself to have such information, all information is owned by the end users, and areas where System could own data for such purposes are not elaborate enough to handle the ideas I have. I suppose GITI Doc could handle a great deal of it, but it is still limited and is not secured for any type of inter-user sharing or anything like that, hence, System Docs would not be safe from end-user edits, which makes me uneasy.

Any time I think I have finished in some major way with GITI my life changes in such a way as I have to either add a module, or bring back to life a module from my past which had long since been forgotten (I know it’s been a long time when it still tries to access the common data commands, oh how GITI v1 can we get). I am not looking to overhaul GITI, I just need to figure out how to add a little more information and make GITI a little more useful.

It seems like too often I have to question GITI in some way. Sometimes it is in the form of the amount of time I have to spend directly modifying the database, other times it is in the lack of a coherent user experience. The most recent situation of this was this morning when several times while working out I had to go into the database to add new entries for exercises that were not yet in the ‘fields’ table. If I were a normal end user I would be basically screwed in that situation since there isn’t an “other” and the health_exercise module uses only “system” fields, it does not allow for the end user to extend what is available. Why not? I do not know, it just was never considered, I guess as a result of me reacting to other modules that use user-level fields that are really inconvenient. I have found that in general the system level fields are more useful and tend to be less user intrusive, since it forces an administrative decision on what the fields should contain, but in the end it comes out show GITI to be a little inflexible in some areas. In almost no area of GITI do I use any type of coherent shared fields… a set of base values specified by an administrator and then a set of additional user values that can apply to the same field. Also, it is an ideal of GITI for each module to control its own fields when they are needed, this hasn’t gone so well in implementation as I have yet to write a single bit of code to allow a user to add an assignment type to the assignment addition area write in the education module, or about 1000 other annoying little spots where such functionality would be really cool. Now I find myself with a decision to make. GITI needs consistent fields, and of course with its requirement of minimizing waste, it must keep user information redundancy to a minimum. Which would work better: users able to add values to fields for themselves (in addition to system values), or a way for users to propose system values? Maybe the answer is in both, but that gets complicated, as it would require allowing users to add values themselves and then recommend for system wide usage, at which point the user would lose access to modify the value they created. I want consistency and extensibility, but there is so much to consider. There have been no procedures specified until now to handle more than 2 or 3 users on GITI, but if I want to get feedback and learn how to make GITI better, I am going to have to prepare it for more than the number of users in my comfort zone. There simply is no precedent in GITI’s history for the type of things I am wanting to accomplish.

Related Links:

http://www.pcfire.net/giti/ideals/ – The GITI Ideals

I am once again attempting to build GITI as an application, this time with more seriousness than my previous attempts. The problem I am running into is that I am discouraged from developing it in C# because there is already a fully build PHP version that works pretty well. The PHP version is HUGE compared to things I can easily do in C#. This makes the desire to move to an application base less than the desire to continue development in PHP, even though I know that I need something on the desktop side to compliment the web based version.

In web land it is incredibly simple to make everything very specific because the user is always on a different page, but on a desktop application the same user interface is used for most things (otherwise, it becomes a mess), so things have to be general. So far I am working with this by having a basic class for “GITIObject” and then I extend it with things like “ClassObject” and “AssignmentObject”, but I am still having a hard time, because things are so different. What I have learned so far today is that GITI has two distinct classes of items it handles. The first class is in the way of education assignments, schedule items and todo items, collectively they could be called “Activity Items”. Next there are the things like keys for software, address book contacts, recipes and such, those are “Data Items”, things that don’t change state and do not need to be brought to the user’s attention unless they are asked for.

At the moment I am attempting to work with all of those items using a GITI application, and just with the Activity Items by using a smaller application I am working on, called “GITI Notify”, which is basically a glorified listbox that updates with information from GITI about current assignments and schedule items.

One day, GITI will work on desktops and the web.

What is the big deal about tags? You can tag photos, you can tag blog entries, and you can even tag your bookmarks. What is the point of tagging?

I have just written the tag code for GITI. It is universal code that can be used by all modules for interacting with the GITI Tags table. Presently it is implemented by the Cookbook module in two forms. I am implementing it for “standard” recipe tags, as well as “meal tags” for associating recipes with meals or days. It is presently a very simplistic implementation, but from what I can tell, tags are very simple. I think this works for now, but I am trying to remember why I added the ability to tag these things.

GITI’s biggest problem as far as development and module completion is my inability to create an effective and useful UI. I can’t see in my head how things should look and outside of the first few modules I don’t really know how I would really want to present things anyway.

Cookbook is the present module that is being created. The first few ideas for the module called for something very similar to the way the other modules presently look, with an intention to change the look later. The problems are that the module ends up looking very empty when implemented that way and also, I have a habit of giving modules my intentions and then not remembering to go back and complete what I intended (see about 4 attempts at ToDo and Schedule). I am having a hard time with cookbook because I am making it more graphical and I have many ideas for what I want to see in it, but those things are not as simple to create as the things that I have done many times on other modules. This module is different because it has to be both a GITI module and a useful individual app, and I am also trying to make sure that things I create are not too hard to port into a desktop application as well (if for no other reason, then just to defeat the cloud concept).

Upon a user request, in GITI Education, Time is now a relevant field for assignments. Basic time support has now been added to the Add, Edit, and View single assignment pages. With this update to the Education module also comes a change of intention for the “Date Assigned” and “Time Assigned” fields. The field labels now express the intention of taking on the earliest date the assignment will be available, and not necessarily recording the actual date the assignment was created.

The batch add system will receive the functionality after implementation options are considered, especially with regard to the programmatic assigning of times to a batch of assignments. The batch edit system will receive the functionality as soon as the batch edit code itself is written.

• Summary now utilizes the “Time Due” field when sorting the assignments that are due in the current context
• Overdue assignment notices do not presently consider Time
• Summary will now only show assignments with “Date Assigned” dates that are ‘yesterday’ and before

I finally got the base code written so now it is possible to:

• Add recipes
• Search by title
• List categories
• See recipes by category
• View recipes

I still have to do the following:

• Add “Edit Recipe” functionality
• Add “Ingredient search”
• Refine interface
• Create side toolbar

It is still very basic, but it does work 🙂 The biggest thing is going to be to make the interface not look ugly. That will take many hours to get right.