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.

Sign up for GitHub

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

Jump to bottom

Range widget with spinner/picker appearance #105

Closed
getodk-bot opened this issue Sep 5, 2016 · 7 comments
Closed

Range widget with spinner/picker appearance #105

getodk-bot opened this issue Sep 5, 2016 · 7 comments
Labels
enhancement
Milestone
July 2017

Comments

@getodk-bot
Copy link
Member

Issue by mitchellsundt
Thursday Jul 09, 2015 at 19:28 GMT
Originally opened as getodk/getodk#877 (2 comment(s))

Originally reported on Google Code with ID 876

On ODK Collect 1.3, the date-time widget with appearance="year" gives a nice spinner
to enter integers between 1901 and 2100. If would be really nice to be able to use
a spinner like this to enter arbitrary integers, especially as the code (presumably)
exists within ODK Collect already. OK, maybe not arbitrary integers, but (say) numbers
between +/-100 (which, I'm sure, form the vast majority of the answers ever provided
to "integer" questions), or a user-specifiable range.

The use cases I'm thinking of are:
(1) collecting dates in non-Gregorian calendars. In the Nepali calendar, for example,
months have between 29 and 32 days. At the moment, I'm using three select1 fields with
appearance="minimal" in a group on the same page. This works, but isn't brilliant,
as the option list of 1-32 is large compared to the screen size.
(2) multiple integer fields on a page - when the virtual keypad pops up, it conceals
the bottom half of the screen, leading to fieldworker confusion.
(3) users who would be happier "leaning on" the + or - to change values, rather than
"typing" on the keypad.

Thanks.

Reported by james.beard.tz on 2013-07-21 03:04:43
@mitchellsundt mitchellsundt mentioned this issue Sep 5, 2016
Closed
@getodk-bot
Copy link
Member Author

Comment by mitchellsundt
Thursday Jul 09, 2015 at 19:28 GMT

Issue 930 has been merged into this issue.

Reported by mitchellsundt on 2014-03-13 23:13:44

@getodk-bot
Copy link
Member Author

Comment by mitchellsundt
Thursday Jul 09, 2015 at 19:28 GMT

Reported by mitchellsundt on 2014-03-13 23:14:14

  • Labels added: Type-Enhancement, Collect
  • Labels removed: Type-Defect

@yanokwa yanokwa removed the Collect label Sep 16, 2016
@lognaturel lognaturel mentioned this issue Apr 22, 2017
Closed
@lognaturel
Copy link
Member

Coming back to this because it's related to #38. This seems like a nice thing to do but unfortunately, I don't think it can be something simple like just an appearance on an integer input because a range of values also needs to be defined at the form level. I don't think we could use constraints for that. This might be best implemented as an appearance on the W3C XForms range control.

@lognaturel lognaturel added this to the May 2017 milestone May 3, 2017
@lognaturel
Copy link
Member

I think we should aim for a RangeWidget with a default appearance using a SeekBar that looks something like:
seekbar-1

@dcbriccetti is working on support in JavaRosa (getodk/javarosa#44) and has setup a basic wrapper on top of that at #938.

Then we can add a spinner appearance to support what this issue originally asked for.

How does that sound?

@lognaturel lognaturel mentioned this issue May 3, 2017
Closed
@lognaturel lognaturel changed the title Possible enhancement - integer spinner Range widget with spinner/picker appearance May 3, 2017
@lognaturel lognaturel mentioned this issue May 4, 2017
Closed
@lognaturel
Copy link
Member

lognaturel commented May 5, 2017 •
edited
Loading

There's some agreement on appearances at the spec level here: getodk/xforms-spec#111

@lognaturel lognaturel modified the milestones: June 2017, May 2017 May 30, 2017
@lognaturel
Copy link
Member

lognaturel commented May 30, 2017 •
edited
Loading

@grzesiek2010 was asking in another conversation about integer vs decimal ranges. That should be determined by the bind in the model.

For example, <bind nodeset="/data/my-int" type="xs:integer"/>, should result in an integer in the instance for /data/my-int.

Similarly, <bind nodeset="/data/my-decimal" type="xs:decimal"/>, should result in a decimal in the instance for /data/my-decimal.

@grzesiek2010 does that give you enough info to work with? I think basically you'll have to think carefully about the different cases in WidgetFactory.

There might be a follow-up question about validation. What happens with something like:

...
        <instance>
             <data>
                 <data1>3.14159</data1>
             </data>
        </instance>
        <bind nodeset="/data/data1" type="xs:integer" />
...
<body>
    <range ref="data1" start="1.6" end="5.3" step="0.5" incremental="true">
        <label>Data1: </label>
    </range>
    ...
</body>

Note that the bind says it's an integer but the default and the start/end/step are all decimals.

For a simple numerical widget, what happens when the bind type is integer and the default is a decimal?

This was referenced May 30, 2017
Closed
Closed
@grzesiek2010
Copy link
Member

@lognaturel to answer your question it's not a problem if we use type="xs:integer" and then decimals as I use intValue() method so I get ints.

@lognaturel lognaturel modified the milestones: July 2017, June 2017 Jun 25, 2017
This was referenced Jul 4, 2017
Closed
Closed
@lognaturel lognaturel mentioned this issue Jul 28, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
July 2017
Development

No branches or pull requests
5 participants
@yanokwa @lognaturel @mitchellsundt @grzesiek2010 @getodk-bot