Collect v1.7.0, Android v6.0.1, device used Samsung S5
When jumping to a new view, or refreshing the current view, the direction is always set to "back".
This is almost certainly wrong behaviour when advancing further in the survey using then jump option. The consequence is that autoplay widgets are not played when the user would expect them to be played.
Arguably it is wrong when moving backwards using the jump command. I would interpret a jump to the beginning of the form for instance as a positive movement which should result in the autoplay widgets being played. Whereas a swipe backwards should not. Note this interpretation will make implementation of a fix easier as well as it will not be necessary to work out whether a question is earlier or later in a form when jumping.
Create an autoplay widget then jump to the question.
Alternatively enable the audit log. Do some jumps and examine the direction reported for the questions jumped to.
Jumps always report a direction as "advancing". See notes above.
@nap2000 @lognaturel
I wanted to fix this as we need it to #760 and here are my initial changes (it's not tested well yet)
https://github.com/grzesiek2010/collect/commit/17ab3c8f3bddd28173739a2bc7620acd94108ed8
but we will need also changes on the javarosa side I mean we have to make FormIndex Serializable so we have to wait.
I could add required changes to the Javarosa repo but I found out that that TaroWorks team need the same changes as well so I'll allow them to create pr.
I will continue work on this.
@nap2000 I'm wondering about the case where a user jumps back to a screen with an autoplay widget. Do you think it really needs to autoplay again? In typical use, it's something the user will have already seen/heard and may not need to experience again so I think it's ok to leave it at their discretion to choose.
The solution @grzesiek2010 is suggesting takes the last visited form location into account so a jump back would be different from a jump forward. I can imagine some interesting analysis just on that. For example, if users are jumping back a lot, there might be a form design problem.
@lognaturel I'm not really that concerned about whether or not the autoplay is played after a jump. So any solution should not be complex or its not worth doing I think. I don't think the direction adds much after a jump. Even ignoring the direction column you can see if the user goes: q1, q2, q3, q1.
Perhaps we should just drop the direction column from the timer log? It may just cause confusion. After all if you see. q1, q2, q1, q2, q1 then you know whats going on whether they used Jump or swiped backwards.
@nap2000 @lognaturel
Perhaps we should just drop the direction column from the timer log?
After deeper investigation I think you are right. It's too hard to handle all possible cases. My solution might be ok but we shouldn't use the same for auto play of source @lognaturel you are right
@lognaturel I think the game is not worth the candle :)
Can we drop this column as @nap2000 suggested?
Especially @mmarciniak90 has found some bugs we should focus on them and maybe in the future rethink adding this column if it's really needed (I doubt)
Ok. When the user jumps forward to a question for the first time it will
not play either?
Any thoughts on whether or not direction should be reported by the timing
logger?
Also did you send the extended catlog for the timing issue when showing
images? Ie to include the log of the writing of the timer log that shows
the error.
On 12 Jun 2017 1:18 PM, "Grzegorz Orczykowski" notifications@github.com
wrote:
@nap2000 https://github.com/nap2000 @lognaturel
https://github.com/lognaturel
Perhaps we should just drop the direction column from the timer log?
After deeper investigation I think you are right. It's too hard to handle
all possible cases. My solution might be ok but we shouldn't use the same
for auto play of source @lognaturel https://github.com/lognaturel you are
right
@lognaturel https://github.com/lognaturel I think the game is not worth
the candle :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opendatakit/collect/issues/1094#issuecomment-307772793,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2y7UuKmUXwboGba61fChH8wEJnF05_ks5sDSyogaJpZM4Nt7Np
.
Dropping the direction column sounds fine to me. As @nap2000 mentioned, it can usually be inferred. Additionally, adding new things to the log later is not a big deal but removing them is much more difficult. @grzesiek2010 🕯😊
Independent of the timing audit, we need to decide what to do about the direction indicator. Should it still be changed in some way or left as it is?
Independent of the timing audit, we need to decide what to do about the direction indicator. Should it still be changed in some way or left as it is?
My proposal is don't touch it. It works well with autoplay option and nobody complains so if we get rid of that column there is no reason to change it.
Leaving the direction indicator as-is and removing the column from the audit sounds good to me. @nap2000 I'll let you make the final decision and close this issue if appropriate.
OK cool. I have made the code changes to remove the direction indicator
from the timer logger. I have also updated the documentation on this. I
just need to finish testing and upload. i think the only other thing I am
waiting for the timer logger is the issue where accessing a media file
causes the start time of the question to be set to when the picture has
been taken and accepted in collect. I can't reproduce this and am waiting
on catlogs to see what is going on.
On Wed, Jun 14, 2017 at 11:10 PM, Hélène Martin notifications@github.com
wrote:
Leaving the direction indicator as-is and removing the column from the
audit sounds good to me. @nap2000 https://github.com/nap2000 I'll let
you make the final decision and close this issue if appropriate.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opendatakit/collect/issues/1094#issuecomment-308559257,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2y7QvqOOAxdccaxWqPxNtBeKG7r1auks5sEExJgaJpZM4Nt7Np
.
--
Smap Consulting http://smap.com.au/| Mobile Data Collection Solutions
Application Developer - [email protected] minqiang.huang@gmail.com
Twitter: @dgmsot
Skype: ianaf4you
Phone: +61 402 975 959 (Australia)
Website: http://smap.com.au http://smap.com.au/blog
Thanks, @grzesiek2010 @nap2000, I'll close this for now.