[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 
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


More information about the EpiData-list mailing list