Category: Programming

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

GITI comes across as a very timid web app. It doesn’t even attempt to be Web 2.0 at all, aside from a little CSS, but things are not as simple as they appear on the surface. There are many functions and tools hidden in GITI that have hardly ever made it to a menu. I don’t know why I have allowed things to get like they are, but there is NOT a good menu system for GITI at this point. For something with Interface in its name, it is lacking in end-user friendly components, such as menus that clearly outline the functions that are available.

Last fall, Chris became a student and at the same time became a GITI user for more than tracking what sneakers he wore when (a module he wrote). At the time the class tracking functionality was somewhat limited, most things had to still be managed manually, except for class closing (which is easier to do one class at a time as they close when you are bored at the end of a semester… when do you think the function was written anyway?). I added more features to make things easier,  including a class planning and registration process, but  that functionality was not apparent and the entire process was a little obtuse. Functions designed to make batch management simpler ended up being easier to do manually, one course at a time. Seems a little counter-productive. The truth is, aside from the new welcome page for the Education module (which almost screams “MAIN MENU”), nothing else even gives a hint to the new functionality. Part of GITI’s charm is supposed to be an integrated menu system that is universal across the system which will allow “one click” navigation (in v1 it was like 3, but still, no new page to load to get to your function). Getting from place to place should not require loading a separate page, and certainly should not require actually entering the module to get access to its internal side bar menu, that makes the modules too independent and less part of a cohesive system.

Another thing that has come to my attention is that GITI is no longer modular. If you pull out certain modules, other modules stop working. They are more like organizational units of functional code. Education now has a dependency in Address Book, Address Book has a dependency on the Asset manager functionality, nothing is separate anymore. The lack of separation makes GITI more usable in my opinion, but it also makes it less versatile. There is no common API yet, just a bunch of code held together by a string (literally, a string variable, called cmd).

So much stuff is hidden because it isn’t in a menu and isn’t in a user friendly location. There are functions in GITI that even I forgot were there.

ok, the title sounds bad, but it really is not about my instructors, its about my instructor objects. Today I have been working on moving some things around and creating a bond between the AddressBook and Education modules. I want my instructors (present and future) to be registered with the AddressBook so that I can store a lot more information about them. The problem with this comes from the process for associating an instructor to a class and the handling of old instructors.

The main issues are:

• Allowing user to enter information, but avoiding duplication of instructors
• Keeping Class.Instructor and the Instructor object consistent
• Promote data insertion at various points in the process without overwhelming user
• Keeping my sanity while tracking all possible permutations of data manipulation

I have a majority of my code written, but there is still a lot of things I need to consider to prevent data contamination.