I assume SMS channel is given to send high-priority data quicker. This means that low priority data would come later (but should come eventually, via internet channel, right?). When I configure a form to go via SMS, ODK collect sends the data via SMS and then moves the form to SENT FORMS list. This means that when the data connection is made available to the phone, it does not have that form in the queue to send (since it has already sent it via SMS). Isn't this wrong? How would I ensure that I get both submissions via SMS and internet?
If someone could help, it would be great. I am in the middle of a deployment and have to finalize whether to adopt it or drop it. If it is a bug and ongoing work, I can wait. If this is how it is supposed to work (no improvements in development queue), then I take a call to drop it. @LN@issa
Hi @Saad, you should be able to do what you want...
First send the forms over SMS, then when you get back to a place with Internet, can change the transport option in General Settings to Internet. Then in Sent Forms, set Change View (should be in the menu ⋮ ) to Sent and Unsent Forms, then select the forms you want to re-send and they should go over Internet.
This is a new feature and I don't have my phone on me, so please try it out first and make sure it works well for you. We'll be making this feature a bit more visible over the next few weeks.
Also, when you get a chance, please introduce yourself here. I'd also encourage you to add a real picture as your avatar because it I find that the volunteers who provide support tend to help faster they know a little bit about you
Please fill the full support template when you have a question. These threads are searchable and useful for the future so it’s important that version numbers are included. In this case, you are likely using Collect v1.16.1.
It’s also important to know what you’ve tried. As @yanokwa mentioned, you can show sent and unsent forms. Have you tried this? If it doesn’t work for you, why not?
Two additions are currently planned:
a “select on send” transport option that displays both “Send (SMS)” and “Send (Internet)” buttons on the send screen.
as @yanokwa said, a way to more easily see just SMS submissions to, for example, resend them. @joeldean is coming up with interface options for this and it’s not yet clear what it will look like. If you have an idea of what you’d like, please share.
There are no current plans to initiate both SMS and Internet submissions at the same time. If this is something you would like, please write a new post in features describing your usecase in detail.
@yanokwa, I had already done this and knew about resetting the form to send again. It works alright with this method. However, this is painful to teach to field workers, who expect significantly straight forward working instructions from us with less complications. That's why I was expecting to avoid your mentioned method and looking for alternates and/or control of it via settings.
@LN: I would go for some variant of option 2. Here is my extended idea:
Server settings in COLLECT should list 3 options: Data only (Wifi or Cellular), SMS only, Both SMS and data (where SMS is sent as soon as form is finalized, while data is sent when phone finds a data connection).
Working should be like this: Option 1 and 2 are simple. For option 3, there should be 2 queues, 1 is SENT via SMS, and second SENT via DATA. As soon as the form is finalized, the form get queued into both queues. SMS should be sent immediately and the form should be released from this queue. But form should remain in data queue, unless it is sent via data and cleared afterwards.
2 safety measures are needed.
First, SMS should send some submission identifier alongwith data (kind of like uuid in aggregate). This is needed because if I receive data from SMS and enter it manually into aggregate, then the absence of identifier will create a duplicate entry of the same data when it would come via data connection. I know uuid is created by aggregate when the instance is received, but Collect would have to do some smaller identifier too for channel synchronization.
Second, SMS should somehow include which question numbers are missing from SMS data (like Q5 if it has image, Q7 if it has audio/video, etc). I know SMS has less space and every single text character is precious, but this is needed on the client side to know if the form submission is complete or not. I will give you an example: If there is an image question but the user does not select an image, then his submission is already complete on submission via SMS. However, I will only know of his opting out of image question when the data submission comes in. This is slightly down-the-road evolution step, but just wanted to share with you from the end-user point of view.
By the way, I have worked on SMS technologies for over a decade (hence my enthusiasm for it!), so I would be happy to help in any design steps for fine-tuning SMS channel (like above) if you require.
For option 3, there should be 2 queues, 1 is SENT via SMS, and second SENT via DATA. As soon as the form is finalized, the form get queued into both queues. SMS should be sent immediately and the form should be released from this queue. But form should remain in data queue, unless it is sent via data and cleared afterwards.
This seems like a good idea. It's not what's currently planned but perhaps we should re-evaluate. I will make sure the Technical Steering Committee discusses this soon.
SMS should send some submission identifier along with data
This is something that's been left up to the form designer because it's hard to do well in a generic way. For example, in some forms, there may be a barcode that's scanned to get a unique identifier. That will identify the record and the form designer can include it in the SMS submission by providing a tag for it. In other forms, there may not be such a unique identifier and in that case the form designer can provide a tag for the instanceID and use that. The downside of the instanceID is that it's quite long so it's not included by default. Does that make sense to you?
Second, SMS should somehow include which question numbers are missing from SMS data (like Q5 if it has image, Q7 if it has audio/video, etc).
This also feels like something the form designer should control because it doesn't seem everyone will have the same needs. What I would do as a form designer to meet that requirement is add a calculate question with an SMS tag that has value T if an image was selected and F otherwise (or 1 and 0, or anything you want). Would that work for you?
By the way, I have worked on SMS technologies for over a decade (hence my enthusiasm for it!), so I would be happy to help in any design steps for fine-tuning SMS channel (like above) if you require.
That's fantastic! It would definitely be great to get your insights on some of the next wave of SMS features and any other requirements we may have missed.
You may want to read the original thread at Send submissions via SMS and see if you have any additional suggestions following that.
