[EpiData-list] Epidata alignment problem

epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca
Thu Aug 3 13:43:05 CDT 2006

Dear Jamie
     Thanks for your response to my alignment problem.  Unfortunately,
neither solution offered is acceptable.  Using one field per line is unmanageable 
when you have hundreds of fields.  Using the '@' method, if you can figure out
the pixel business, results in entry fields that are aligned, but the associated text
is scattered all over the place and may be on  different lines.  The data entry screens 
and printed forms are the public face of ED. 
      If ED is indeed legacy EI then the face presented to the world should work properly.  Otherwise, either the QES file must be intentionally misaligned or the REC file will not be acceptable.  But then the QES file is a mess.  It seems to me that the code can be changed to correct this problem as indicated in my original message(see below).  If it cannot be corrected, I would appreciate it if someone on the development team would let me know so I can switch to something else and be done with this problem.  If it can be corrected, will it be? I understand and appreciate the enormous effort that has been
expended by the team.  But if there are resources for doing things like import/export,
pack, codebook, validate, consistency, compress, archive ......., then how can 
the entry screens and printed forms remain unusable in a routine, typical  manner?



DEAR Jens and Michael ,    
      I have delayed composing this letter for quite some time because
 I so much appreciate the efforts and accomplishments of the Epidata(ED)
 team over the years.  I was one of the early users and continue to use     
 ED extensively in our very many projects here at the hospital.
      My problem is that what I see in the QES file is not translated,
 as it appears, to the data entry screens in the REC file. In other words,
 the form is not WYSIWIG; in fact, what you see is NOT what you get.
 What you sometimes get in data entry screens are fields that are
 scattered all over and the allignment between the lines is comletely lost.
 This does not happen in EpiInfo(EI).
      This problem is not apparent in the sample files because they only
 have one item on a line.  To see the misalignment, the QES file must
 have multiple lines and fields that use the brackets, such as date and
 boolean fields. I examined the header portion of the REC file generated by
 both EI and ED and they are essentially identical. The brackets and their 
 conversion are the problem!
      Consider the following very simple QES file:
 D___________   E___  F___ 
    Note: the font may be changed by you email client.  To see the
    point being made, letter D should be right under letter A, 
    E should be right under B and F under C using a fixed-width
    font, such as 'courier new' with no spaces between the fields.
 I have six fields(A-F) and have intentionally placed B right after A
 and C right after B. If this file is converted to a REC file in EI, 
 everything is aligned exactly as it appears above.  If it is converted
 in ED, it is not. What EI does is remove the left bracket in field A 
 and shift the REST OF THE LINE one space to the left. It then removes 
 the right bracket from A and again shifts the REST OF THE LINE one 
 space to the left. It then does exactly the same thing for field B. 
 Everything would now be out of alignment with the next line,
 except that EI then adds two spaces IMMEDIATELY to the right of EACH
 field from which the brackets have been removed. In fact, if you
 look at the data entry screen in EI, you will notice that after
 shifting to the left as described above, two spaces now appear right
 after field A and two space appear right after field B, and this 
 maintains the alignment with the lines below. ED does exactly the 
 same shifting as EI, but fails to add two spaces to the right of 
 each of these bracketed fields. Changing the font in ED data entry
 screens to fixed-width does not help.
 I develop QES files with hundreds of fields of all types, and  bracketed 
 fields hopelessly mess up the alignment in both the screen version and in 
 printed forms.  While I can now(since I figured it out)  make these 
 adjustments in the QES  file to maintain alignment, I cannot  recommmend  
 ED to any of  my less experienced colleagues because the entry screens     
 and printed reports will  look disorganized, resulting in a less 
 aesthetic experience and more data  entry errors.  I must therefore
 either  personally design every form  (which I do not have time for), or   
 have them use something horrible like Excel.
      EpiData is a splendid product and is indeed legacy EpiInfo because it 
 maintains the elegant features of the latter,  while adding many new and 
 really useful ones.  The loss of alignment between lines, however, sort of 
 ruins things for me although it probably does not affect most users. If my 
 analysis is correct, I hope the program can be modified relatively easily.  
 If I am wrong,  maybe you can&#8217;t do anything.  Either way, thanks again for 
 all you have done for the rest of us EpiInfo lovers.
 Steve Blum, PhD
 Associate Professor
 Albert Einstein College of Medicine
 Dept of Epidemiology and Population Health     
 Steve Blum


If you want to line up the entry fields and are less concerned about the 
text around them, put @ before the entry field. It is quite easy, with 
minimal trial and error, to get the entry fields to line up. In my 
experience, most questionnaires align the spaces to capture text and 
with judicious use of spaces to separate field names/text,  you can get 
a questionnaire on screen that is quite easy to use.

We teach our field epidemiologists to enter data one field per line, for 
simplicity and because this produces a  nice companion to the codebook 
(we suggest using "first word" for field names). However, I also liked 
the fixed font approach of EI when creating questionnaires. Over the 
years, we realized that data entry fields scattered across the page were 
not ideal and shifted to the single column (with exceptions where it 
makes a lot of sense).

The help file with ED doesn't say much about @, but does point it out in 
the explanation of differences from EI.

In your example, I tried this:
A @<mm/dd/yyyy> B @<Y> C @___
D @___________  E @___ F @___

and, while E is not under B, the entry fields line up very nicely. When 
you add the field descriptions, it looks better. Some fields may need 
more than one @, or add spaces before the field name. I prefer to use 
'First word' because the questionnaire then documents the field names. 
Your colleagues should be able to master this easily.

A date goes here @<mm/dd/yyyy> B key y/n answer @<Y> C this is a name @___
D the address @___________ E diagnostic code @___ F outcome code @___

Jamie Hockin
Public Health Agency of Canada

More information about the EpiData-list mailing list