Range is not behaving as before

[SkrOYC]

I have some columns set to Number type and configured to show a range while entering data into the form:

First: today it started to show the slider to the left instead of the center of the screen:

That’s not a big problem, the thing is that if you touch/click on a certain point at the left or right of the slider (while it’s centered, for example like this):

It will move the slider exactly to where you touch/click instead of increasing/decreasing by the steps you configured it to do.
This is REALLY BAD for me because:

1. I told users that they can do the 1-increase/1-decrease thing by touching either side of the slider and
2. The range is big so it’s hard to be accurate just by using the slider by itself.

Please some help. I hope this is not another of those “we are google and we think this is the best way so just get used to it”

@Steve Any idea?

[Steve]

SkrOYC:

I hope this is not another of those “we are google and we think this is the best way so just get used to it”

Attn @Mike_Moss @Arthur_Rallu

[SkrOYC]

@Mike_Moss @Arthur_Rallu Any idea?

[SkrOYC]

Is this a side effect on new changes? @Mike_Moss

[Marc_Dillon]

SkrOYC:

if you touch/click on a certain point at the left or right of the slider

…
It will move the slider exactly to where you touch/click instead of increasing/decreasing by the steps you configured it to do.

…

1. I told users that they can do the 1-increase/1-decrease thing by touching either side of the slider and

I don’t believe that has ever been the behavior of the range slider.

[SkrOYC]

It was until a couple of days.
Before I could change the number by just tapping once at either side the slicer by the number configured inside “Increase/decrease step”

[SkrOYC]

Is there any way in wich this problem will be solved anytime soon? @Mike_Moss
Even a simple response would be apreciated.
I cannot believe I’m the only one affected by this or the only one that liked how it worked before.
I’m feeling like a crazy person defending its POV

[Mike_Moss]

@SkrOYC we are actively looking at this.

As you know, sliders are a tradeoff: a visible, discoverable way to grok a full range of acceptable values, but the tradeoff can be precision (i.e. fine grained motor skills to select a small value).

We intend to find a way to get precision, while also honoring the step increase / decrease needed by the customer (which ranges from simple -1 / +1 to much larger steps).

Question for you:
What context are your app users when using this control?

• Mobile / tablet?
• Inside / outside?
  We ask because there’s a big variance of circumstances in which the apps are used; every data point helps w/ our understanding. We relish hearing the details of what the app / user is doing, and the situation they are in at that time.

Screenshots of the app (if possible) always welcome (and helpful).

[SkrOYC]

@Mike_Moss Thanks for your response and sorry if I’m late, I’ve been through a lot of work lately.

• Users are using mobile mainly.
• “Inside / outside?” I have no idea what that means, I’m sorry. English is not my main language and that gets in the way sometimes. Do you mean if they are from the same organization that’s the info’s owner? Then, inside

I have posted screenshots on this post and also an explanation of why I need this to behave the old way

Every record have 5 fields that need to be entered using sliders/range and every month there are going to be around 80-90 records and 90% of those records are entered between the 1st and 10th of each month.
Since the one incharge of entering the info needs to do it fast, range is our way to go but now it takes more time because of this problem

SkrOYC:

The thing is that if you touch/click on a certain point at the left or right of the slider (while it’s centered, for example like this):

It will move the slider exactly to where you touch/click instead of increasing/decreasing by the steps you configured it to do.
This is REALLY BAD for me because:

1. I told users that they can do the 1-increase/1-decrease thing by touching either side of the slider and
2. The range is big so it’s hard to be accurate just by using the slider by itself.

[Mike_Moss]

@SkrOYC
sorry for lack of clarity: when i say Inside / Outside I’m thinking more of the environmental conditions in which your users operate:

• sometimes under time pressure (like you’ve mentioned),
• We have apps that people are using in a dark area, vs in an outdoor setting, where contrast issues from sunlight can be an issue.

• Sometimes we have older users who need larger type to see more clearly

Either way, we are intending to give you the ability to increment as needed. It may not be the same way as the old slider, but the outcome is that your users will be able to adjust increments as needed (and ideally quickly and accurately).

Thanks for the response.

[Steve]

Mike_Moss:

Either way, we are intending to give you the ability to increment as needed. It may not be the same way as the old slider, but the outcome is that your users will be able to adjust increments as needed (and ideally quickly and accurately).

Curious why you have to take away long-standing behavior in order to give it back. Why not leave it until a suitable replacement is available?

[SkrOYC]

Thanks @Mike_Moss
Hope there are really smart people working on this in order to make a new way equal or better than the old one.
I’m with @Steve on this one. We shouldn’t face this kind of problems in the first place.
There should be a a suitable replacement done first, so we can adapt to it and prepare our users how to do things once a change gets executed, but in this case (similar to the left align Gallery View, text on About page, Card Views, etc) the change was done and then we had to start moving to deal with it.
You know, if it ain’t broken, don’t fix it

[SkrOYC]

Ended up with a workaround, as everything inside AppSheet that has no fix in the future.

UX:

I made the field an Enum base Number and created a suggested values expression:

IFS(
	[_THIS]<1,
    LIST(
      [_THIS],
      [_THIS]+1,
      [_THIS]+5
    ),
  [_THIS]<5,
    LIST(
      [_THIS]-1,
      [_THIS],
      [_THIS]+1,
      [_THIS]+5
    ),
  AND(
  	[_THIS]>=5,
    [_THIS]<=145
  ),
    LIST(
    	[_THIS]-5,
      [_THIS]-1,
      [_THIS],
      [_THIS]+1,
      [_THIS]+5
    ),
  [_THIS]>149,
    LIST(
    	[_THIS]-5,
      [_THIS]-1,
      [_THIS],
    ),
  [_THIS]>145,
    LIST(
    	[_THIS]-5,
      [_THIS]-1,
      [_THIS],
      [_THIS]+1
    )
)

This way I just allow the user to enter values between 0 and 150 and there are 5 and 1 step options.
It’s not perfect at all and I hate the fact that I had to make this just to fix a problem that should have never existed if no one would have changed the way Range behave.
I can’t cover my hate for Google policies,

[SkrOYC]

I'll move this to the set of killed features that the new AppSheet Team removed without previous notice