Is there a roadmap with timelines available? We might be interested in replacing a student course based on the old Epidata Entry with one based on the new version, but this of course depends on the release dates.

Kind regards,

Simon

The short answer is YES

- but the time scale is always somewhat uncertain, since we cannot foresee the problems in the next phases. To ensure future compatibility of XML file structure we must now include all functionality which will affect the XML data structure.

My current principle in teaching (Materials found on http://biostat.sdu.dk/courses/datadocumentation) is to have the participants work in the "old versions" for entry, but then also showing how they would do this in the new software. And suggest that they try the new and add comments on the EpiData list - the understanding that software development is something which users can comment upon is very unusual for most people - they tend to think that there can be no influence.

In my daily work (at a hospital) I have started to use the new principles for evaluation projects, because we cannot ensure reliable function without working in real situations. But these are short time/one time used data files with e.g. 30 observations. When the XML structure changes it creates no problem, since then that specific evaluation is already over.

SInce the products are released for free download there is only the "moral" obligation and credibility (plus agreements with donors) to follow a strict plan - remember that the EpiData Association is NOT a commercial company, government agency nor an official NGO. It is an initiative with support from the users and institutions endorsing the principles included.

Due to the current funding basis we have to demonstrate and release a functional product soon (within one-two months). The problems showing up will define whether some aspects are moved to "after V1" in the list below.

I should also say that due to the problems which have showed up in the re-writing process it is necessary to attract funding for another year of development.

Only when there is a final functional software with current functionality (data definition, documentation, analysis) implemented and extended with GCP principles in the re-written form for several operating systems (Linux, Win, Mac et. ) will the project have reached a state, where stability is secured for the next decade. By then we will have a standards compliant software which can be/will be a strong tool. This should be accomplishable within about a year, where single products are released and extended over that period starting soon. Technical documentation will be released on the wiki.

Introduction documents will be part of the release, whereas extended user/field guides and wiki contents depends on work from users and collaborators, such as the APHEO initiative (http://www.apheo.ca/index.php?pid=47) and the online course materials developed as part of IUATLD training courses (http://www.tbrieder.org/epidata/epidata.html ).

I have learned from years of experience with EpiData to base development on a proper mixture of: a. Be very certain about the principles used in implementation of features (stick to known and established principles) b. Work according to defined user groups/types of study. c. Create structured and detailed plans and follow them strictly in content d. Have an eye open on which features can attract funding at a given time

But also to remember NOT to promise anything finished at a given time (Apart from deadlines defined by the projects currently funding development).

On October 26th I had a similar mail regarding this and wrote:

"My own decision is to base the next courses in February 2011 on the new (EXP) systems, but I will start to use the system for smaller evaluations from now on. Gradually teaching and instruction materials will show up with the new interface and possibilities. When developing such materials make sure that we all know about on the list, such that there can be mutual benefit of this."

Since then it turned out that we decided to add more XML based functionality than anticipated AND added the template functionality used in EpiDataCmd processor. Maybe a short time drawback, but definitely a value added part in the long run. This also revealed a need for more additions to the XML structure.

Regards Jens Lauritsen EpiData Association

List of revisions before version 1 of manager and entryclient:

----------------------------------------------------------------------------

Changes requiring XML changes in file structure:

1 Fundamental change to XML: headings and fields all have a name and a "question" text. -- to avoid problems of translation

2 Study description - definition of basic tags for study description (based on http://www.ddialliance.org/Specification/DDI-Lifecycle/3.1/XMLSchema/dceleme...)

complete list (Approval expected from Dansk Data Archive):

<Author></> <Publisher></> <Title></> <Purpose></> <Abstract> </> <Citation></> <Identifier></> (Unique identifier in GCP terms) <Coverage></> (geographical and time period) <Rights></> <Funding></> <Language></> (default language)

<Version></> (user specified versioning) <Created></> (date created) <Modified></> (date saved regardless of change in data/structure)

3 feature: key unique - on import report of non-compliance to pdf report

4 field attributes: notes/info at field level (xml) type comment to other field (xml) default value (plus jump reset to this value) (xml) repeat value from previous record (xml)

autotime and autodate fields: attribute indicating: "value at day/time of record created" "value at day/time of record updated/saved" (xml).

5 simplified construction of calculated variables: Principle: Result value is typed into "resultfield" at the time of :entry of last of indicated fields in sequence in file. :saving record - Before "mustenter" is checked If any of fields involved are "missing value" result is .

A time difference into other field: (date2+time2)- (date1+time1) (possibly extended with truncation, e.g. years)

B datefield = combine day month year into a dmy/mdy/ymd field

C combined text field: string representation of up to 3 fields: stringfield = var1 + "-" + var2 + "-" + var3

D undecided: simple math, e.g. (var1+var2) or BMI calculation -------------------------------------------------------------------------------------------------

New features - not requiring XML changes (and possibly moved to after V1):

1 Visual: (setup parameter of manager and entry) font size (by factor) colour: focus field, background, non-focus fields

2 print dataform in manager and client (pdf) use in other parts for documentation reporting pdf creator tool/component: Powerpdf

3 feature: simple search (specified a la jumps) show "next record ctrl+f" with function key "repeat (f3?) " or "all records" s matching criteria in a grid form with possibility for "edit record" after scroll save search criteria in ini file (a la recent files)

4. interface for study description fields (as defined in xml structure) ----------------------------------------------------------------------------

AFTER version 1 encryption of files and sections (user access control) validate tool for dublicate data files more datasets in one epx external labels (e.g. icd10) relate (relational database) translate questions and text features of databases field notes (previous F5 feature) - add text to single "flat file" including keys from current record GCP features on entry and reporting change language of interface ----------------------------------------------------------------------------