Good to see comments from users yesterday. I wish to comment on one of them, which is the conversion from EpiData Entry (qes/chk/rec) to Epidata Manager (recxml).
It is of utmost importance that the basic way of working is NOT changed. But also that we most do some changes to accomplish new possibilities such as MAC/Linux versions or GCP compliance.
Jamie Hockin writes:
- editor does not mind that a file is open in Manager (good!), but each
should recognize when a file has been changed by the other
Let me expand on this issue. The decision just now is: a. reading of QES files directly and/or pasting from the editor or clipboard onto the data form (with subsequent saving in files) is supported. (and errors in relation to this fixed).
b. The data form contains definitions for the structure and metadata (labels etc) of a file. These definitions can be shown at any time in the "view structure" form, which is activated by the right most button in the toolbar, when a data form is shown. (Will get a function key).
c. If any change is made on the data form, then the "view structure" is updated.
e. Any change in the editor will NOT result in changes in other places, such as the data form. Unless the user actively "pastes" these onto the data form.
To support the current users - the editor has an easy way of creating data forms by pasting contents onto a data form. This pasting is the same as when we previously first saved a qes file, then created a rec file, and if we changed the qes file, we would have to go into "enter data" before the rec file changed. With the new manager we skip 2 steps in this. Steps which often gave me trouble when teaching.
We will implement (later) a conversion from the data form to a text based representation, e.g. "Data form to qes" or "data form to rec file" - but this is going to be a "one-way" route in the same manner as we can "import a qes or rec file". Import/Export must be possible, but if we limit ourselves to a 1:1 correspondance btw. data form (recxml) and old data file (rec+qes) it will create other problems.
Jamies other suggestions of having labels before and after the entry fields or possibility to define help notes in each field are good ones for implementation later. Previously it was not that easy to define such aspects and if we find an easy way of implementing this more users will be encouraged to change to the new principles.
Please give more comments, also on the choice of which current chk file commands we should maintain as "core checks" and which ones are for the more experienced.
regards Jens Lauritsen EpiData Association