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.
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:
You tap Start ranking button and then a large dialog pops up (or maybe full-screen)
You can re-arrange the elements with a long press and drag
When you are done you click OK and the answers are printed below the button
When you swipe to the next or previous screen it saves like every other widget
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.
@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.
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.
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 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
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?
@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?
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".
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.
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.
