Edit simulations, launch site altitude slider is confusing about openrocket HOT 8 OPEN

I wouldn't remove a single slider, because this is a general design aspect.
The sliders are meant for quick entry, while the boxes allow full control.
If this is too confusing then something should be designed which covers all
places.

A startup tip (in the upcoming startup dialog) could alleviate the problem.

• Sampo N.
  On Jun 13, 2013 1:38 AM, "Jeff Davis" [email protected] wrote:

Report from the Rocketry Forum. User was trying to set altitude to 6,500
feet, but the slide maxs out at 3,330 feet (1km). This lead user to believe
that 3,300 feed was the max launch altitude that OR could handle, when in
fact any altitude can be typed in the textbox.

Fix rather than change the max altitude on the slider, remove the slider
as most people will likely type in their actual altitude at their location.

Bonus point: add button to search and find altitude at your location.
Though that feature should be a separate item for v.next.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/104
.

from openrocket.

One idea for a more self-explanatory UX: When a user pulls the slider to the limit, and the value is allowed to go larger/smaller, a small popup box could appear for a few seconds saying that larger/smaller values can be input in the box. (Can someone think of an intuitive way to indicating this without a lot of text?)

The popup could fade out / disappear after a few seconds, or if the user moves the slider away from the edge.

This could be implemented in BasicSlider.java. In most (all?) cases the model provided to it is DoubleModel.ValueSliderModel, and it could be extended to check when the DoubleModel value can go outside of the slider value. (Or a constructor could be made that takes a DoubleModel, and all places changed to use it.)

from openrocket.

Another idea would be to use the non-linear slider model with a large
upper limit of say 5000m.

from openrocket.

Yes, if it's only that one particular field that is problematic, then of course its range can be fine-tuned. I have a feeling some people have been confused about the same thing in some other places as well.

from openrocket.

I prefer text entry boxes to the sliders as a general rule. I never put in
something for "quick entry"; either I leave it alone or I set it to the
number that I want.

For example, in the component configuration dialogs, I have never once used
a slider. I measure the number from the actual part, or I look it up
online, and then I enter it in the text box.

When I do use the slider, I end up tweaking afterwards, because the sliders
have no scale for reference. Unless the sliders snap to convenient values,
I don't think they're at all appropriate for either component editing or
simulation editing. (They are, however, appropriate for things like
rotation of the rocket in the 2d view)

On Thu, Jun 13, 2013 at 3:50 PM, plaa [email protected] wrote:

Yes, if it's only that one particular field that is problematic, then of
course its range can be fine-tuned. I have a feeling some people have been
confused about the same thing in some other places as well.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/104#issuecomment-19420254
.

from openrocket.

I believe that this issue is still present, the slide limits are 0-1000m and if I type in 3000m to the textbox, the slider limits are still 0-1000 where I would have expected 0-3000m.

from openrocket.

From a UX perspective, I can see two ways around this:

1. having the sliders always reset to the middle once the value is update (like a springy slider) so that repeated pushes in either direction will continue to increase / decrease the value
2. have the sliders continue to increment/decrement when they hit the end, while they are being held down (ie: while mouseDown). On release, the "scale" of the slider can be adjusted. Double Extra bonus points if the amount of increase is logarithmic, so the longer you hold it a an extremity, the faster it increments/decrements. Granular control can be resumed once mouseUp occurs, and the slider range is rescaled...

from openrocket.

why not try giving a single " i " (Info) button and in case of any confusion they can click over it and get to know what constraints are there and whatnot.

from openrocket.