Comments for new released EpiData Manager 1.3
Dear EpiData list,
After spending a whole day to explore the newly released EpiData Manager and EpiData EntryClient, I have some comments:
1. The new EpiData Manager is not as flexible as the older version in which I can add code for check file. For example, I cannot use EpiData Manager to calculate BMI. Or if I have 10 questions about mental health then I have no way to calculate the total score. The patients in some studies should be referred to psychiatrist if they have a mental health score > cutoff point at the time of assessment. There should be “EDIT” like the olde version.
2. Another example to show that “EDIT” to check data entry should be included. In the old EpiData, I can add some codes to do extra things. Ex: when I enter postal code for Vietnam, the city/province variable includes only cities or provinces in Vietnam. Or if I enter postal code for Australia, the city/province variable only has option to choose among Australian cities. No way to do this in this version.
3. I can enter data using Unicode font but when I export the data to CSV or STATA…, they do not work. It does not appear correctly (Vietnamese).
4. I love the way the old Epidata align fields because the variable names are aligned to the right of the screen.
5. The undo, redo symbol should be on the menu bar as users may need them
6. In Epidata Manager, Tools > EpiData EntryClient should open the form that users are working on. This is because the data manager will need to look at the format of the data entry form or want to test the form.
7. The Tools > Report should have an option for “code book” as we may need it to check the data. In the old version, the code book includes information about the mean, …
8. If the double entry file has password, then “Incorrect Password” message appears when validating data. No box appear for entering password in this case.
9. In the old EpiData, we can create parent-child data file which is very helpful in community survey or longitudinal data with the same baseline information. I cannot do this in this new version.
I have some year experience teaching EpiData at the university, so I am happy to be the tester or to contribute something to this very interesting and helpful version.
Thank you,
Truc
Thai Thanh Truc (♂), MPH Department of Biostatistics - Faculty of Public Health - HCMC University of Medicine and Pharmacy Email: mailto:thaithanhtruc@gmail.com thaithanhtruc@gmail.com or mailto:thaithanhtruc@fphhcm.edu.vn thaithanhtruc@fphhcm.edu.vn or mailto:thai@connect.qut.edu.au thai@connect.qut.edu.au Mobile: +84 908 381 266
Thai Thanh Truc made a list of relevant issues yesterday. Here area a few comments.
First it is very welcomed to have this highly structured feedback to the development. - we will look at these in the coming week.
Your question on related files have a simple answer: This function is planned, but not implemented yet.
The lack of flexibility of Manager in relation to "edit" and add your own code is a decision. There could be reasons to implement a very flexible structure, but currently this would take momentum off the other developments. The suggestion to allow for summary measures or calculation of BMI is already on my mind and I think we will reconsider this as an option to possibly implement in some form.
Other users please answer on the following questions:
1 Which aspects of the chk file functionality are still lacking with the new fixed possibilities ? Please be very specific like Thai Thanh Truc was.
2 Do we need analysis functions like codebook in EntryClient (or can one always use EpiData Analysis) ?
regards Jens Lauritsen EpiData Association
Additional functionality for Manager calculations:
1. It will be very useful to have some more calculation possibilities as we had in .chk files. In order of priority: - minimally, the following via the menu/drop down approach that exists: - add/subtract an integer variable or constant to/from a date field to yield another date field - result field = fn(source field[, source field b]) (where fn is a function as for the LET statement in .chk) - substr for string combinations - ideally, the ability to enter a text string that defines a calculation based on other fields (equivalent to LET statement in .chk). We should keep the functions to a limited set of those available for LET. I'm not sure what is most useful. Doing some calculation during entry is useful, as this allows for additional validity checking - the ability to reference value labels in another project (equivalent of COMMENT LEGAL USE abc.rec)
2. We already have most of the old codebook for Manager with reports. It might be useful to add value labels to the Extended report. The best way to get anything further, such as actual min/max, etc is with Analysis. It doesn't make sense to add this to Manager.
Jamie
On 2012-12-16, at 8:11 AM, epidata-list@lists.umanitoba.ca wrote:
Other users please answer on the following questions:
1 Which aspects of the chk file functionality are still lacking with the new fixed possibilities ? Please be very specific like Thai Thanh Truc was.
2 Do we need analysis functions like codebook in EntryClient (or can one always use EpiData Analysis) ?
Jamie can you extend the suggestion with a series of "let" examples, that clarifies the extend. My consideration is not so much whether to add something simple, but I think we should be careful not to constantly postpone highly desired functionality such as relate or GCP functionality with logging.
regards Jens Lauritsen
On 12/16/2012 08:56 PM, epidata-list@lists.umanitoba.ca wrote:
Additional functionality for Manager calculations:
It will be very useful to have some more calculation possibilities as we had in .chk files. In order of priority:
- minimally, the following via the menu/drop down approach that exists:
- add/subtract an integer variable or constant to/from a date field to yield another date field
- result field = fn(source field[, source field b]) (where fn is a function as for the LET statement in .chk)
- substr for string combinations
- ideally, the ability to enter a text string that defines a calculation based on other fields (equivalent to LET statement in .chk). We should keep the functions to a limited set of those available for LET. I'm not sure what is most useful. Doing some calculation during entry is useful, as this allows for additional validity checking
- the ability to reference value labels in another project (equivalent of COMMENT LEGAL USE abc.rec)
We already have most of the old codebook for Manager with reports. It might be useful to add value labels to the Extended report. The best way to get anything further, such as actual min/max, etc is with Analysis. It doesn't make sense to add this to Manager.
Jamie
On 2012-12-16, at 8:11 AM, epidata-list@lists.umanitoba.ca wrote:
Other users please answer on the following questions:
1 Which aspects of the chk file functionality are still lacking with the new fixed possibilities ? Please be very specific like Thai Thanh Truc was.
2 Do we need analysis functions like codebook in EntryClient (or can one always use EpiData Analysis) ?
Apologies if my message seemed as I do not wish to extend this.
I would like to do so, but as Jamie wrote "We should keep the functions to a limited set of those available for LET. I'm not sure what is most useful. Doing some calculation during entry is useful, as this allows for additional validity checking "
This is exactly the point.
If we go beyond a certain basic set - it is much better to implement a full "command compiler", which we will not do. At least not until the whole set of Manager, EntryClient and Analysis have been re-written.
/Jens Lauritsen
I agree with you, Jens. Everything I suggest below can wait until after RELATE and GCP. None of that is required for data entry. Jamie
On 2012-12-16, at 3:48 PM, epidata-list@lists.umanitoba.ca wrote:
Jamie can you extend the suggestion with a series of "let" examples, that clarifies the extend. My consideration is not so much whether to add something simple, but I think we should be careful not to constantly postpone highly desired functionality such as relate or GCP functionality with logging.
regards Jens Lauritsen
On 12/16/2012 08:56 PM, epidata-list@lists.umanitoba.ca wrote:
Additional functionality for Manager calculations:
- It will be very useful to have some more calculation possibilities as we had in .chk files. In order of priority:
- minimally, the following via the menu/drop down approach that exists:
- add/subtract an integer variable or constant to/from a date field to yield another date field
- result field = fn(source field[, source field b]) (where fn is a function as for the LET statement in .chk)
- substr for string combinations
- ideally, the ability to enter a text string that defines a calculation based on other fields (equivalent to LET statement in .chk). We should keep the functions to a limited set of those available for LET. I'm not sure what is most useful. Doing some calculation during entry is useful, as this allows for additional validity checking
- the ability to reference value labels in another project (equivalent of COMMENT LEGAL USE abc.rec)
please remove me from your mailing list Thank you Stephanie Douma
-----Original Message----- From: epidata-list-bounces@lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca] On Behalf Of epidata-list@lists.umanitoba.ca Sent: December-16-12 8:12 AM To: epidata-list@lists.umanitoba.ca Subject: Re: [EpiData-list] Comments for new released EpiData Manager 1.3
Thai Thanh Truc made a list of relevant issues yesterday. Here area a few comments.
First it is very welcomed to have this highly structured feedback to the development. - we will look at these in the coming week.
Your question on related files have a simple answer: This function is planned, but not implemented yet.
The lack of flexibility of Manager in relation to "edit" and add your own code is a decision. There could be reasons to implement a very flexible structure, but currently this would take momentum off the other developments. The suggestion to allow for summary measures or calculation of BMI is already on my mind and I think we will reconsider this as an option to possibly implement in some form.
Other users please answer on the following questions:
1 Which aspects of the chk file functionality are still lacking with the new fixed possibilities ? Please be very specific like Thai Thanh Truc was.
2 Do we need analysis functions like codebook in EntryClient (or can one always use EpiData Analysis) ?
regards Jens Lauritsen EpiData Association
_______________________________________________ EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
On 2012-12-16 21:15, epidata-list@lists.umanitoba.ca wrote:
please remove me from your mailing list Thank you Stephanie Douma
You can unsubscribe from the mailing-list at the bottom of this page:
http://lists.umanitoba.ca/mailman/listinfo/epidata-list
Regards, Torsten.
On 2012-12-15 20:54, epidata-list@lists.umanitoba.ca wrote:
- I can enter data using Unicode font but when I export the data to CSV or
STATA…, they do not work. It does not appear correctly (Vietnamese).
In regards to the STATA export question, the current official release (1.1.2) does allow for changing the codepage used when exporting to stata. This is done in the settings, where it is also possible to choose which version of STATA to export for.
With the current test-release changing version (1.3.0.9), encoding and other properties for export is done in the export window.
Older versions of STATA does NOT support importing UTF-8 encoded text, and therefor you should choose some other codepage. IIRC, from STATA version 11 and forward it is possible to use UTF-8 encoded string.
Regards, Torsten Bonde Christiansen. EpiData Association.
participants (1)
-
epidata-list＠lists.umanitoba.ca