Previous to version 7, clicking on either side of the current slider position advanced the slider in that direction by the increment amount. This feels intuitive to me, and I don’t think it works in version 7. I’ve found that clicking once on a slider and then using the arrow keys will do the same thing in 7, but it feels less intuitive. Given that the increment functionality is thus still existent, I place a low priority on this request, but I guess I’m also asking a question about whether clicking to increment/decrement still works.
Hi Christopher,
The default behavior for slider interaction changed in NetLogo 7, but there is a preference that will allow you to revert to the old behavior. Navigate to the General tab in the Preferences dialog (Settings on Mac) and uncheck the “Jump sliders to click location” preference. This should restore the 6.4 behavior, both for slider widgets and for the model speed slider. Let us know if you can’t find that preference or if it still doesn’t behave as expected.
Isaac B.
Great, thanks! I’ll add that I’ve never found jump-to scroll bar functionality to be useful. I guess that here, though, I’d jump and then arrow to a precise value. Still, jump-to seems to be no improvement over drag-to as regards motion conservation—or even motion difference. Finally, there’s no way for me to encode in the model which functionality the user has, is there?
The primary reason for changing the default behavior is that pretty much every slider in modern GUIs jumps to the click location rather than incrementing, so it would be a more familiar behavior to the vast majority of new users. Unfortunately this is currently just an application-level preference, so you can’t specify it in the model, although I’m not sure why you would want to. Evidently, different people have different preferences for this behavior, so it might be confusing for a user to see one behavior in their own model and a different behavior in another.
Isaac B.
I hear you. I’ll just get used to it.
Though … in MacOS there’s a setting in the Appearance pane to chose between “Jump to the next page” and “Jump to the spot that’s clicked”. So you can guess that I have the first one selected on my machine.
As regards GUI standards, I hear you there, too. Thanks for pointing it out. Yet it is true that the vast majority of my students’ machines are Macs—though I don’t know what setting they have selected for the scrollbar click functionality. I know that Windows has a huge market share, and it’s probably also larger among NetLogo users even if not as hugely as the entire market. Okay, now I’m wondering about Linux … and a quick search shows that the behavior is inconsistent across applications. And of course there are the Google apps, which is often what my students are using, regardless of their computer’s platform. Oh, wait …
Maybe the MacOS version of NetLogo could check my Mac’s scroll bar functionality in the Appearance pane of Settings and work accordingly? MS Word respects that setting, for example. And since I use a browser to open … the Google apps, those respect the setting, too.
Regardless, it’s excellent that the functionality of incremental movement still exists. That was the shocking (and confusing) thing for me. I had thought that the incremental movement had disappeared entirely, but when I saw that Increment was still in slider elements’ spec’s, I tried harder to figure out how it might be accessed and after a bit of trial and error found that the arrow keys were the way to do it.
A final nit picky note: To use that increment functionality the user now first needs to click on the interface element and then move to the keys (and back and forth again if adjusting more sliders), so it takes more effort on the user’s part this way. Not that it’s a big difference in time-use, and not that people do this a lot, but still.
Yeah, this got too long. Sorry about that! There are a ton of improvements in the version 7 user interface.
No worries at all about the length, it’s always great to hear thorough and sincere feedback on new features! It’s interesting that you’re equating this to scroll bars, because to me, sliders and scroll bars are completely separate components that shouldn’t necessarily have the same behavior. I would totally support matching our scroll bar behavior to the system behavior, however.
I understand your concern about the incremental functionality of sliders, but I don’t think it’s an issue. In previous versions of NetLogo, using the arrow keys wasn’t even an option. Also, with “jump on click” disabled, you can increment the slider by clicking in the track without clicking on the body of the slider first. So my analysis of the situation is, the existing functionality has been retained with equivalent timing, and there are now additional ways to acess this functionality. Let me know if I’m misunderstanding something.
One other thing that caught my attention is that you thought the slider increment had disappeared entirely. To clarify, simply dragging the slider will respect the increment, there’s no need to click the track or use the arrow keys unless you have a very small increment. Was this not clear from the interface? Or was it not the behavior you were expecting?
Thanks again for your thoughtful comments!
Isaac B.
Good points.
I hadn’t thought about dragging working by increment as well. I’ll keep that in mind, though the place where it’s necessary to click (or arrow) by increment is where the increment is small compared to the range and so I was in that situation by default.
The slider & scroll bar equivalency seems natural for me, and I’m also not recalling many cases where I use a slider other than in NetLogo. Though, in those places, I imagine there’s often a pair of +/– buttons in addition to the slider.
You’re right that there often are +/- buttons accompanying a slider. We discussed adding those to the slider widget at one point, but it’s already quite cramped as is, so that didn’t really work out. If you think that would have solved your problem, we can certainly revisit that idea and see if we can come up with something that works!
Isaac B.