Hey Folks,
Just wanted to give a quick update on the CommCare 1.1 client's workplan.
We're currently finishing up QA Testing of the client. We're on a stable
release branch (For those of you using data.cchq, the Release Candidates are
the 9000 series), and have finished up fixing the last round of bugs from
QA. The current plan is to get a release put together by the end of this
week or the beginning of next week. I'll keep you guys informed of progress.
The unstable version (1.2) is where new feature dev will be happening. On
dev.cchq this is still the 7000 series of builds.
-Clayton
Clayton, thanks for the update. When this is released, can you also provide
us with information on:
-
What features are new in CC 1.1 ?
-
What QA and testing steps have been completed? This can help us plan what
QA we should do on our side.
thanks!
Jon
···
On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims wrote:
Hey Folks,
Just wanted to give a quick update on the CommCare 1.1 client's workplan.
We're currently finishing up QA Testing of the client. We're on a stable
release branch (For those of you using data.cchq, the Release Candidates are
the 9000 series), and have finished up fixing the last round of bugs from
QA. The current plan is to get a release put together by the end of this
week or the beginning of next week. I'll keep you guys informed of progress.
The unstable version (1.2) is where new feature dev will be happening. On
dev.cchq this is still the 7000 series of builds.
-Clayton
Jon,
Absolutely.
1.1 is largely a bug fix and stability release. We've addressed a huge
number of bugs in both the core JR code and the CommCare libraries
Other big points
- Official support for, and big improvements to the usefulness of the One
Question per Screen entry mode
- Official support for builds on multiple devices (native input for S40's,
qwerty S60 devices, even windows mobile)
- Inclusion of the Sense UI into the builds, which streamlines entry for
forms which use primarily audio and images to convey information
- Better integration with CommCareHQ and improved workflow for registering
users when no connection is available.
- Support for form transmission over SMS
- Notifications and tracking of the phone's time settings to catch and
report phones whose date is hugely out of sync.
- Support for Syncing regularly (rather than just OTA Restoring once)
We have a QA testing cycle comprised of a test application with the standard
CommCare form actions (OTA restore, register cases, close cases, register
referrals, close referrals, etc), that we run through each time we commit
any changes (bug fixes, etc) to the stable QA branch. We've been cataloging
errors on that branch, fixing, and retesting. What we haven't been testing
in full is the content of every available CommCare app (The
xforms/suites/profiles for the existing apps), so it would be good to run
through those specifically.
-Clayton
···
On Thu, Apr 7, 2011 at 3:14 PM, Jonathan Payne wrote:
Clayton, thanks for the update. When this is released, can you also provide
us with information on:
-
What features are new in CC 1.1 ?
-
What QA and testing steps have been completed? This can help us plan
what QA we should do on our side.
thanks!
Jon
On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims csims@dimagi.com wrote:
Hey Folks,
Just wanted to give a quick update on the CommCare 1.1 client's workplan.
We're currently finishing up QA Testing of the client. We're on a stable
release branch (For those of you using data.cchq, the Release Candidates are
the 9000 series), and have finished up fixing the last round of bugs from
QA. The current plan is to get a release put together by the end of this
week or the beginning of next week. I'll keep you guys informed of progress.
The unstable version (1.2) is where new feature dev will be happening. On
dev.cchq this is still the 7000 series of builds.
-Clayton
The list of new features looks fantastic. I had a couple quick questions:
-
Can you say more about the time setting tracking? It's definitely
needed. What happens when the system detects that phone might have the
wrong date? Does it message the user directly, or is there a CCHQ
feature that messages some sort of supervisor?
-
How does syncing regularly work? If it detects the phone is out of
sync, will it "spoof" submissions to CCHQ to make it synchronize, or
will it add/delete cases on the handset?
Brian
···
On Thu, Apr 7, 2011 at 12:29 PM, Clayton Sims wrote:
> Jon,
> Absolutely.
> 1)
> 1.1 is largely a bug fix and stability release. We've addressed a huge
> number of bugs in both the core JR code and the CommCare libraries
> Other big points
> * Official support for, and big improvements to the usefulness of the One
> Question per Screen entry mode
> * Official support for builds on multiple devices (native input for S40's,
> qwerty S60 devices, even windows mobile)
> * Inclusion of the Sense UI into the builds, which streamlines entry for
> forms which use primarily audio and images to convey information
> * Better integration with CommCareHQ and improved workflow for registering
> users when no connection is available.
> * Support for form transmission over SMS
> * Notifications and tracking of the phone's time settings to catch and
> report phones whose date is hugely out of sync.
> * Support for Syncing regularly (rather than just OTA Restoring once)
> 2)
> We have a QA testing cycle comprised of a test application with the standard
> CommCare form actions (OTA restore, register cases, close cases, register
> referrals, close referrals, etc), that we run through each time we commit
> any changes (bug fixes, etc) to the stable QA branch. We've been cataloging
> errors on that branch, fixing, and retesting. What we haven't been testing
> in full is the content of every available CommCare app (The
> xforms/suites/profiles for the existing apps), so it would be good to run
> through those specifically.
> -Clayton
>
> On Thu, Apr 7, 2011 at 3:14 PM, Jonathan Payne wrote:
>>
>> Clayton, thanks for the update. When this is released, can you also
>> provide us with information on:
>> 1) What features are new in CC 1.1 ?
>> 2) What QA and testing steps have been completed? This can help us plan
>> what QA we should do on our side.
>> thanks!
>> Jon
>> On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims wrote:
>>>
>>> Hey Folks,
>>> Just wanted to give a quick update on the CommCare 1.1 client's workplan.
>>> We're currently finishing up QA Testing of the client. We're on a stable
>>> release branch (For those of you using data.cchq, the Release Candidates are
>>> the 9000 series), and have finished up fixing the last round of bugs from
>>> QA. The current plan is to get a release put together by the end of this
>>> week or the beginning of next week. I'll keep you guys informed of progress.
>>> The unstable version (1.2) is where new feature dev will be happening. On
>>> dev.cchq this is still the 7000 series of builds.
>>> -Clayton
>
>
Brian,
- So there are two different things that we've set up.
A) The phone now includes the appropriately formatted header in every http
connection to tell the server what time (in UTC) that it the phone thinks it
is. HQ is receiving this info and both logging it (so we can eventually
notify someone in the program) and noting it in the submission.
B) The phone also parses down the server time in each connection and looking
for gross inconsistencies. If this happens, the user will be notified at the
next login (at a max, once per day) that their phone's time appears to be
wrong.
- The syncing is structured somewhat differently. Essentially there is a
flag you set in your application to be in "Sync" mode instead of an expected
offline mode. In sync mode, the "send all unsent" option is replaced by a
sync option, and when you press it it submits all of your unsent forms and
requests a restore packet from the server. If the server supports a sync
token, it'll incrementally send back only the differences, otherwise it will
just dump down the entire active data set (and the phone will just reconcile
the differences).
-Clayton
···
On Thu, Apr 7, 2011 at 3:57 PM, Brian DeRenzi wrote:
The list of new features looks fantastic. I had a couple quick questions:
-
Can you say more about the time setting tracking? It's definitely
needed. What happens when the system detects that phone might have the
wrong date? Does it message the user directly, or is there a CCHQ
feature that messages some sort of supervisor?
-
How does syncing regularly work? If it detects the phone is out of
sync, will it "spoof" submissions to CCHQ to make it synchronize, or
will it add/delete cases on the handset?
Brian
On Thu, Apr 7, 2011 at 12:29 PM, Clayton Sims csims@dimagi.com wrote:
Jon,
Absolutely.
1)
1.1 is largely a bug fix and stability release. We've addressed a huge
number of bugs in both the core JR code and the CommCare libraries
Other big points
- Official support for, and big improvements to the usefulness of the One
Question per Screen entry mode
- Official support for builds on multiple devices (native input for
S40's,
qwerty S60 devices, even windows mobile)
- Inclusion of the Sense UI into the builds, which streamlines entry for
forms which use primarily audio and images to convey information
- Better integration with CommCareHQ and improved workflow for
registering
users when no connection is available.
- Support for form transmission over SMS
- Notifications and tracking of the phone's time settings to catch and
report phones whose date is hugely out of sync.
- Support for Syncing regularly (rather than just OTA Restoring once)
We have a QA testing cycle comprised of a test application with the
standard
CommCare form actions (OTA restore, register cases, close cases, register
referrals, close referrals, etc), that we run through each time we commit
any changes (bug fixes, etc) to the stable QA branch. We've been
cataloging
errors on that branch, fixing, and retesting. What we haven't been
testing
in full is the content of every available CommCare app (The
xforms/suites/profiles for the existing apps), so it would be good to run
through those specifically.
-Clayton
On Thu, Apr 7, 2011 at 3:14 PM, Jonathan Payne paynejd@gmail.com wrote:
Clayton, thanks for the update. When this is released, can you also
provide us with information on:
- What features are new in CC 1.1 ?
- What QA and testing steps have been completed? This can help us plan
what QA we should do on our side.
thanks!
Jon
On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims csims@dimagi.com wrote:
Hey Folks,
Just wanted to give a quick update on the CommCare 1.1 client's
workplan.
We're currently finishing up QA Testing of the client. We're on a
stable
release branch (For those of you using data.cchq, the
Release Candidates are
the 9000 series), and have finished up fixing the last round of bugs
from
QA. The current plan is to get a release put together by the end of
this
week or the beginning of next week. I'll keep you guys informed of
progress.
The unstable version (1.2) is where new feature dev will be happening.
On
dev.cchq this is still the 7000 series of builds.
-Clayton
Hi Clayton,
Thanks for this info. For 1B, it sounds like that's something that all
CommCare folks will have to add to training once they switch to 1.1,
right? That is, we need to tell CHWs what to do when you get the "Your
phone time is probably wrong" message. Just out of curiosity, what
threshold are you using?
It's really frustrating, but the cell towers in TZ (at least when I
was there and on the Celtel network) don't support the auto-update
time feature. That would solve so much... I wonder if that's a
conscious decision by the telco in order to let people put their
phones in swahili-time if they so desire.
For #2, it sounds like that's something for a field implementer to do,
correct? Not an action that a CHW/end user will be doing? (at least
for now in Dodoma)
Brian
···
On Fri, Apr 8, 2011 at 3:21 PM, Clayton Sims wrote:
> Brian,
> 1) So there are two different things that we've set up.
> A) The phone now includes the appropriately formatted header in every http
> connection to tell the server what time (in UTC) that it the phone thinks it
> is. HQ is receiving this info and both logging it (so we can eventually
> notify someone in the program) and noting it in the submission.
> B) The phone also parses down the server time in each connection and looking
> for gross inconsistencies. If this happens, the user will be notified at the
> next login (at a max, once per day) that their phone's time appears to be
> wrong.
> 2) The syncing is structured somewhat differently. Essentially there is a
> flag you set in your application to be in "Sync" mode instead of an expected
> offline mode. In sync mode, the "send all unsent" option is replaced by a
> sync option, and when you press it it submits all of your unsent forms and
> requests a restore packet from the server. If the server supports a sync
> token, it'll incrementally send back only the differences, otherwise it will
> just dump down the entire active data set (and the phone will just reconcile
> the differences).
> -Clayton
>
> On Thu, Apr 7, 2011 at 3:57 PM, Brian DeRenzi wrote:
>>
>> The list of new features looks fantastic. I had a couple quick questions:
>>
>> 1. Can you say more about the time setting tracking? It's definitely
>> needed. What happens when the system detects that phone might have the
>> wrong date? Does it message the user directly, or is there a CCHQ
>> feature that messages some sort of supervisor?
>>
>> 2. How does syncing regularly work? If it detects the phone is out of
>> sync, will it "spoof" submissions to CCHQ to make it synchronize, or
>> will it add/delete cases on the handset?
>>
>> Brian
>>
>>
>> On Thu, Apr 7, 2011 at 12:29 PM, Clayton Sims wrote:
>> > Jon,
>> > Absolutely.
>> > 1)
>> > 1.1 is largely a bug fix and stability release. We've addressed a huge
>> > number of bugs in both the core JR code and the CommCare libraries
>> > Other big points
>> > * Official support for, and big improvements to the usefulness of the
>> > One
>> > Question per Screen entry mode
>> > * Official support for builds on multiple devices (native input for
>> > S40's,
>> > qwerty S60 devices, even windows mobile)
>> > * Inclusion of the Sense UI into the builds, which streamlines entry for
>> > forms which use primarily audio and images to convey information
>> > * Better integration with CommCareHQ and improved workflow for
>> > registering
>> > users when no connection is available.
>> > * Support for form transmission over SMS
>> > * Notifications and tracking of the phone's time settings to catch and
>> > report phones whose date is hugely out of sync.
>> > * Support for Syncing regularly (rather than just OTA Restoring once)
>> > 2)
>> > We have a QA testing cycle comprised of a test application with the
>> > standard
>> > CommCare form actions (OTA restore, register cases, close cases,
>> > register
>> > referrals, close referrals, etc), that we run through each time we
>> > commit
>> > any changes (bug fixes, etc) to the stable QA branch. We've been
>> > cataloging
>> > errors on that branch, fixing, and retesting. What we haven't been
>> > testing
>> > in full is the content of every available CommCare app (The
>> > xforms/suites/profiles for the existing apps), so it would be good to
>> > run
>> > through those specifically.
>> > -Clayton
>> >
>> > On Thu, Apr 7, 2011 at 3:14 PM, Jonathan Payne wrote:
>> >>
>> >> Clayton, thanks for the update. When this is released, can you also
>> >> provide us with information on:
>> >> 1) What features are new in CC 1.1 ?
>> >> 2) What QA and testing steps have been completed? This can help us plan
>> >> what QA we should do on our side.
>> >> thanks!
>> >> Jon
>> >> On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims wrote:
>> >>>
>> >>> Hey Folks,
>> >>> Just wanted to give a quick update on the CommCare 1.1 client's
>> >>> workplan.
>> >>> We're currently finishing up QA Testing of the client. We're on a
>> >>> stable
>> >>> release branch (For those of you using data.cchq, the
>> >>> Release Candidates are
>> >>> the 9000 series), and have finished up fixing the last round of bugs
>> >>> from
>> >>> QA. The current plan is to get a release put together by the end of
>> >>> this
>> >>> week or the beginning of next week. I'll keep you guys informed of
>> >>> progress.
>> >>> The unstable version (1.2) is where new feature dev will be happening.
>> >>> On
>> >>> dev.cchq this is still the 7000 series of builds.
>> >>> -Clayton
>> >
>> >
>
>
Hey Clayton,
Which of the new changes/fixes/etc listed are user facing? You mention
improved workflow for registering users among other things.
It'd be great to know how the changes that we'll have to communicate and
potentially even train the users on.
Thanks,
Nick
Nick P. Amland
CommCare Field Fellow
Dimagi, Inc.
Dodoma, Tanzania
Google Voice: 253.642.7790
TZ Mobile: +255 762 740 996
Email: namland@dimagi.com namland08@gmail.com
···
On Sun, Apr 10, 2011 at 3:02 AM, Brian DeRenzi wrote:
Hi Clayton,
Thanks for this info. For 1B, it sounds like that's something that all
CommCare folks will have to add to training once they switch to 1.1,
right? That is, we need to tell CHWs what to do when you get the "Your
phone time is probably wrong" message. Just out of curiosity, what
threshold are you using?
It's really frustrating, but the cell towers in TZ (at least when I
was there and on the Celtel network) don't support the auto-update
time feature. That would solve so much... I wonder if that's a
conscious decision by the telco in order to let people put their
phones in swahili-time if they so desire.
For #2, it sounds like that's something for a field implementer to do,
correct? Not an action that a CHW/end user will be doing? (at least
for now in Dodoma)
Brian
On Fri, Apr 8, 2011 at 3:21 PM, Clayton Sims csims@dimagi.com wrote:
Brian,
- So there are two different things that we've set up.
A) The phone now includes the appropriately formatted header in every
http
connection to tell the server what time (in UTC) that it the phone thinks
it
is. HQ is receiving this info and both logging it (so we can eventually
notify someone in the program) and noting it in the submission.
B) The phone also parses down the server time in each connection and
looking
for gross inconsistencies. If this happens, the user will be notified at
the
next login (at a max, once per day) that their phone's time appears to be
wrong.
- The syncing is structured somewhat differently. Essentially there is a
flag you set in your application to be in "Sync" mode instead of an
expected
offline mode. In sync mode, the "send all unsent" option is replaced by a
sync option, and when you press it it submits all of your unsent forms
and
requests a restore packet from the server. If the server supports a sync
token, it'll incrementally send back only the differences, otherwise it
will
just dump down the entire active data set (and the phone will just
reconcile
the differences).
-Clayton
On Thu, Apr 7, 2011 at 3:57 PM, Brian DeRenzi bderenzi@gmail.com wrote:
The list of new features looks fantastic. I had a couple quick
questions:
-
Can you say more about the time setting tracking? It's definitely
needed. What happens when the system detects that phone might have the
wrong date? Does it message the user directly, or is there a CCHQ
feature that messages some sort of supervisor?
-
How does syncing regularly work? If it detects the phone is out of
sync, will it "spoof" submissions to CCHQ to make it synchronize, or
will it add/delete cases on the handset?
Brian
On Thu, Apr 7, 2011 at 12:29 PM, Clayton Sims csims@dimagi.com wrote:
Jon,
Absolutely.
1)
1.1 is largely a bug fix and stability release. We've addressed a huge
number of bugs in both the core JR code and the CommCare libraries
Other big points
- Official support for, and big improvements to the usefulness of the
One
Question per Screen entry mode
- Official support for builds on multiple devices (native input for
S40's,
qwerty S60 devices, even windows mobile)
- Inclusion of the Sense UI into the builds, which streamlines entry
for
forms which use primarily audio and images to convey information
- Better integration with CommCareHQ and improved workflow for
registering
users when no connection is available.
- Support for form transmission over SMS
- Notifications and tracking of the phone's time settings to catch and
report phones whose date is hugely out of sync.
- Support for Syncing regularly (rather than just OTA Restoring once)
We have a QA testing cycle comprised of a test application with the
standard
CommCare form actions (OTA restore, register cases, close cases,
register
referrals, close referrals, etc), that we run through each time we
commit
any changes (bug fixes, etc) to the stable QA branch. We've been
cataloging
errors on that branch, fixing, and retesting. What we haven't been
testing
in full is the content of every available CommCare app (The
xforms/suites/profiles for the existing apps), so it would be good to
run
through those specifically.
-Clayton
On Thu, Apr 7, 2011 at 3:14 PM, Jonathan Payne paynejd@gmail.com wrote:
Clayton, thanks for the update. When this is released, can you also
provide us with information on:
- What features are new in CC 1.1 ?
- What QA and testing steps have been completed? This can help us
plan
what QA we should do on our side.
thanks!
Jon
On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims csims@dimagi.com wrote:
Hey Folks,
Just wanted to give a quick update on the CommCare 1.1 client's
workplan.
We're currently finishing up QA Testing of the client. We're on a
stable
release branch (For those of you using data.cchq, the
Release Candidates are
the 9000 series), and have finished up fixing the last round of bugs
from
QA. The current plan is to get a release put together by the end of
this
week or the beginning of next week. I'll keep you guys informed of
progress.
The unstable version (1.2) is where new feature dev will be
happening.
On
dev.cchq this is still the 7000 series of builds.
-Clayton
Yeah, adding training for setting the phone time is a good plan. Even if the
towers supported the auto-time feature, it's not enabled by default on the
Nokias, and even if you turn it on, the flag to auto-update gets cleared
when the battery is removed, so it's not a great situation on either side.
For #2 the CHW/end user would be doing the sync (It's just like doing a Send
all Unsent), but only on deployments where the profile is set to be in sync
mode, so I don't think anyone would be using it by default just yet.
-Clayton
···
On Sat, Apr 9, 2011 at 8:02 PM, Brian DeRenzi wrote:
Hi Clayton,
Thanks for this info. For 1B, it sounds like that's something that all
CommCare folks will have to add to training once they switch to 1.1,
right? That is, we need to tell CHWs what to do when you get the "Your
phone time is probably wrong" message. Just out of curiosity, what
threshold are you using?
It's really frustrating, but the cell towers in TZ (at least when I
was there and on the Celtel network) don't support the auto-update
time feature. That would solve so much... I wonder if that's a
conscious decision by the telco in order to let people put their
phones in swahili-time if they so desire.
For #2, it sounds like that's something for a field implementer to do,
correct? Not an action that a CHW/end user will be doing? (at least
for now in Dodoma)
Brian
On Fri, Apr 8, 2011 at 3:21 PM, Clayton Sims csims@dimagi.com wrote:
Brian,
- So there are two different things that we've set up.
A) The phone now includes the appropriately formatted header in every
http
connection to tell the server what time (in UTC) that it the phone thinks
it
is. HQ is receiving this info and both logging it (so we can eventually
notify someone in the program) and noting it in the submission.
B) The phone also parses down the server time in each connection and
looking
for gross inconsistencies. If this happens, the user will be notified at
the
next login (at a max, once per day) that their phone's time appears to be
wrong.
- The syncing is structured somewhat differently. Essentially there is a
flag you set in your application to be in "Sync" mode instead of an
expected
offline mode. In sync mode, the "send all unsent" option is replaced by a
sync option, and when you press it it submits all of your unsent forms
and
requests a restore packet from the server. If the server supports a sync
token, it'll incrementally send back only the differences, otherwise it
will
just dump down the entire active data set (and the phone will just
reconcile
the differences).
-Clayton
On Thu, Apr 7, 2011 at 3:57 PM, Brian DeRenzi bderenzi@gmail.com wrote:
The list of new features looks fantastic. I had a couple quick
questions:
-
Can you say more about the time setting tracking? It's definitely
needed. What happens when the system detects that phone might have the
wrong date? Does it message the user directly, or is there a CCHQ
feature that messages some sort of supervisor?
-
How does syncing regularly work? If it detects the phone is out of
sync, will it "spoof" submissions to CCHQ to make it synchronize, or
will it add/delete cases on the handset?
Brian
On Thu, Apr 7, 2011 at 12:29 PM, Clayton Sims csims@dimagi.com wrote:
Jon,
Absolutely.
1)
1.1 is largely a bug fix and stability release. We've addressed a huge
number of bugs in both the core JR code and the CommCare libraries
Other big points
- Official support for, and big improvements to the usefulness of the
One
Question per Screen entry mode
- Official support for builds on multiple devices (native input for
S40's,
qwerty S60 devices, even windows mobile)
- Inclusion of the Sense UI into the builds, which streamlines entry
for
forms which use primarily audio and images to convey information
- Better integration with CommCareHQ and improved workflow for
registering
users when no connection is available.
- Support for form transmission over SMS
- Notifications and tracking of the phone's time settings to catch and
report phones whose date is hugely out of sync.
- Support for Syncing regularly (rather than just OTA Restoring once)
We have a QA testing cycle comprised of a test application with the
standard
CommCare form actions (OTA restore, register cases, close cases,
register
referrals, close referrals, etc), that we run through each time we
commit
any changes (bug fixes, etc) to the stable QA branch. We've been
cataloging
errors on that branch, fixing, and retesting. What we haven't been
testing
in full is the content of every available CommCare app (The
xforms/suites/profiles for the existing apps), so it would be good to
run
through those specifically.
-Clayton
On Thu, Apr 7, 2011 at 3:14 PM, Jonathan Payne paynejd@gmail.com wrote:
Clayton, thanks for the update. When this is released, can you also
provide us with information on:
- What features are new in CC 1.1 ?
- What QA and testing steps have been completed? This can help us
plan
what QA we should do on our side.
thanks!
Jon
On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims csims@dimagi.com wrote:
Hey Folks,
Just wanted to give a quick update on the CommCare 1.1 client's
workplan.
We're currently finishing up QA Testing of the client. We're on a
stable
release branch (For those of you using data.cchq, the
Release Candidates are
the 9000 series), and have finished up fixing the last round of bugs
from
QA. The current plan is to get a release put together by the end of
this
week or the beginning of next week. I'll keep you guys informed of
progress.
The unstable version (1.2) is where new feature dev will be
happening.
On
dev.cchq this is still the 7000 series of builds.
-Clayton
Dear commcare users
I trying to build the commcare application using CommCareHQ version 1.0
I did the configuration which I thought I did right but when I tried to
build, I got error messages as bellow.
"Module crs csi
<Log In :: CommCare HQ - CommCare HQ
5cc5/?edit=true&m=0&build_errors=e86716bed5bc57c5a9f9323bdd703e03> uses
cases but doesn't have detail screens configured for cases.
Module crs csi
<Log In :: CommCare HQ - CommCare HQ
5cc5/?edit=true&m=0&build_errors=e86716bed5bc57c5a9f9323bdd703e03> uses
referrals but doesn't have detail screens configured for referrals."
Can someone help me figure out what does that mean?
Gayo
Hey Clayton,
I was wondering if you could give me a quick list of all the features (from
1.1) that will affecting the user experience (i.e. UI, data entry workflow,
etc.). If necessary, a list of how it's changed from 1.0.
We'll definitely have to train users on anything that changes other than
something really minor.
Thanks,
Nick
Nick P. Amland
CommCare Field Fellow
Dimagi, Inc.
Dodoma, Tanzania
Google Voice: 253.642.7790
TZ Mobile: +255 762 740 996
Email: namland@dimagi.com namland08@gmail.com
···
On Mon, Apr 11, 2011 at 12:19 AM, Nick Amland wrote:
Hey Clayton,
Which of the new changes/fixes/etc listed are user facing? You mention
improved workflow for registering users among other things.
It'd be great to know how the changes that we'll have to communicate and
potentially even train the users on.
Thanks,
Nick
Nick P. Amland
CommCare Field Fellow
Dimagi, Inc.
Dodoma, Tanzania
Google Voice: 253.642.7790
TZ Mobile: +255 762 740 996
Email: namland@dimagi.com namland08@gmail.com
On Sun, Apr 10, 2011 at 3:02 AM, Brian DeRenzi bderenzi@gmail.com wrote:
Hi Clayton,
Thanks for this info. For 1B, it sounds like that's something that all
CommCare folks will have to add to training once they switch to 1.1,
right? That is, we need to tell CHWs what to do when you get the "Your
phone time is probably wrong" message. Just out of curiosity, what
threshold are you using?
It's really frustrating, but the cell towers in TZ (at least when I
was there and on the Celtel network) don't support the auto-update
time feature. That would solve so much... I wonder if that's a
conscious decision by the telco in order to let people put their
phones in swahili-time if they so desire.
For #2, it sounds like that's something for a field implementer to do,
correct? Not an action that a CHW/end user will be doing? (at least
for now in Dodoma)
Brian
On Fri, Apr 8, 2011 at 3:21 PM, Clayton Sims csims@dimagi.com wrote:
Brian,
- So there are two different things that we've set up.
A) The phone now includes the appropriately formatted header in every
http
connection to tell the server what time (in UTC) that it the phone
thinks it
is. HQ is receiving this info and both logging it (so we can eventually
notify someone in the program) and noting it in the submission.
B) The phone also parses down the server time in each connection and
looking
for gross inconsistencies. If this happens, the user will be notified at
the
next login (at a max, once per day) that their phone's time appears to
be
wrong.
- The syncing is structured somewhat differently. Essentially there is
a
flag you set in your application to be in "Sync" mode instead of an
expected
offline mode. In sync mode, the "send all unsent" option is replaced by
a
sync option, and when you press it it submits all of your unsent forms
and
requests a restore packet from the server. If the server supports a sync
token, it'll incrementally send back only the differences, otherwise it
will
just dump down the entire active data set (and the phone will just
reconcile
the differences).
-Clayton
On Thu, Apr 7, 2011 at 3:57 PM, Brian DeRenzi bderenzi@gmail.com wrote:
The list of new features looks fantastic. I had a couple quick
questions:
-
Can you say more about the time setting tracking? It's definitely
needed. What happens when the system detects that phone might have the
wrong date? Does it message the user directly, or is there a CCHQ
feature that messages some sort of supervisor?
-
How does syncing regularly work? If it detects the phone is out of
sync, will it "spoof" submissions to CCHQ to make it synchronize, or
will it add/delete cases on the handset?
Brian
On Thu, Apr 7, 2011 at 12:29 PM, Clayton Sims csims@dimagi.com wrote:
Jon,
Absolutely.
1)
1.1 is largely a bug fix and stability release. We've addressed a
huge
number of bugs in both the core JR code and the CommCare libraries
Other big points
- Official support for, and big improvements to the usefulness of the
One
Question per Screen entry mode
- Official support for builds on multiple devices (native input for
S40's,
qwerty S60 devices, even windows mobile)
- Inclusion of the Sense UI into the builds, which streamlines entry
for
forms which use primarily audio and images to convey information
- Better integration with CommCareHQ and improved workflow for
registering
users when no connection is available.
- Support for form transmission over SMS
- Notifications and tracking of the phone's time settings to catch
and
report phones whose date is hugely out of sync.
- Support for Syncing regularly (rather than just OTA Restoring once)
We have a QA testing cycle comprised of a test application with the
standard
CommCare form actions (OTA restore, register cases, close cases,
register
referrals, close referrals, etc), that we run through each time we
commit
any changes (bug fixes, etc) to the stable QA branch. We've been
cataloging
errors on that branch, fixing, and retesting. What we haven't been
testing
in full is the content of every available CommCare app (The
xforms/suites/profiles for the existing apps), so it would be good to
run
through those specifically.
-Clayton
On Thu, Apr 7, 2011 at 3:14 PM, Jonathan Payne paynejd@gmail.com wrote:
Clayton, thanks for the update. When this is released, can you also
provide us with information on:
- What features are new in CC 1.1 ?
- What QA and testing steps have been completed? This can help us
plan
what QA we should do on our side.
thanks!
Jon
On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims csims@dimagi.com wrote:
Hey Folks,
Just wanted to give a quick update on the CommCare 1.1 client's
workplan.
We're currently finishing up QA Testing of the client. We're on a
stable
release branch (For those of you using data.cchq, the
Release Candidates are
the 9000 series), and have finished up fixing the last round of
bugs
from
QA. The current plan is to get a release put together by the end of
this
week or the beginning of next week. I'll keep you guys informed of
progress.
The unstable version (1.2) is where new feature dev will be
happening.
On
dev.cchq this is still the 7000 series of builds.
-Clayton
Hi Gayo,
Yes. I see how this message could be quite cryptic. Let me explain:
When you have a form that requires you to select a case, the phone needs to
know how to list cases on the screen. You can do that by configuring "detail
screens" for your cases (and referrals) by going to the module settings (the
error message should have the link in it. The "short" screens are what show
up when it's listing all the cases; the "long" screens are the fuller
version that contains all the information about the case (that you think is
relevant).
I hope that this helps you and others. We will be adding documentation to
the site itself to make this clearer.
Cheers,
Danny
···
2011/4/12 gayo
Dear commcare users
I trying to build the commcare application using CommCareHQ version 1.0
I did the configuration which I thought I did right but when I tried to
build, I got error messages as bellow.
"Module crs csihttps://www.commcarehq.org/a/crs.csi/apps/view/13fb26d1d491f89636a699ddf7fa5cc5/?edit=true&m=0&build_errors=e86716bed5bc57c5a9f9323bdd703e03uses cases but doesn't have detail screens configured for cases.
Module crs csihttps://www.commcarehq.org/a/crs.csi/apps/view/13fb26d1d491f89636a699ddf7fa5cc5/?edit=true&m=0&build_errors=e86716bed5bc57c5a9f9323bdd703e03uses referrals but doesn't have detail screens configured for referrals."
Can someone help me figure out what does that mean?
Gayo
Clayton, I can work with you to put this together so we can have it on
the wiki as well.
···
On Wed, Apr 20, 2011 at 5:26 AM, Nick Amland wrote:
> Hey Clayton,
> I was wondering if you could give me a quick list of all the features (from
> 1.1) that will affecting the user experience (i.e. UI, data entry workflow,
> etc.). If necessary, a list of how it's changed from 1.0.
> We'll definitely have to train users on anything that changes other than
> something really minor.
> Thanks,
> Nick
> Nick P. Amland
> CommCare Field Fellow
> Dimagi, Inc.
> Dodoma, Tanzania
> Google Voice: 253.642.7790
> TZ Mobile: +255 762 740 996
> Email: namland@dimagi.com
>
>
> On Mon, Apr 11, 2011 at 12:19 AM, Nick Amland wrote:
>>
>> Hey Clayton,
>> Which of the new changes/fixes/etc listed are user facing? You mention
>> improved workflow for registering users among other things.
>> It'd be great to know how the changes that we'll have to communicate and
>> potentially even train the users on.
>> Thanks,
>> Nick
>>
>> Nick P. Amland
>> CommCare Field Fellow
>> Dimagi, Inc.
>> Dodoma, Tanzania
>> Google Voice: 253.642.7790
>> TZ Mobile: +255 762 740 996
>> Email: namland@dimagi.com
>>
>>
>> On Sun, Apr 10, 2011 at 3:02 AM, Brian DeRenzi wrote:
>>>
>>> Hi Clayton,
>>>
>>> Thanks for this info. For 1B, it sounds like that's something that all
>>> CommCare folks will have to add to training once they switch to 1.1,
>>> right? That is, we need to tell CHWs what to do when you get the "Your
>>> phone time is probably wrong" message. Just out of curiosity, what
>>> threshold are you using?
>>>
>>> It's really frustrating, but the cell towers in TZ (at least when I
>>> was there and on the Celtel network) don't support the auto-update
>>> time feature. That would solve so much... I wonder if that's a
>>> conscious decision by the telco in order to let people put their
>>> phones in swahili-time if they so desire.
>>>
>>> For #2, it sounds like that's something for a field implementer to do,
>>> correct? Not an action that a CHW/end user will be doing? (at least
>>> for now in Dodoma)
>>>
>>> Brian
>>>
>>>
>>> On Fri, Apr 8, 2011 at 3:21 PM, Clayton Sims wrote:
>>> > Brian,
>>> > 1) So there are two different things that we've set up.
>>> > A) The phone now includes the appropriately formatted header in every
>>> > http
>>> > connection to tell the server what time (in UTC) that it the phone
>>> > thinks it
>>> > is. HQ is receiving this info and both logging it (so we can eventually
>>> > notify someone in the program) and noting it in the submission.
>>> > B) The phone also parses down the server time in each connection and
>>> > looking
>>> > for gross inconsistencies. If this happens, the user will be notified
>>> > at the
>>> > next login (at a max, once per day) that their phone's time appears to
>>> > be
>>> > wrong.
>>> > 2) The syncing is structured somewhat differently. Essentially there is
>>> > a
>>> > flag you set in your application to be in "Sync" mode instead of an
>>> > expected
>>> > offline mode. In sync mode, the "send all unsent" option is replaced by
>>> > a
>>> > sync option, and when you press it it submits all of your unsent forms
>>> > and
>>> > requests a restore packet from the server. If the server supports a
>>> > sync
>>> > token, it'll incrementally send back only the differences, otherwise it
>>> > will
>>> > just dump down the entire active data set (and the phone will just
>>> > reconcile
>>> > the differences).
>>> > -Clayton
>>> >
>>> > On Thu, Apr 7, 2011 at 3:57 PM, Brian DeRenzi wrote:
>>> >>
>>> >> The list of new features looks fantastic. I had a couple quick
>>> >> questions:
>>> >>
>>> >> 1. Can you say more about the time setting tracking? It's definitely
>>> >> needed. What happens when the system detects that phone might have the
>>> >> wrong date? Does it message the user directly, or is there a CCHQ
>>> >> feature that messages some sort of supervisor?
>>> >>
>>> >> 2. How does syncing regularly work? If it detects the phone is out of
>>> >> sync, will it "spoof" submissions to CCHQ to make it synchronize, or
>>> >> will it add/delete cases on the handset?
>>> >>
>>> >> Brian
>>> >>
>>> >>
>>> >> On Thu, Apr 7, 2011 at 12:29 PM, Clayton Sims wrote:
>>> >> > Jon,
>>> >> > Absolutely.
>>> >> > 1)
>>> >> > 1.1 is largely a bug fix and stability release. We've addressed a
>>> >> > huge
>>> >> > number of bugs in both the core JR code and the CommCare libraries
>>> >> > Other big points
>>> >> > * Official support for, and big improvements to the usefulness of
>>> >> > the
>>> >> > One
>>> >> > Question per Screen entry mode
>>> >> > * Official support for builds on multiple devices (native input for
>>> >> > S40's,
>>> >> > qwerty S60 devices, even windows mobile)
>>> >> > * Inclusion of the Sense UI into the builds, which streamlines entry
>>> >> > for
>>> >> > forms which use primarily audio and images to convey information
>>> >> > * Better integration with CommCareHQ and improved workflow for
>>> >> > registering
>>> >> > users when no connection is available.
>>> >> > * Support for form transmission over SMS
>>> >> > * Notifications and tracking of the phone's time settings to catch
>>> >> > and
>>> >> > report phones whose date is hugely out of sync.
>>> >> > * Support for Syncing regularly (rather than just OTA Restoring
>>> >> > once)
>>> >> > 2)
>>> >> > We have a QA testing cycle comprised of a test application with the
>>> >> > standard
>>> >> > CommCare form actions (OTA restore, register cases, close cases,
>>> >> > register
>>> >> > referrals, close referrals, etc), that we run through each time we
>>> >> > commit
>>> >> > any changes (bug fixes, etc) to the stable QA branch. We've been
>>> >> > cataloging
>>> >> > errors on that branch, fixing, and retesting. What we haven't been
>>> >> > testing
>>> >> > in full is the content of every available CommCare app (The
>>> >> > xforms/suites/profiles for the existing apps), so it would be good
>>> >> > to
>>> >> > run
>>> >> > through those specifically.
>>> >> > -Clayton
>>> >> >
>>> >> > On Thu, Apr 7, 2011 at 3:14 PM, Jonathan Payne wrote:
>>> >> >>
>>> >> >> Clayton, thanks for the update. When this is released, can you also
>>> >> >> provide us with information on:
>>> >> >> 1) What features are new in CC 1.1 ?
>>> >> >> 2) What QA and testing steps have been completed? This can help us
>>> >> >> plan
>>> >> >> what QA we should do on our side.
>>> >> >> thanks!
>>> >> >> Jon
>>> >> >> On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims wrote:
>>> >> >>>
>>> >> >>> Hey Folks,
>>> >> >>> Just wanted to give a quick update on the CommCare 1.1 client's
>>> >> >>> workplan.
>>> >> >>> We're currently finishing up QA Testing of the client. We're on a
>>> >> >>> stable
>>> >> >>> release branch (For those of you using data.cchq, the
>>> >> >>> Release Candidates are
>>> >> >>> the 9000 series), and have finished up fixing the last round of
>>> >> >>> bugs
>>> >> >>> from
>>> >> >>> QA. The current plan is to get a release put together by the end
>>> >> >>> of
>>> >> >>> this
>>> >> >>> week or the beginning of next week. I'll keep you guys informed of
>>> >> >>> progress.
>>> >> >>> The unstable version (1.2) is where new feature dev will be
>>> >> >>> happening.
>>> >> >>> On
>>> >> >>> dev.cchq this is still the 7000 series of builds.
>>> >> >>> -Clayton
>>> >> >
>>> >> >
>>> >
>>> >
>>
>
>
--
Amelia Sagoff
Amelia,
Thanks! In general I think the User Interface shouldn't really be affected
in many tangible ways other than the notifications for clock-syncing unless
you actively turn on the new features, but we can review to make sure.
-Clayton
···
On Wed, Apr 20, 2011 at 9:41 AM, Amelia Sagoff wrote:
Clayton, I can work with you to put this together so we can have it on
the wiki as well.
On Wed, Apr 20, 2011 at 5:26 AM, Nick Amland namland@dimagi.com wrote:
Hey Clayton,
I was wondering if you could give me a quick list of all the features
(from
1.1) that will affecting the user experience (i.e. UI, data entry
workflow,
etc.). If necessary, a list of how it's changed from 1.0.
We'll definitely have to train users on anything that changes other than
something really minor.
Thanks,
Nick
Nick P. Amland
CommCare Field Fellow
Dimagi, Inc.
Dodoma, Tanzania
Google Voice: 253.642.7790
TZ Mobile: +255 762 740 996
Email: namland@dimagi.com
On Mon, Apr 11, 2011 at 12:19 AM, Nick Amland namland@dimagi.com wrote:
Hey Clayton,
Which of the new changes/fixes/etc listed are user facing? You mention
improved workflow for registering users among other things.
It'd be great to know how the changes that we'll have to communicate and
potentially even train the users on.
Thanks,
Nick
Nick P. Amland
CommCare Field Fellow
Dimagi, Inc.
Dodoma, Tanzania
Google Voice: 253.642.7790
TZ Mobile: +255 762 740 996
Email: namland@dimagi.com
On Sun, Apr 10, 2011 at 3:02 AM, Brian DeRenzi bderenzi@gmail.com wrote:
Hi Clayton,
Thanks for this info. For 1B, it sounds like that's something that all
CommCare folks will have to add to training once they switch to 1.1,
right? That is, we need to tell CHWs what to do when you get the "Your
phone time is probably wrong" message. Just out of curiosity, what
threshold are you using?
It's really frustrating, but the cell towers in TZ (at least when I
was there and on the Celtel network) don't support the auto-update
time feature. That would solve so much... I wonder if that's a
conscious decision by the telco in order to let people put their
phones in swahili-time if they so desire.
For #2, it sounds like that's something for a field implementer to do,
correct? Not an action that a CHW/end user will be doing? (at least
for now in Dodoma)
Brian
On Fri, Apr 8, 2011 at 3:21 PM, Clayton Sims csims@dimagi.com wrote:
Brian,
- So there are two different things that we've set up.
A) The phone now includes the appropriately formatted header in every
http
connection to tell the server what time (in UTC) that it the phone
thinks it
is. HQ is receiving this info and both logging it (so we can
eventually
notify someone in the program) and noting it in the submission.
B) The phone also parses down the server time in each connection and
looking
for gross inconsistencies. If this happens, the user will be notified
at the
next login (at a max, once per day) that their phone's time appears
to
be
wrong.
- The syncing is structured somewhat differently. Essentially there
is
a
flag you set in your application to be in "Sync" mode instead of an
expected
offline mode. In sync mode, the "send all unsent" option is replaced
by
a
sync option, and when you press it it submits all of your unsent
forms
and
requests a restore packet from the server. If the server supports a
sync
token, it'll incrementally send back only the differences, otherwise
it
will
just dump down the entire active data set (and the phone will just
reconcile
the differences).
-Clayton
On Thu, Apr 7, 2011 at 3:57 PM, Brian DeRenzi bderenzi@gmail.com wrote:
The list of new features looks fantastic. I had a couple quick
questions:
-
Can you say more about the time setting tracking? It's definitely
needed. What happens when the system detects that phone might have
the
wrong date? Does it message the user directly, or is there a CCHQ
feature that messages some sort of supervisor?
-
How does syncing regularly work? If it detects the phone is out
of
sync, will it "spoof" submissions to CCHQ to make it synchronize, or
will it add/delete cases on the handset?
Brian
On Thu, Apr 7, 2011 at 12:29 PM, Clayton Sims csims@dimagi.com wrote:
Jon,
Absolutely.
1)
1.1 is largely a bug fix and stability release. We've addressed a
huge
number of bugs in both the core JR code and the CommCare libraries
Other big points
- Official support for, and big improvements to the usefulness of
the
One
Question per Screen entry mode
- Official support for builds on multiple devices (native input
for
S40's,
qwerty S60 devices, even windows mobile)
- Inclusion of the Sense UI into the builds, which streamlines
entry
for
forms which use primarily audio and images to convey information
- Better integration with CommCareHQ and improved workflow for
registering
users when no connection is available.
- Support for form transmission over SMS
- Notifications and tracking of the phone's time settings to catch
and
report phones whose date is hugely out of sync.
- Support for Syncing regularly (rather than just OTA Restoring
once)
We have a QA testing cycle comprised of a test application with
the
standard
CommCare form actions (OTA restore, register cases, close cases,
register
referrals, close referrals, etc), that we run through each time we
commit
any changes (bug fixes, etc) to the stable QA branch. We've been
cataloging
errors on that branch, fixing, and retesting. What we haven't been
testing
in full is the content of every available CommCare app (The
xforms/suites/profiles for the existing apps), so it would be good
to
run
through those specifically.
-Clayton
On Thu, Apr 7, 2011 at 3:14 PM, Jonathan Payne <paynejd@gmail.com wrote:
Clayton, thanks for the update. When this is released, can you
also
provide us with information on:
- What features are new in CC 1.1 ?
- What QA and testing steps have been completed? This can help
us
plan
what QA we should do on our side.
thanks!
Jon
On Thu, Apr 7, 2011 at 3:07 PM, Clayton Sims csims@dimagi.com wrote:
Hey Folks,
Just wanted to give a quick update on the CommCare 1.1 client's
workplan.
We're currently finishing up QA Testing of the client. We're on
a
stable
release branch (For those of you using data.cchq, the
Release Candidates are
the 9000 series), and have finished up fixing the last round of
bugs
from
QA. The current plan is to get a release put together by the end
of
this
week or the beginning of next week. I'll keep you guys informed
of
progress.
The unstable version (1.2) is where new feature dev will be
happening.
On
dev.cchq this is still the 7000 series of builds.
-Clayton
--
Amelia Sagoff