I am a research assistant that wants to use ODK for our small study in
east africa. We want to use android based phones or tablet PCs. I
am coming from a strictly research background with very little
computer experience (other than an interest in technology)..so my
questions are definitely newbish. I have many questions, so please
feel free to answer part or all of my questions. In terms of
implementing aggregate and collect, I have been receiving the forum
digests for a few weeks and feel confident that you lovely folk on the
forum can help me trouble shoot anything that went terribly wrong in
the implementation or with the software.
A bit of background
I recently downloaded ODK collect on an android emulator and am
impressed with the potential of the tool. I have researched a number
of other possibilities out there for a researcher and this is by far
the most exciting tool out there. However, I am very intimidated by
trying to implement it. I have not even tried to use the aggregator
yet because I am concerned about creating forms. Our survey will be
about 1000 questions long with subforms, complex skip patterns,
possibly some repetition.
Forms and XHTML
One of my biggest concerns is that ODK build is not yet very mature.
It does not yet support skip patterns, subforms and what not so I
cannot program it myself eaisly. I don't have the computer skills and
the programming experience to code the forms in XHTML, nor do I really
have the time to teach it to myself. Are there programmers out there
(in the US, but also perhaps in east africa? that we could hire to
help code our survey?) How easy would they be to find? It seems that
XHTML is relatively new.
Data format
But I was wondering, what format is the output data in. It says on
the website that it exports to google spreadsheets. I have not yet
had the time to test out aggregate and am running into a road block
with the XHTML to test the format of output data for myself. So
perhaps people who have used the program can answer this question: can
google spreadsheets retain your labels. By this I mean, if you ask a
question such as What is your favorite color. Green (1), Blue (2) and
Red (3). Does the spreadsheet report 1,2,3 but also retain the
labels? In free data entry software such as epiinfo, you can export
this information with your database/spreadsheet and automatically load
it into your data analysis software such as Stata, SAS and SPSS. In
the end this saves a lot of time to have the labels imported in.
Codebook
Is there anyway to obtain a codebook or extract a codebook from your
survey. A codebook would be a printable sheet with every question
asked and the possible responses (in text) with their corresponding
numerical values. Again this would be very useful for the data
analysis.
Languages
In the demos of ODK, there is the possibility of switching between
languages in your survey, which is extremely useful. How would I go
about doing that?- i think I would like a general overview to
understand the process.
For such large forms, we have been very intrigued by the XLS to XForm
converter http://xform.childcount.org/ which allows you to enter a form with
repeat groups rather easily as rows of entries in an Excel spreadsheet. It
then converts this to a well-formed xform. This converter lacks support for
branch logic, but most tools available do not support that and you will
likely have to hand-code that logic in many cases -- it is just too hard to
capture through a simple user interface. Once you generate the form using
one of these tools, the branch logic resides in the model area and could
probably be cut-and-pasted rather easily across your revisions whenever you
revise different sections of the form as long as you do not change the field
names (tags) in the form.
With text-based forms such as XForms, there is no need to code the selection
choice into an integer value for data processing. You can define it to be a
(short) alphanumeric value (no spaces please!). e.g., 'highBloodPressure'
or 'red'. This eliminates the need for a codebook. If you do need numeric
codes, and therefore a codebook, you should definitely look at the XLS to
XForm converter. I think the selection value lists (see the 2nd tab of the
surveys-v0.2.xls "template" example on the above site) will exactly be the
codebook that you seek.
As for the output format, the data is transmitted off the phone as an xml
document:
The field names are the tags in the xml format (e.g., "TextSection0_data").
The values that were entered or populated via a calculation while filling
out the form are between the start and end tags (e.g., "yes" for the
TextSection0_data tag).
These short xml documents are interpreted by the Aggregate server, and split
into separate data fields. And the values for these data fields are then
stored in different data columns. Multiple-choice selections are
space-separated, hence the need for no spaces in the selection value being
used. If you set up publishing into Google spreadsheet or fusion tables,
these columns will appear in those tables. If you download the data via the
Briefcase tool, they appear as separate columns in a .csv file.
I'll let others talk about languages...
Mitch
···
On Thu, Oct 7, 2010 at 11:01 AM, Chloe wrote:
Hi,
I am a research assistant that wants to use ODK for our small study in
east africa. We want to use android based phones or tablet PCs. I
am coming from a strictly research background with very little
computer experience (other than an interest in technology)..so my
questions are definitely newbish. I have many questions, so please
feel free to answer part or all of my questions. In terms of
implementing aggregate and collect, I have been receiving the forum
digests for a few weeks and feel confident that you lovely folk on the
forum can help me trouble shoot anything that went terribly wrong in
the implementation or with the software.
A bit of background
I recently downloaded ODK collect on an android emulator and am
impressed with the potential of the tool. I have researched a number
of other possibilities out there for a researcher and this is by far
the most exciting tool out there. However, I am very intimidated by
trying to implement it. I have not even tried to use the aggregator
yet because I am concerned about creating forms. Our survey will be
about 1000 questions long with subforms, complex skip patterns,
possibly some repetition.
Forms and XHTML
One of my biggest concerns is that ODK build is not yet very mature.
It does not yet support skip patterns, subforms and what not so I
cannot program it myself eaisly. I don't have the computer skills and
the programming experience to code the forms in XHTML, nor do I really
have the time to teach it to myself. Are there programmers out there
(in the US, but also perhaps in east africa? that we could hire to
help code our survey?) How easy would they be to find? It seems that
XHTML is relatively new.
Data format
But I was wondering, what format is the output data in. It says on
the website that it exports to google spreadsheets. I have not yet
had the time to test out aggregate and am running into a road block
with the XHTML to test the format of output data for myself. So
perhaps people who have used the program can answer this question: can
google spreadsheets retain your labels. By this I mean, if you ask a
question such as What is your favorite color. Green (1), Blue (2) and
Red (3). Does the spreadsheet report 1,2,3 but also retain the
labels? In free data entry software such as epiinfo, you can export
this information with your database/spreadsheet and automatically load
it into your data analysis software such as Stata, SAS and SPSS. In
the end this saves a lot of time to have the labels imported in.
Codebook
Is there anyway to obtain a codebook or extract a codebook from your
survey. A codebook would be a printable sheet with every question
asked and the possible responses (in text) with their corresponding
numerical values. Again this would be very useful for the data
analysis.
Languages
In the demos of ODK, there is the possibility of switching between
languages in your survey, which is extremely useful. How would I go
about doing that?- i think I would like a general overview to
understand the process.
build is really designed for very basic forms. for 1000 question
forms, you might want to try purcforms
(http://code.google.com/p/purcforms/). if you need assistance, our
friends at dimagi are well-versed in form design. more importantly,
they can also connect you to companies in africa who can build forms
as well. this is part of their coded-in-country initiative
(http://www.dimagi.com/collaborate/coded-in-country/).
you can manually encode most unicode characters. languages that don't
work are complex scripts like hindi and arabic. this limitation is due
to the android renderer and it is a long standing android issue. one
way to get around it is to add audio clips or render the text as an
image and use that in place of the question text. of course, this
doesn't solve entering arabic or hindi as input...
···
On Thu, Oct 7, 2010 at 13:47, Mitch Sundt wrote:
> Hi Chloe,
>
> I will answer just a few of your questions ;-)
>
> For such large forms, we have been very intrigued by the XLS to XForm
> converter http://xform.childcount.org/ which allows you to enter a form with
> repeat groups rather easily as rows of entries in an Excel spreadsheet. It
> then converts this to a well-formed xform. This converter lacks support for
> branch logic, but most tools available do not support that and you will
> likely have to hand-code that logic in many cases -- it is just too hard to
> capture through a simple user interface. Once you generate the form using
> one of these tools, the branch logic resides in the model area and could
> probably be cut-and-pasted rather easily across your revisions whenever you
> revise different sections of the form as long as you do not change the field
> names (tags) in the form.
>
> With text-based forms such as XForms, there is no need to code the selection
> choice into an integer value for data processing. You can define it to be a
> (short) alphanumeric value (no spaces please!). e.g., 'highBloodPressure'
> or 'red'. This eliminates the need for a codebook. If you do need numeric
> codes, and therefore a codebook, you should definitely look at the XLS to
> XForm converter. I think the selection value lists (see the 2nd tab of the
> surveys-v0.2.xls "template" example on the above site) will exactly be the
> codebook that you seek.
>
> As for the output format, the data is transmitted off the phone as an xml
> document:
>
> xmlns="http://example.org/meta">
> yes
> V -14-4
> yes
> Zambezia
> Milange
> 10
> Milange
> 1
> Milange
> Urban
> Samora-Machel
> 2
> 66
> -16.9089355 36.75921051 635.0 4.0
> ...
>
>
> The field names are the tags in the xml format (e.g., "TextSection0_data").
> The values that were entered or populated via a calculation while filling
> out the form are between the start and end tags (e.g., "yes" for the
> TextSection0_data tag).
>
> These short xml documents are interpreted by the Aggregate server, and split
> into separate data fields. And the values for these data fields are then
> stored in different data columns. Multiple-choice selections are
> space-separated, hence the need for no spaces in the selection value being
> used. If you set up publishing into Google spreadsheet or fusion tables,
> these columns will appear in those tables. If you download the data via the
> Briefcase tool, they appear as separate columns in a .csv file.
>
> I'll let others talk about languages...
>
> Mitch
>
> On Thu, Oct 7, 2010 at 11:01 AM, Chloe wrote:
>>
>> Hi,
>>
>> I am a research assistant that wants to use ODK for our small study in
>> east africa. We want to use android based phones or tablet PCs. I
>> am coming from a strictly research background with very little
>> computer experience (other than an interest in technology)..so my
>> questions are definitely newbish. I have many questions, so please
>> feel free to answer part or all of my questions. In terms of
>> implementing aggregate and collect, I have been receiving the forum
>> digests for a few weeks and feel confident that you lovely folk on the
>> forum can help me trouble shoot anything that went terribly wrong in
>> the implementation or with the software.
>>
>> A bit of background
>> I recently downloaded ODK collect on an android emulator and am
>> impressed with the potential of the tool. I have researched a number
>> of other possibilities out there for a researcher and this is by far
>> the most exciting tool out there. However, I am very intimidated by
>> trying to implement it. I have not even tried to use the aggregator
>> yet because I am concerned about creating forms. Our survey will be
>> about 1000 questions long with subforms, complex skip patterns,
>> possibly some repetition.
>>
>> 1. Forms and XHTML
>> One of my biggest concerns is that ODK build is not yet very mature.
>> It does not yet support skip patterns, subforms and what not so I
>> cannot program it myself eaisly. I don't have the computer skills and
>> the programming experience to code the forms in XHTML, nor do I really
>> have the time to teach it to myself. Are there programmers out there
>> (in the US, but also perhaps in east africa? that we could hire to
>> help code our survey?) How easy would they be to find? It seems that
>> XHTML is relatively new.
>>
>> 2. Data format
>> But I was wondering, what format is the output data in. It says on
>> the website that it exports to google spreadsheets. I have not yet
>> had the time to test out aggregate and am running into a road block
>> with the XHTML to test the format of output data for myself. So
>> perhaps people who have used the program can answer this question: can
>> google spreadsheets retain your labels. By this I mean, if you ask a
>> question such as What is your favorite color. Green (1), Blue (2) and
>> Red (3). Does the spreadsheet report 1,2,3 but also retain the
>> labels? In free data entry software such as epiinfo, you can export
>> this information with your database/spreadsheet and automatically load
>> it into your data analysis software such as Stata, SAS and SPSS. In
>> the end this saves a lot of time to have the labels imported in.
>>
>> 3. Codebook
>> Is there anyway to obtain a codebook or extract a codebook from your
>> survey. A codebook would be a printable sheet with every question
>> asked and the possible responses (in text) with their corresponding
>> numerical values. Again this would be very useful for the data
>> analysis.
>>
>> 4. Languages
>> In the demos of ODK, there is the possibility of switching between
>> languages in your survey, which is extremely useful. How would I go
>> about doing that?- i think I would like a general overview to
>> understand the process.
>>
>> Thank you so much,
>>
>> Chloe
>>
>> --
>> Post: opendatakit@googlegroups.com
>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en
>
>
>
> --
> Mitch Sundt
> Software Engineer
> http://www.OpenDataKit.org
> University of Washington
> mitchellsundt@gmail.com
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
Adding to what anokwa has said.those references are really good.am working
with odk for cropmonitoring.a google sponsored project in Uganda.u can send
to me your survey details in pdf n i will create ua survey xforms n host
it.u will be testing it untill u are okay with it then u will pay me....etc
adding to mitch's responses...
build is really designed for very basic forms. for 1000 question
forms, you might want to try purcforms
(http://code.google.com/p/purcforms/). if you need assistance, our
friends at dimagi are well-versed in form design. more importantly,
they can also connect you to companies in africa who can build forms
as well. this is part of their coded-in-country initiative
(http://www.dimagi.com/collaborate/coded-in-country/).
you can manually encode most unicode characters. languages that don't
work are complex scripts like hindi and arabic. this limitation is due
to the android renderer and it is a long standing android issue. one
way to get around it is to add audio clips or render the text as an
image and use that in place of the question text. of course, this
doesn't solve entering arabic or hindi as input...
I will add a few notes as well.
We do population surveys in Africa, and our surveys are large, with complex
skip logic and data constraints. I will say that at about 300 questions, we
are pushing some limits. For example, the survey takes a little while to
load, and a little while to save. In earlier versions of ODK, this sometimes
caused a Force Close error and lost data.(0.2% of the time) Memory
management is better in the newer versions of ODK, but I am still
conservative in my coding.
I would be interested in what the list thinks of the size of this survey? I
have some fears that a 1000 question survey with multiple languages might
crash out. I estimate the XML would be in the 1 meg range, and once the data
is completed, especially if the answers are saved as text (red, blue,
yellow) instead of numeric values (1,2,3), the output could be really heavy.
Has anyone tested something this large? Load times and save times could be
an issue. It also depends on the hardware you are using.
I am curious about the content, at 300 questions, the surveys we do take
more than an hour to administer. Triple that, and you will be trying the
patience of the most ardent subject. Maybe you have an incentive for the
subject to participate, or a controlled environment to survey in that make
this a non-issue.
What else...I wouldn't go with the tablet, the phones are a more mature
platform and the questions fit nicely on the phone screen. Portable,
available. We use HTC MyTouch PDAs, great battery life, tough hardware. ODK
runs great on those.
Also, you don't have to use the Aggregate server to get your data out to a
format you can analyze. I say this because in East Africa you may not always
have access to internet, or it may be too expensive to put a SIM card in
every android. We developed the KoBo Post Processor to sync data from the
phones to your computer, then transcribe the data into CSVs, which can be
imported into any database or analytical tool, even something as simple as a
spreadsheet, or as complex as SPSS. KoBoPP is a good solution for working in
areas with limited connectivity, or with sensitive data that you don't want
to send up to a server.
I will add a few notes as well.
We do population surveys in Africa, and our surveys are large, with complex
skip logic and data constraints. I will say that at about 300 questions, we
are pushing some limits. For example, the survey takes a little while to
load, and a little while to save. In earlier versions of ODK, this sometimes
caused a Force Close error and lost data.(0.2% of the time) Memory
management is better in the newer versions of ODK, but I am still
conservative in my coding.
I would be interested in what the list thinks of the size of this survey? I
have some fears that a 1000 question survey with multiple languages might
crash out. I estimate the XML would be in the 1 meg range, and once the data
is completed, especially if the answers are saved as text (red, blue,
yellow) instead of numeric values (1,2,3), the output could be really heavy.
Has anyone tested something this large? Load times and save times could be
an issue. It also depends on the hardware you are using.
I am curious about the content, at 300 questions, the surveys we do take
more than an hour to administer. Triple that, and you will be trying the
patience of the most ardent subject. Maybe you have an incentive for the
subject to participate, or a controlled environment to survey in that make
this a non-issue.
What else...I wouldn't go with the tablet, the phones are a more mature
platform and the questions fit nicely on the phone screen. Portable,
available. We use HTC MyTouch PDAs, great battery life, tough hardware. ODK
runs great on those.
Also, you don't have to use the Aggregate server to get your data out to a
format you can analyze. I say this because in East Africa you may not always
have access to internet, or it may be too expensive to put a SIM card in
every android. We developed the KoBo Post Processor to sync data from the
phones to your computer, then transcribe the data into CSVs, which can be
imported into any database or analytical tool, even something as simple as a
spreadsheet, or as complex as SPSS. KoBoPP is a good solution for working in
areas with limited connectivity, or with sensitive data that you don't want
to send up to a server.
