Recently in Getting It Together Interface Category

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.

* Not my module

I now understand why I have had to rework the menus lately, more modules than there is space, plus there has to be space for the independent constructs.

We’ve all seen a cookbook and there are tons of web-based as well as desktop applications for cookbooks as well. So why would I want to write my own for GITI? First of all, because its GITI, it is MY Personal Information Manager. Second, I like things a little more  custom to the application of things than some of the other apps are. I do not need shopping lists and things generated (at this point anyway, and if I do later, that will probably be coordinated with the Inventory module). The third reason is because there is a lot of integration I can see for this. From just being able to store and retrieve single recipes to being able to assign “tags” to recipes to make them part of a master meal plan, it can all be used across multiple modules. Finally, if I write the code, then I know how the data is assembled and I can more quickly build web apps that use the information or even write an app in C# that can use the information.

The major origin of this entire project is my recent growing collection of recipes I am keeping in a 3-ring binder. Most are from Cooks.com or other similar sources, but some are recipes that I have written. I do not like having my recipes stored in physical form, it limits my access to them as well as makes it more difficult to get another copy if I get something on the physical pages. I will probably still keep my physical copies in a notebook, since I tend to be a little messy when cooking (especially baking).

The planned functions for GITI Cookbook are:

• Recipe Storage
• Search by name
• Search by ingredient (perhaps even multiple)
• Servings adjustment for recipe output
• Nutrition export directly to GITI Health
• Date/Event Tagging
• Image of food (when available) via GITI Assets
• Notes about the recipes (alternate ingredients, etc)

One of GITI’s least developed features is called “Quick Key”. Basically, it is a shortcut system for GITI. Type your command in the box (a “key” command, not the fully GITI path) and it takes you where you want to go. Unfortunately, they are very simple, and most rely on module functionality to make them work. The biggest drawback to something like this is that it is not possible to type “add assignment” and have GITI pick up the meaning on that. The most advanced that gets is being able to call a specific assignment by number “assignment 1143” returns the details page for Assignment #1143. The way that works is that GITI only recognizes one word in the string for the key, so if there is more than one, it breaks it up and passes the other part as a parameter to the module.  This eliminates any possibility for “natural language” keys, which sucks. Most keys do not even accept parameters, so that further limits flexibility.

Add, Find and View are some of the functions I would like to add as universals, but I have not quite gotten to writing the core level code that would allow GITI to have its own internal keys that are not module dependant. To do this will also likely require me teaching GITI a list of mappings for each of the special “natural language” commands (ie. “Add Recipe” calls Cookbook’s Add function). Find should be especially interesting, since at this point no modules, except Address Book and Library even support the ability to search for anything. The weirdest possibility for “find” would be writing a universal search tool that would look through specified fields on each module’s entities. I would worry about the database load of such a functionality though. I am not sure how “natural language” typing the phrase “find contact Kularski” actually is.

All of this stuff comes up now because of the creation of a new empty module called “Cookbook”. The module at the moment has no code, only its GITI constructs and things that will expedite my ability to write the module. It is a fairly simple module on the surface, its ingredient lists, directions and cooking times. No big deal at all there. I will likely get into more elaborate concepts such as categories and ingredient searches, but so far, I am just planning to create the data constructs for them and put not much effort into writing those components,focusing on the “important” stuff, like recipe insertion and retrieval. The mere conceptualization of the module causes these other needs to arise in Quick Key because it is a module that can require things to be accessed in a short amount of time, perhaps being pecked out on a keyboard using the end of a wooden spoon.

Quick Key could be a very useful functionality if I spent more time with it and perhaps made it more obvious in the user interface (beyond a small textbox).

exhibit 1: Quick Key command list