[EpiData-list] Aligning of fields and development priorities
epidata-list at lists.umanitoba.ca
epidata-list at lists.umanitoba.ca
Fri Aug 4 16:27:42 CDT 2006
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
"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
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.
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.
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.
We add a new file type defining the exact positions of fields.
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.
Initiator and Coordinator of development.
More information about the EpiData-list