I am having the following issue: I need to let users graphically interact with parameters of a curve in a 2-dimensional graph to do manual curve fitting. Some parameters are straightforward such as "min" and "max" asymptotes (also called A and K in the generalized logistic function) because they have an obvious 1:1 mapping with graphical elements, but others do not and I need to find a way to represent them graphically anyway. For instance, one of the parameters represents the growth of the curve at the inflection point but while it is proportional to the gradient at that point it does not correspond to it. Even more damning, sometimes that parameter and its graphical representation (the gradient of the curve) are not even of the same sign, and thus the only relationship that is consistent between the parameter and its graphical representation is that incrementing/decrementing the parameter by a small value produces a small non-linear change in the curve.

For reference, the curve looks like this:

Normal sigmoid curve

And the parameter in question controls the rate of growth at the inflection point (the point where x = 0 on that curve). Modifying the parameter has a lot of impact on the curve when it's close to 0 but the further it gets from 0 the (exponentially) less impact it has as the curve converges towards a step function.

To summarize, my issues are the following:

  1. I need to manipulate a hidden parameter from the effect it has on a curve
  2. The mapping between the parameter and the curve is not obvious (it cannot be 0, and it converges towards a step function, and the interaction is sometimes reversed)

Has this kind of problem been solved before and is there an obvious solution I am glossing over? So far I have tried the following:

  • A wheel that the user could drag and where I used the angular distance between the place they clicked and the place they released the click to calculate by how much I should increment/decrement the parameter. It didn't really work in practice because the users expected that angle to be exactly by how much the gradient would increase/decrease.
  • A slider between two approximated extremums: small positive (negative in the case of negative growth) value and some arbitrary positive (negative in the case of negative growth) big value (here I used max asymptote - min asymptote). The issue here was that adding a linear delta to the parameter meant that only a very small part of the slider led to interesting changes.
  • A simple "steepen/flatten" pair of buttons with a look-ahead test to see whether it does what it says it does and the option to long click the button in order to change the curve from one extreme to another. I have yet to investigate how to change the magnitude of delta based on how close the parameter is to 0 (so as to not make the interaction too tedious in cases where the original curve is already extremely steep) but as of now it's the only thing that is more or less working.
  • Is this purely an educational site? Can you limit the slider range to be around zero? – icc97 Feb 1 '16 at 21:35
  • 1
    perhaps I'm misunderstanding - but could you draw a feint linear line through x = 0 and allow them to drag the ends of the line around? – icc97 Feb 1 '16 at 21:37
  • @icc97 it's actually part of a data modelling application (which is why I sadly can't post screenshots and have to rely on textual descriptions). I have tried something like that and the issue is that while calculating the line from the parameter is trivial, calculating the parameter from the line isn't. I thought about approximating it but I am afraid that being almost-precise is going to be an extremely frustrating user experience. – jjanssen Feb 2 '16 at 9:48

The Problem isn’t Having the Right Control

For the purposes of visually adjusting a curve shape, any of your solutions (wheel, slider, buttons) sound adequate to me. The wheel is probably best because it is direct manipulation, and, as your testing revealed, users seem able to drag to the exact slope they want -it’s just that the curve doesn’t comply.

The wheel may have some discoverability problems, so if the users are untrained then the slider is a pretty good alternative, with the ends and midpoint labeled graphically (I guess that would be a straight line at one end, a middle-level sigmoid in the center, and a step-function at the other end). Unlike the wheel, users can’t see what they get until they try something, so it’ll mean more cut-and-try (or overshoot and reverse), but the controls will likely be more familiar, so it’s easier to figure out.

So the problem isn’t the controls. You’ve already figured that out.

The Problem is Mapping the Control

Reverse the Function

No matter what control you have, the problem is mapping a visual effect to a non-linearly related underlying parameter. In the case of relating the gradient to the parameter, one could solve the function’s equation for the parameter. Then, when the user selects a slope (with wheel or slider), calculate the parameter using the x and y coordinates at either end of the line defining the slope.

Transform the Parameter

However, you seem to be saying that the function relating the parameter to the line is a one-way function –that it’s not feasible to compute the parameter from x and y in the 200 ms necessary to allow smooth dragging or sliding. One alternative is to increment the parameter non-linearly so that the resulting visual changes in the curve appear more-or-less smoothly progressive. You may have to mathematically analyze the function for an approximation or experiment with various alternative transformations of the parameter (like the logarithm that icc97 suggests). It may be necessary to divide the range of parameter values up into segments and apply a different transformation to each segment (e.g., the middle values versus the ends).

Look-up Table

Or, take a page from cryptanalysis: when it’s too much for the CPU, use memory. Make a table of parameter increments that you have experimentally determined (perhaps through a series of binary searches) lead to a smooth progressive change to the curve. Users can only drag (a wheel or slider) to within a pixel, so you probably only need about a 1000 entries in the table. It shouldn't be a big demand on memory. To minimize your own workload, you might be able to have an order of magnitude or two less than 1000 if it works to linearly interpolate values in between (or use a non-linear transformation, making this a combination of the last two solutions).

  • This is a brilliant answer. I didn't think about a look-up table with interpolation, but the result seems to be pretty good. – jjanssen Feb 2 '16 at 13:12

The best I can think of is for you to use a logarithmic scale for the slider. They're not as uncommon as I thought - this Form Usability guide for Slider Interfaces recommends them for e-commerce sites. They also point to some example sites, of which Lens Hawk seems to have an implementation along the lines of what you're looking for.

enter image description here

enter image description here

enter image description here

You effectively need two sliders I think - one for positive values and one for negative.

Your Answer

