Announcement:
An important development step has been reached: The first public test release of the new EpiData Data Entry Client.
Since the first release of EpiData software in 1999 focus has been on data quality, stability and simplicity seen from the end users point of view. This strategy has been extended with more functionality and release of Analysis some years ago.
Following the large user base resulting in download counts in several thousands as documented on the download pages - and unknown dissemination of copies to other users - an important decision was made a few years back to rewrite the whole software for the next decade.
This has resulted in change to a new development environment (freepascal and Lazarus - see lazarus.org), which allows for crossplatform development based on the same source code, but also a new file structure. The EpiData XML file format "EPX" combines and replaces the current qes, chk and rec files into on physical file. It will also allow for more extensive access control at section level and compliance with so-called GCP (Good Clinical Practice) principles. The specification of the EPX format takes place in discussions with The Danish Data Archives (http://samfund.dda.dk/default-en.asp) in relation to securing compatibility with the DDI formats (see http://www.ddialliance.org/)
The file structure will be fully documented. Currently you can see the principles in http://www.epidata.org/dokuwiki/doku.php/documentation:datafileformat:xml_v0
The re-written software will consist of three parts - and possibly batch processors for repetitive tasks. a. EpiData Data Manager b. EpiData DataEntry Client c. EpiData Analysis
Therefore it is a crucial step in the development that users having either Linux, Macintosh or Windows operating systems can now test the new software released in as well 32 and 64bit versions for as well Manager and Data Entry Client (a+b).
Users are urged to test as well data definition, change in definitions and entry for files. Also please comment the development on this list.
In particular test and discuss these aspects: a. can we define all structures we would like ? - notice that in definition of data paste of text and qes like structures is possible b. is the naming of structures and aspects correct ? c. is the "feel of the software" easy to adapt to from earlier versions ? d. Also test local language formulations of data forms and entered data.
In particular point c is important. We have to renew the system and principles. but would not like to loose a large number of users. Notice that the current release is NOT containing the controls in check files, but this will come later. We have a detailed development plan, which has been discussed in previous mails on this list.
In the sample data base we have included 12 different local language fonts, which we can see on our monitors here, including Danish, Asian and right-left such as Arabic. The text included should say "Sample text", which we translated with an automatic translator on the web. On linux the right-left or left-right is shown correctly, but in windows all local fonts are aligned to the left border of the text field.
The current test release is not for production, but only for test. But we proceed to add further functionality and more introduction documents until most of what was contained previously is available. Programming is done by Torsten Christiansen here in Denmark and specification via current functionality in EpiData Entry and Analysis, plus the discussions on this list and with the "Friends of EpiData Group", see the credit page on epidata.dk.
The test version is released as a combined package of Manager plus Entry Client, but also includes the "sample.epx" file and is found on: http://www.epidata.dk/testing.php
As soon as stability has been secured via your tests we will change the status from test to release with limited functionality. The time for this is not defined, but some aspects are crucial before turning to first actual release, e.g. secured timed back-up or reading of EPX files into analysis.
One major change for entry is that now all data resides in memory until saved, therefore the user is asked to save project when closing. This will result in longer load times at the initiation of entry, but allows for quicker search and moves between records.
Regards to all
Jens Lauritsen Initiator and coordinator of EpiData Software Denmark
Manager and Client behave pretty well on my Mac (Intel) and in Windows Vista.
Field entry is as expected, ignoring invalid keys and limiting lengths. Dates seem to go in properly, with short dates being assigned to the first fields. I would prefer that a single number entered in a date field be assigned to DAY, but realize this is a design issue that all of us can deal with.
It will be good when the cursor changes without a mouse click, but that's not a problem in a test version.
Congratulations on getting to this step!
Jamie Hockin
On 2010-09-10, at 5:38 AM, epidata-list@lists.umanitoba.ca wrote:
Therefore it is a crucial step in the development that users having either Linux, Macintosh or Windows operating systems can now test the new software released in as well 32 and 64bit versions for as well Manager and Data Entry Client (a+b).
Jamie comments on keyboard and movements.
The strategy for moving after a key press or mouse in Entry Client is this: a. tab, "arrow down" or enter : move to next field b. shift+tab, "arrow up": move to previous field c. when clicking with the mouse: move to that field d. arrow down in last field: move to first field e. arrow up in first field: move to last field
The date rule now is: One number: entered as first of dmy/mdy/ymd type, e.g. year for ymd Two numbers: entered as first of dmy/mdy/ymd type, e.g. year for ymd if more than 12 in a mdy field, then reject entering
More than two numbers: depends in the same manner on field type (dmy/mdy/ymd)
Jamie Hockin suggests to always use a single (or two) digits as day, and I suppose up to four digits always as day + month.
Please discuss here on the list which logic you would like to see.
regards Jens Lauritsen EpiData Association
I think it is trickier if 2 numbers (or 4 digits) are entered for a date. I would propose that anything other than a single number follow the day and month scheme established for the field. So entering 1011 for a <dd/mm/yyyy> field yields 10 November, but 11 October for a <mm/dd/yyyy> field or <yyyy/mm/dd> field. It's a bit of backwards logic, but would be easily explained to anyone doing data entry. But I have no strong feeling about that.
Jamie
On 2010-09-11, at 11:10 AM, epidata-list@lists.umanitoba.ca wrote:
The date rule now is: One number: entered as first of dmy/mdy/ymd type, e.g. year for ymd Two numbers: entered as first of dmy/mdy/ymd type, e.g. year for ymd if more than 12 in a mdy field, then reject entering
More than two numbers: depends in the same manner on field type (dmy/mdy/ymd)
Jamie Hockin suggests to always use a single (or two) digits as day, and I suppose up to four digits always as day + month.
Please discuss here on the list which logic you would like to see.
epidata-list@lists.umanitoba.ca
-
epidata-list＠lists.umanitoba.ca