Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New VAS (Visual Analogue Scale) answer format #708

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

ICONplcRK
Copy link

The ORKVASScaleAnswerFormat class represents a visual analogue scale (VAS) answer format.

Using this, participants select a position on a continuous linear scale that represents how they rate their health condition by marking a point on a horizontal line between two endpoints. The health conditions represented by the endpoints of the line are described by the left and right anchor text: @param minimumValueDescription and @param maximumValueDescription respectively.
This scale is an electronic version of the standard 100cm visual analogue scale (VAS) used in many paper questionnaires and validated health instruments, particularly in the area of pain measurement. The VAS automatically scales to the optimal length for the device display, and the scientific literature contains strong validation evidence that the display length of the VAS does not influence the psychometric properties of the scale.
In common with the 100cm paper visual analogue scale, the scale answer format produces an ORKScaleQuestionResult object that returns an integer result from 0 to 100 with all possible integers between 0 to 100 measurable.
The style of marker used to indicate the point on the VAS that the participant has selected is controlled by @param markerStyle.
The presence or absence of arrows to associate the anchor text with the ends of the VAS line is controlled by @arrows.

@@ -3141,8 +3166,9 @@
LD_RUNPATH_SEARCH_PATHS = "$(inherited) @executable_path/Frameworks @loader_path/Frameworks";
MODULEMAP_FILE = ResearchKit/module.modulemap;
MTL_ENABLE_DEBUG_INFO = YES;
PRODUCT_BUNDLE_IDENTIFIER = "org.researchkit.${PRODUCT_NAME:rfc1034identifier}";
PRODUCT_BUNDLE_IDENTIFIER = nsg.resKit.VAS;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Revert this Product Bundle Identifier

@YuanZhu-apple
Copy link
Member

YuanZhu-apple commented Jun 10, 2016

@ICONplcRK Can you attach a screenshot for us to review?
Additionally, Can you put your testing code into ORKCatalog and ORKTest instead of ORKSample.
Normally we control what get shows up in ORKSample. Thanks!

@ICONplcRK
Copy link
Author

Here are screenshots with answer with possible configurations:
vas1
vas2
vas3

@YuanZhu-apple
Copy link
Member

Please correct me if I'm wrong.
Compared the existing continuous scale with VAS scale, I find a few difference.

  1. VAS has a ticker at each ends
  2. VAS don't show current value
  3. VAS don't show a value label at each end
  4. VAS has a different drag button.

Do you think it is possible to throw a few customization options to the existing continuous scale, and not introduce a new answer format?

simulator screen shot jun 10 2016 2 41 00 pm

@ICONplcRK
Copy link
Author

In such case we need to add show/hide option to actual value, min and max labels, scale slider and change thumbnails, and to hide "scale markers" on slider. Additionally, is such cases user can change scale anyway (disabling this will be bad idea for all other slider formats). And is our case, this limit is essential, we collect in some way, patient "felling" about his/her situation, so original VAS has this fixed 0 to 100 scale.
For dis reason we decided to make it as a separate answer object.

@YuanZhu-apple
Copy link
Member

@ICONplcRK

I still think you can make those options available for the existing continuous scale.
And create a convenient initializer for VAS.

  1. VAS has a ticker at each ends
  2. VAS don't show current value
  3. VAS don't show a value label at each end
  4. VAS has a different drag button.

@ICONplcRK
Copy link
Author

Right now, existing continuous scales, don't have those min and max arrows, and have option only to show or hide tickers for scale, we want to emulate real measurement tool as close as possible, and in such case even using custom initializer we must expand a loot of existing classes and parametrize them.
IMHO creating classes to use specific tool, w/o fogging existing code is valid idea.

@YuanZhu-apple
Copy link
Member

@ICONplcRK Can you please explain why the arrow between the scale and label are important?

IMHO ResearchKit is trying bring the research to the mobile, but not to copy everything. And that's not possible either. For example, user use finger instead of pen to do a survey.

The parametrization happens in the framework, so the developer won't notice it. To the developers, the custom initialer is easy to use.

And I am sure, even on paper not all the VAS looks the same, there could be some variants. That's why I think customization is good way to go.

@lwrecza
Copy link

lwrecza commented Oct 6, 2016

