[Feature] Snapping support for RangeSelector

[hansmbakker]

Use case

I am looking for a way to edit the timing schema of tasks within a project (like a simple version of a Gantt chart). Some tasks should

• start at the same time as other tasks (parallel execution)
• start at the time another task ends (dependency on other task)

Describe the problem this feature would solve

I thought to use the multiple RangeSelector instances below each other to configure the TimeSpans of task executions.

In order to express the relations between start / end times of these tasks, I would like to have snapping support for the RangeSelector as in the drawing below:

Suggested technical solution

• Bindable properties:
  • Snapping values should be a bindable list of numerical values.
  • The snapping distance should be a configurable / bindable numerical value.
  • The breaking distance should be a configurable / bindable numerical value.
• Main behavior
  • When one of the Thumbs comes within the configured distance from one of the snapping values, that Thumb should snap to it (assume the closest snapping value).
  • When the user pulls further and the "dragging force" becomes too large (delta between pointer and Thumb becomes larger higher than the breaking distance), the dragged Thumb should assume the pointer position again
• Feedback to user: when it snaps,
  • the thumb that is being dragged could blink / become larger shortly
  • the control could emit an event that allows the programmer to give feedback to the user
    • show the user what triggered the snapping / what value was triggered so that the user could see the relation between things
    • sound or vibration implemented in consuming app rather than in control
  • the control could make a snapping sound
  • the control could generate a short vibration if the device supports it

Describe alternatives you've considered

If anybody has a better way of editing the timing schema of tasks within a project, I would be curious to hear about it :)

If there is a way to make a simple, draggable, horizontal bar chart that would also help

[ghost]

Hello, 'hansmbakker! Thanks for submitting a new feature request. I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future!

[michael-hawker]

@hansmbakker we have the existing StepFrequency property just like the normal Slider control, is that not sufficient to cover these scenarios?

[hansmbakker]

@michael-hawker My use case is that I want to have several of these range selectors below each other. When dragging a Thumb I would like it to snap when the value matches one of the other values.

StepFrequency is for snapping to fixed intervals, but that doesn't work for my use case.

[skendrot]

@hansmbakker Is this functionality available in any websites or apps to get an understanding of how it would be used?

[hansmbakker]

@skendrot no I don't, but I updated the original post with more information about the use case and with a drawing that hopefully helps.

By the way: If anybody has a better way of editing the timing schema of tasks within a project, I would be curious to hear about it :)

[skendrot]

Looking at your drawing I'm still confused how this would be handled from the developer of the app. How are those "inside" snapping points determined? They seem to be random and not correlate to anything else. The first "inside" snapping point seems to be when Task 1 ends? But then from there how are they determined? And then how would they be determined for all four tasks? You would need to implement some custom logic to determine the points for all of the tasks. I'm sure there are N number of tasks so you couldn't bind the RangeMin and RangeMax values. You'd have to listen to the changed events.

Your use case seems very niche which is why I asked if you had an example of this being done somewhere else. If this is something only your app would use it's hard to put work into it. But if others are asking for it, or even using it in other locations then it makes sense to put work in. I keep thinking of a calendar app where you don't want meetings to overlap, so your next meeting has a minimum of your previous meetings end time. But this use case is handled with the Minimum value of the RangeSelector and you can easily have meetings that overlap so even it doesn't quite fit.

[hansmbakker]

How are those "inside" snapping points determined?

Every Thumb value from every RangeControl (that is not in dragging state) would contribute to a list of snapping values. Every control could be bound to that list.

The Thumb being dragged would then snap to the values in that list. Only when the Thumb is released, the snapping values list would be updated.

[skendrot]

Thanks, that makes more sense on how those are handled

[michael-hawker]

I think the main thing here is that with Slider you can set the tick and steps independently, so the tick marks can be shown, but you can snap at them or other points in-between.

I think we'd want to first mirror that behavior in RangeSelector and not deviate from it. So I think this is really just about adding the TickFrequency and TickPlacement properties?

But @hansmbakker then it sounds like your scenario is even more specific than that? Do you think that'd be a common enough scenario that it should be something baked into the control? Is this something you've done today in your app already? Do you think there's a generalized solution?

I think these would have to be a separate set of properties or something, right? Or almost something that could be abstracted for both Slider and RangeSelector, as I don't think either were ever intended for this type of scenario?

[hansmbakker]

Thank you for getting back to this @michael-hawker!

I believe TickFrequency / TickPlacement only covers regular intervals, and I was looking for snapping at only specific values - e.g. not snapping at all except for those specific values.

I am not currently working on the app anymore and find it difficult to say from the top of my head what the solution should be - I think some discussion (including a possible solution) has taken place above already, and I'm not sure what to add at the moment.