ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > The Form Letter Machine

General use issues.

<< < (3/4) > >>

kimajac:
The variable list does not update correctly.  If you are in a tree and adding a variable, in some cases I will get a new variable for every additional letter added.  So I will have a dozen new variables in the list.  If I close the program and reopen, things are fine.  If I want to save the variable list, I cannot remove the errant entries before saving.
A means of updating the list would help

One of the previous posts recommended a global variable list versus a list specific to the current tree.  I would agree that a method of changing the scope of the variable list would be very helpful.
Others have asked for some means of manipulating order of variables.  Again a very helpful feature.

kimajac:
My current method of using TFM:
I get the TFM text close to what I need.  I then paste the text to Msword.  In Word,
I tweak the text and then paste to the final destination. Since I am in a very
fast paced environment, this methodology insures I am pasting the best quality text.
In the past, I would paste to the final destination and tweak things in a non-editor
window.  I would invariably leave words/sentences that did not apply to the current
file.  Plus it is more efficient to edit the full doc than trying to find the source
text to edit in TFM.

If the center window could be edited, I think it would greatly improve the functionality
of TFM.  It is almost impossible to add a radio button or check box for every situation.
While the text can be edited by finding the appropriate place in the tree, my trees
are very extensive and the search can be time consuming.  It is more efficient to
edit the final output as a whole than it is to search for the text in the tree.  The quality
of my documentation has improved dramatically.

The changes you made to the latest version are awesome.  Greatly reduces the chance
of storing things in the wrong locations.  Have not had much chance to put the new
version to serious testing yet.

The ability to manipulate the order of the variables would really help.  They could then be grouped by relationship or ordered so that pasting to them would not require jumping around the list.

mouser:
Hi Kim,

I'm very glad to hear that the last version was an improvement.

Making the main editable directly.. it's not impossible but it is quite tricky because whenever you check a box it recreates the message and so all changes you make would have to be remembered and associated with a particular node in the tree.

Right now you probably know that you can edit the currently viewed contents on-the-fly so to speak by selecting a node and changing the text in the upper window.  this actually changes the tree *temporarily* which is how its able to remember your changes even if you check and uncheck other items.

What i could do i think is making it so that when you click anywhere in the main text, it JUMPS to that node in the tree on the left and the upper window -- at least then you could find what node was generating any text instantly.

As for the variables --
i think one of the problems is that i really don't use them much at all myself, so naturally they got relegated to second-class status.  i can think of some improvements like HIGHLIGHTING them in the main text window and letting you click on them there to fill in the values.

And as you say maybe they could be shown in a better way in the list with user ordering.. but i guess my problem there is just that i don't have a good feel for how more people want to use these variables and i don't have an understanding of the philosophy of their use so it's hard for me to get a grip around what the ideal user interface would be.

kimajac:
Text Edit
Since there is a button that pastes the current text to the clipboard, it would be functionally similar to add a button that would paste the current text to an edit window.  This would be a one-way transaction.  Edit the text and then press a button to paste to the clipboard.  Once the window is closed all changes are lost.  This might be easier than trying to change code within the program.

Variables
I really like the ability to fill in a variable on the fly.  It would be a nice prompt for temporary data that is not efficiently saved in each variable file.  Take it one step farther and allow entry of variables directly into the variable file.  Most  of the time I know what data I need, just not where in the tree.   The ultimate would be allow dragging of a variable from the variable window into the tree edit program.

Here is an explanation of how I use the variable file.  I create a blank file with 25 variables.  The way I do this is to first create a dummy tree that is nothing but a list of variables in the correct order.  That gives me a base "blank" variable file. 

Since I am dealing with 50-100 data files per deployment, I bring up the blank variable file, rename it to the reference file number and save it blank.  I then paste data into each field from the legacy program.  (BTW pasting is a pain since the highlighted field name is not replaced with the pasted data, the data is inserted into the field name.  I have to first delete the name and then paste.)  Since I am cutting and pasting in the order dictated by the legacy program field location, if the fields in the variable file are in the wrong order, I am jumping up and down the list to paste.  Once all data is pasted, I save the file again.

Some would ask why do I do all the cutting and pasting.  I am in a car all day.  The aircard has limited bandwidth.  I am taking calls from customers and about customers all day.  TFLM is up all the time with the "general info" tree showing.  When a customer calls, I can bring up their variable file and have all their information available.  That allows me to complete the call without relying on a network connection.  At the same time I change the tree and document the conversation and save to a remote file. 

The variable file supports the following trees.  "First contact", "inspection", "prior loss email ordering", "no contact".  If, during development of the tree I have to add a variable, it automatically goes to the bottom of the list.  That is usually not the best position for cutting and pasting for new files. 
 In each case the log entry includes customized data taken from the variable file.  Nobody else on the team can place the custom data in the log as quickly.  They are not using TFLM!!
Some of the trees have 50 plus radio buttons and check boxes and 3-4 levels of dependency.  Example.  If there is a prior loss, does it relate to the current loss.  If so, is the data available or does it have to be ordered.  If ordered, record when ordered because that sets the start time for the max waiting period.  Other trees use 2-3 variables in a single sentence.  You can see that when deployed I put TFLM through a full test.

Hope this helps explain why manipulating the variable file is really critical to the efficiency of creating log entries.

mouser:
you are really using tflm for some interesting stuff.. the more i read though the more i think that what you need is another program, similar to TFLM but more designed for your use.. like using nice plaintext files for variables so you can easily create and edit them using a standard text editor, etc..

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version