@YuanZhu-apple Are you able to proceed with this ? We have updated the source code and our client ICON really needs this to be resolved. We need to have it closed until the conference session planned soon. Can you help us ? Much appreciated in advance.
Best,
Lukasz Wrecza

@YuanZhu-apple
Copy link
Member

@lwrecza You have the freedom to keep the change in your fork. I don't see it is necessary to push it to the official repo.

@lwrecza
Copy link

lwrecza commented Oct 6, 2016

@YuanZhu-apple There is a real value for other developers from having this part of code. Don't you think ? Why do you think it is not necessary to have it in the official repo or you suggest other way to merge this pull request ?

Best,
Lukasz Wrecza

@YuanZhu-apple
Copy link
Member

@lwrecza I stated before.

@ICONplcRK Can you please explain why the arrow between the scale and label are important?

IMHO ResearchKit is trying bring the research to the mobile, but not to copy everything. And that's not possible either. For example, user use finger instead of pen to do a survey.

The parametrization happens in the framework, so the developer won't notice it. To the developers, the custom initialer is easy to use.

And I am sure, even on paper not all the VAS looks the same, there could be some variants. That's why I think customization is good way to go.

@lwrecza
Copy link

lwrecza commented Oct 6, 2016

@YuanZhu-apple Thanks for coming back. We noted your comments and that's why we changed the code for customization and followed your advice. We submitted it today but still do not see any new commit. It should be 7th.

Best,
Lukasz

@lwrecza
Copy link

lwrecza commented Oct 6, 2016

@YuanZhu-apple btw, we have yet 2 more pull requests in the pipe. Would be great to go forward with this one. On your rules here so count on your advice and support.
Best,
Lukasz

@lwrecza
Copy link

lwrecza commented Oct 18, 2016

@YuanZhu-apple Hi. Is the fork closed ? We have submitted the changes but there are no updates under the commits section. Can you help ? Much appreciated in advance.
Best,
Lukasz

@lwrecza
Copy link

lwrecza commented Oct 20, 2016

@YuanZhu-apple Friendly ping.
Best,
Lukasz

@rsanchezsaez
Copy link
Contributor

rsanchezsaez commented Oct 20, 2016

@lwrecza: You have not submitted any new commits to this pull request since Yuan's comment regarding customizing the existing scale answer format instead of adding a new one.

Make sure you have pushed all the relevant commits to the master branch of your fork (which is the branch you created the PR from). Also, make sure you pull the latest official master into your mater and resolve any arising merge conflicts.

@pharmpk
Copy link

pharmpk commented Nov 2, 2016

Is ORKVASScaleAnswerFormat available yet?

@rsanchezsaez
Copy link
Contributor

rsanchezsaez commented Nov 2, 2016

@pharmpk Feedback needs to be addresses before this feature is considered for merging into the official ResearchKit repo. In the meantime, you're free to use the implementation in ICONplcRK's fork. ;-)

@pharmpk
Copy link

pharmpk commented Nov 2, 2016

@rsanchezsaez Thanks for the reply. ResearchKit is an interesting challenge for an intermediate Swift programmer ;-) I was finally getting to the stage of developing a 'complete' application and heard about VAS yesterday. I'll have a look at ICONplcRK's fork. I'm still in the demoing possibilities stage so hopefully an official version will happen (soon enough). Thanks
... the ICONpicRK fork seems to be one Xcode/Swift version behind. Too many changes for me to resolve for now.

@umerkhan-apple
Copy link
Member

@pharmpk Should we proceed with closing this PR for now?

@pharmpk
Copy link

pharmpk commented Jan 24, 2017

@umerkhan-apple I'm not sure of GitHub protocol so I've probably asked in the wrong 'area'. I found mention of VAS here and wanted to incorporate it into a survey type application. A colleague indicated some interest if VAS was available but that has cooled. I'd like to dig a little deeper into ResearchKit in the future. As mentioned above the ICONpicRK fork seemed to have too many, for me, incompatibilities with the Xcode/Swift I was using for me to resolve. I probably should not have a 'vote' on closing the PR but I would like to see some progress with this task type or maybe more information about how to develop a new type of task. Thanks

@umerkhan-apple
Copy link
Member

@pharmpk It would be nice to include this PR into RK. I will leave it open with a help wanted tag to see if anyone picks it up. Otherwise, we will have to close it. If you would like, you can create a separate PR with your implementation of VAS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants