Steve has written about the: "Epidata alignment problem"
The basic difference to remember from Epi Info v6 to EpiData and other
windows based interface programmes is the change from character based to
pixel based interface. The Epi Info screen V6 has 80 characters on aline
which can either contain a space or some letter.
Therefore what from simple logic could be phrased: (Quoted from Steve's
mail:)
"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."
is not simple in the Windows environment, because the width of a space
is not easily attainable. The basic choice in developing EpiData could
then be:
a.
We skip the rec file format altogether and create a new variant where
alignments are measured in pixels instead of in characters. We develop a
"drawing interface" where placements of fields are freely floatable.
b.
We maintain the rec file standard which has as a consequence that all
sizes for the screen are measured in characters of variable width. The
problem is that the header only allows for small numbers to describe
placement of entry fields etc.
c.
We try to fiddle with a combination of calculations to estimate the
length of "one space" and based on this use the REC file format as a
basis of creating a "usually nice looking" entry screen.
d.
We add a new file type defining the exact positions of fields.
e.
We restrict choice of fonts to known types where alignment is possible.
The point C is actually what we have done. The problem being that even
with fixed size fonts the width of a space or a given letter is not very
easy to calculate on a given screen. Many aspects of this is also bound
to language. Some solutions are very good for one language, but not for
other languages with special letters. EpiData Software is typically
downloaded from nearly 100 countries every month, so to do development
and accomplish only one or a few is not fair. Already basing all on the
english language (and now website also in Spanish) is a restricted
policy. E.g. obviously I would prefer that everything was written in my
native language Danish, but only about 5 mio people speak that language.
Users who have been along since 1999 will remember that in the beginning
there were many problems of combinations of fields and texts which ended
messed up/overlapped or hidden from the interface. So the current
principle is a "parsimoneous" balance of different tests and principles
creating exactly the alignment problems pointed out.
So what are the solutions to the problem
a. Someone find or develop very good algoritms which can in a
standardised way replicate alignment properties and submit them to us.
b. Persons who are very keen on this uses other software which is not
tied to the limitations of the rec file format. There are plenty of
commercial solutions to choose among.
c. We find another solution.
Option A: Anyone keen to experiment and spent time on this can find
freeware tools at http://www.freepascal.org/
So the statement "If ED is indeed legacy EI then the face presented to
the world should work properly."
obviously is a very nice goal, but as mentioned not easy to attain.
Focus is on the data entered NOT on the visual quality of the interface.
The fact is that interface handling is a whole different story than:
>But if there are resources for doing things like import/export,
>pack, codebook, validate, consistency, compress, archive
>
which can all be handled by standard logic, and which tends not to be
included in other software. What we have done with the EpiData
development is to accomplish needs which we found possible and desirable
within the time frame we had for this project. Data quality has the main
driving priority - quality of alignment on screens has not.
My suggestion is to add the issue "enhancements of data entry screen and
design" to the development list for the plan 2006-2010. If someone are
willing to find funding for this on top of the already planned
activities it can be added, but otherwise it will not be added.
Whether the patience of users of the software is sufficiently large for
this approach or they decide on option B above is not up to me to decide.
Kind regards
Jens Lauritsen
Initiator and Coordinator of development.
EpiData Association
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?
Steve
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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:
A<mm/dd/yyyy>B<Y>C___
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’t do anything. Either way, thanks again for
all you have done for the rest of us EpiInfo lovers.
Sincerely
Steve Blum, PhD
Associate Professor
Albert Einstein College of Medicine
Dept of Epidemiology and Population Health
Steve Blum
Steve,
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
Dear all,
I have a problem with numeric fields of more than one digit in length,
e.g. ##.
All legal values (and their value labels) for the variables in my
questionnaire are precoded in the CHK file. Currently, if a legal value
is defined as "1", the data entry program does not accept "01" and vv:
if a legal value is defined as "01" the data entry program does not
accept "1".
The typists usually type without looking the whole time at the screen so
they prefer the legal values to be precoded 01, 02, 03 etc because if
they enter "1" they would need to press ENTER before the cursor moves to
the next field (which they do not need to do if the length of the field
is one digit).
Precoding "01" etc initially seemed to work fine, but as soon as the
record is saved, when the typist needs to return to the same record,
e.g. to make a correction, the value "01" is reflected as "1" on the
screen, and when passing through this field again, e.g. to move to a
part that is further down in the questionnaire, an error message pops
up: "illegal entry", and the typists believe they should change the "1"
again into "01". This is at times quite a bit of a nuisance.
I think that one possible solution (I have not tried this yet) could be
to define for all digits under 10 both "1", "2", "3" as well as "01",
"02", etc as legal values (with the same value labels), but I think it
is not very elegant. Is there another solution?
PS. is there a command that can used in the CHK file to that after every
entry the typist needs to press enter before the cursor moves to the
next field?
Thanks a lot,
Henriette
Dr Henrica A.F.M. (Henriette) Jansen
Epidemiologist,
WHO Multi-country Study Violence against Women
Department of Gender, Women and Health
Tel direct: +41 22 791 3106
Fax direct: +41 22 791 1585
Mobile: +41 78 730 3035
E-mail: jansenh(a)who.int
Website: http://www.who.int/gender/violence/multicountry/en/