ODK Collect v1.16 Beta

@aurdipas @mschroeder @dr_michaelmarks @Matt_Berg Here's what it looks like in the code that's going out for the next beta.

  1. You tap Start ranking button and then you are immediately shown the ranking UI inline.
  2. You can re-arrange the elements with a long press and drag like in the current beta.
  3. When you swipe to the next or previous screen it saves like every other widget
  4. To reset, you long press on the question text to remove the response every other widget

My concern is that this rank UI is not exactly like the "tap a button" widgets (e.g., date, barcode) that you find in All Widgets. In those, the button is always visible at the top, the answer is at the bottom, and changing the answer requires that you tap the button first. In rank, the button is only there when the answer is empty and all the changes are inline.

Here's what the date widget looks like:

I worry a lot about consistency, so my question is why not make the rank widget exactly like the date widget? The interaction would be:

  1. You tap Start ranking button and then a large dialog pops up (or maybe full-screen)
  2. You can re-arrange the elements with a long press and drag
  3. When you are done you click OK and the answers are printed below the button
  4. When you swipe to the next or previous screen it saves like every other widget
  5. To reset, you long press on the question text to remove the response every other widget

The pros are that this is consistent with other widgets which means consistent interactions which means less training. And it's vertically small, which can be nice for multiple widgets on a screen.

The cons are that you have to press the button each time you want to rank or re-rank. And you don't see the options when you land on that screen. And a dialog would be smaller than just doing it inline. And consistency for consistency's sake is lunacy. Maybe we do want to have more things inline.

Anyone prefer one over the other?

@yanokwa I agree on what you say about consistency. The actual version is enough intuitive and not bad at all, but if it would be possible to have the same style of the other widgets (e.g. date widget) also for the rank one, that would be better.

@yanokwa I agree with @aurdipas. Consistency is nice especially for training purposes. However, option 1 is quite intuitive and could be easily adopted by users. I think I actually prefer option 1 to option 2.

Pretty strong preference to keep what the first video shows. Depending on the device screen size, ranking in a dialog may mean having to scroll vertically while moving items around. That requires quite a bit of dexterity. In that case, not all of the choices would be visible on the screen at once which could bias results.

@aurdipas do you have any specific concerns about not having the button always available? My sense is that data collectors are unlikely to make the connection with date or geo questions and so wouldn't notice an inconsistency.

One possible concern would be that clearing an answer is not very discoverable but note that date and geo questions have that same property.

I like the button to start ranking. The screen layout looks good.
It would if possible be preferable to have a (re)-start ranking button if you go back to the question later.

Also +1 from me for @Fabla suggestion

If it can also be created in such a way that one have the option to send the data/responses in collect to both wife/cellular and SMS in the server settings so that there will be main data can go to aggregate server and the fields with SMS tag can go to SMS. (I still stand by sending to multiple numbers here)

I can see many situations where this would be useful. And/or option to send the minimum SMS dataset but keep the data so that it sends next time you have data/wifi.

1 Like

Interesting! Would love to hear more about what you're seeing as the benefits. Seems I'm in the minority so happy to be wrong on this one but it would help me to understand what the overarching goals are.

The feature we're looking at here is meant to send form contents via SMS. You can do what you're describing by launching the default text app with number and message content using the external app feature. I'll try to share a sample form soon.

Agreed with you and @dr_michaelmarks. This is planned for a later release once we know the SMS feature is used and working well.

When you design your form, you can set what the delimiter between field values should be. For example, you could set it to be | so your message would look something like SMS-test|fn|Marie Jo|ln|Bar. The delimiter is escaped for server processing. That is, if the text sent were SMS-test fn Marie\ Jo ln Bar, the server can tell that the space in the first name is part of that answer and not meant to be used as a delimiter.

Again, this feature is meant to sent texts that will be automatically read and used by some kind of server on the other end. I'll share a form to send more free-form texts (that can also include values from the form).


@LN, thanks for your respond, i will be glad to get those forms, nice work to all.

1 Like

@LN as I said the way it is now is quite intuitive and should not be a problem for an enumerator.
my comment was about consistency that is always a good thing... but sometime if you want innovation you need to be less conservative :slight_smile:

1 Like

Small thing: I just noticed that the icons on the upload screen look a bit odd: I assume they're supposed to be round as opposed to oval?

Thanks for spotting this Adam. I am gonna be working on a fix for it which will be available in a beta soon! Will update you when that fix is released so you can verify!

@dr_michaelmarks I wanted to make sure you saw @LN's question. To summarize, why would it be preferable to have a (re)-start ranking button. Would it be exactly like the date button where it's an edit operation? Would it reset the current ranking and start over?

I think its just a visual thing that makes clearer to the user that you can re-rank.
I think the date / geopoint widgets are similar?

We just uploaded v1.16 Beta 3 to the Play Store! Assuming no problems are found with this beta, we'll ship this build to all Collect users on Sunday.

@dr_michaelmarks @aurdipas We've made the changes to the rank widget so it’s the same as the date widget. Can you take a look?

@benjaminFaguer In your post at https://forum.getodk.org/t/13200 you wanted to be able to encrypt imported data in Collect. We’ve add that feature! Can you give it a try with one submission?

@Fabla and @lalo We (mostly @LN) added one more feature to this release that is pretty amazing: Sending a text message (SMS) or email from a form in Collect. That is, you can add a widget that lets you send compose a message from data in the form and send to whatever SMS number or email address. We’ve added sample form called “Send SMS or Email in Form” on the test server. What do you think?

1 Like

I like the new Rank form. I can still see that some might want a "Re-Rank" button similar to the re-capture of barcode form but I think its good.

I tried the Send SMS/Email from within form but it didn't work for me.
When I click the Launch button I get a message saying
"The Requested application is missing. Please manually enter the reading".

1 Like

Thanks for the feedback, @dr_michaelmarks. I think you are using v1.16.0 beta.2. Upgrade to beta.3 to resolve those issues you reported!

I think you are using v1.16.0 beta.2. Upgrade to beta.3 to resolve those issues you reported!

  • Correct. Both fixed. Its great.

One small thing - is there anyway to automatically go back to ODK Collect once the SMS has been sent and/or to make the message send in the background so you stay "in App" so to speak.

am glad to hear that this has work out, i will surely have a long at it, good work to all.


really cool. I like that.
Does it mean that Sunday also a version of XLSForm Offline will be released as well?

1 Like

@aurdipas There is a high-priority issue (https://github.com/opendatakit/xforms-spec/issues/203) in the XForms specification that is blocking Sunday's release. It's a relatively small code change, but it's a wee bit dangerous and we need help from @martijnr and @Ukang_a_Dickson to review and resolve.

Once that change is approved, it will require updates to JavaRosa, which will mean updates to Collect and Validate. It will also require updates to pyxform, which will mean updates to XLSForm Online and Offline.

All this to say, there's a lot going on, and the sequencing is tricky, but I'm hopeful we'll be able to get it all done by Sunday.

1 Like

I just pushed v1.16.0 beta.4 which resolves the blocking issue we found yesterday. Thanks to @LN for her quick fixes!

And for those keeping score, we've also updated JavaRosa and Validate. Next up is pyxform and XLSForm Online/Offline!

1 Like