Screen shot #2 (Merely a picture to illustrate that our GUI is totally self-explanatory) 

While TK-MIP rigidly adheres to most Windows’ Key and Menu Option standards, as prescribed by Microsoft, a single exception is in how TK-MIP handles the User activity history/check-off log" by merely reporting User progress (without the user ever directly or explicitly clicking anything on this list itself) since TK-MIP reports and updates this list automatically as the User accomplishes the various intermediate processing goals. A passive “User activity history/check-off log” as a detailed menu drop down list maintains continuity of operations by passively summarizing at-a-glance what operations have already been completed (by no longer being grayed) and what remains to be done (as signified by still being grayed) before the particular task is fully complete. In this way, the User will not loose his place if frequently interrupted for long periods of time. It is crucial to aid the User in this way so that long processing runs can be easily handled despite any hiatus in the User’s attention so that the User never looses track of what steps have already been completed and what remains to be done. TK-MIP prevents processing collisions or unintended redundant retracing of previously activated steps by visually notifying the USER via  the feedback of a red light being present in the program’s status bar at the bottom of the screen (when both mouse and keyboard inputs are locked out) until it turns green again as the signal that it is again receptive to further User requests. We have other convenient User cross-checks throughout TK-MIP.

Microsoft Word™ is to WordPerfect™ as TK-MIP™ is to ... everything else that claims to perform comparably! 

User can provide a specific name for each project in order to easily distinguish it from other likely projects and furthermore to unambiguously associate with it both the intermediate and final output files for the particular project at hand (with history of activity log stored in a concise “header” to each intermediate and major output file that automatically reloads and refreshes TK-MIP whenever the User resumes processing right at the same point where the User last left off (even after project has been closed and TK-MIP has been exited or the computer has been completely shut down or powered off). Otherwise, if User has a sufficiently long block of time without any interruptions interfering before completion of the tasks at hand, User can just perform the processing functions in one sitting without such project identifiers and TK-MIP will remember all pertinent activity history without a specific project name being assigned as long as TK-MIP is not exited and there is only one User performing only one project at a time. Even in seeking to follow the latter case (described last as not designating a particular project name) and an unanticipated interruption occurs, If processing outputs and models already specified are saved and given a name after the fact, then the existing activity/history log residing within TK-MIP up to this point will be correctly associated with the project and automatically appended by TK-MIP as a header for later User resumption of tasks in pursuit of the final goal.    

By invoking a particular project and then “Save Project as...” with a name change, all files associated with the original project name will inherit the same new name change except SAVE_ALL files which will retain their previous name. Of course once saved, SAVE_ALL can then be invoked with the new name and a SAVE_ALL will then be associated with the new project name in case User later seeks to RESURECT_ALL with this new project name. User may want to just change a few parameter values in the models and then recalculate results in this easy way to keep things properly sorted out. See the parallel with how Users can easily handle and manipulate document versions within Microsoft Word®?

Our TK-MIP™ software is a masterpiece of engineering implementation by properly anticipating our users’ needs.