slider orientation default seems incorrect more often than not...

[ScottJehl]

When someone has time, could you explain the logic behind how the
slider decides which orientation to use?

I've had to fix our select-to-slider wrapper plugin to always set
'horizontal' as a default because it would flip to vertical even when
there was plenty of room for a horizontal slider (~400px width).

At a glance, it seems maybe the logic should be...

if the number of slider values on the scale is greater than the pixel
width, set to vertical.
otherwise, set to horizontal.


Otherwise, it seems vertical sliders will be occurring in many
situations where horizontal is expected, since horizontal seems to me
to be the primary case in most interfaces.

Thoughts?

[Maggie Wachs]

I'm curious, what was the rationale for making the default orientation
"auto"? If the goal was to eliminate the need to pass an orientation
option, it should default to horizontal (probably the most common use
case) or vertical instead of leaving it open-ended. Auto means that
it will shift to fit the container, which works as an option, but
seems like an edge case that a slider's orientation would be set that
way so it shouldn't be the default.

-- Maggie

[ScottJehl]

Btw - in the existing logic, the following slider is always vertical.

$('<div></div>').slider().appendTo('body');

Doesn't seem right.
I'm with Maggie:
- Set default to 'horizontal'.
- maybe keep 'auto' as an option if we can fix its logic.

[Richard D. Worth]

+1

Auto is going to be a very hard default to test unless it's very well specified. Let's change the default back to horizontal as that's the most common case (as all our defaults should be) and remove auto for now. If someone specifies vertical, we now have a default height of 100px, which should make it easier.

- Richard

[Scott González]

On Mon, Feb 16, 2009 at 3:51 PM, Richard D. Worth <rdw...@gmail.com> wrote:

+1

Auto is going to be a very hard default to test unless it's very well specified. Let's change the default back to horizontal as that's the most common case (as all our defaults should be) and remove auto for now. If someone specifies vertical, we now have a default height of 100px, which should make it easier.

+1 for removing auto as a valid option and setting the default to horizontal

[Paul Bakaus]

The orientation detection is incredibly simple. It just checks if the height is greater than the slider width, and if that's true, the orientation is 'vertical', if not, it's horizontal. That sounds like pretty common to me. Maybe all we need is to change the check a bit, to default to 'horizontal' in equal (0 == 0) situations.

-1 for removing auto as option

--
Paul Bakaus
UI Architect
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus

[Scott Jehl]

Paul,

Can you explain a situation where this feature would be used? A reason someone would choose auto orientation?

Have you seen it used on any sites yet?

I'm having trouble thinking of a case where you'd want the script to choose this option for you.

 

Even if the parent element is taller than it is wide, why does that mean a vertical slider is more appropriate?

Aside from being sorta technically neat, it seems like bloat to me. Seeing it in the docs confused me. 

[Paul Bakaus]

On Tue, Feb 17, 2009 at 1:28 PM, Scott Jehl <sc...@scottjehl.com> wrote:

Paul,

Can you explain a situation where this feature would be used? A reason someone would choose auto orientation?

Have you seen it used on any sites yet?

I'm having trouble thinking of a case where you'd want the script to choose this option for you.

 

Even if the parent element is taller than it is wide, why does that mean a vertical slider is more appropriate?

Aside from being sorta technically neat, it seems like bloat to me. Seeing it in the docs confused me. 

Exactly the opposite. It's not bloat to the user, it's removing one decision completely. This is exactly the same we're
doing on the sortable plugin. Rather than having the user choose float: true/false for every situation, we made
both sortable and slider smart enough to detect those, so the user doesn't need to care at all about those options.
That's the whole reason for it.

 

On Feb 17, 2009, at 3:51 AM, Paul Bakaus <paul....@googlemail.com> wrote:

The orientation detection is incredibly simple. It just checks if the height is greater than the slider width, and if that's true, the orientation is 'vertical', if not, it's horizontal. That sounds like pretty common to me. Maybe all we need is to change the check a bit, to default to 'horizontal' in equal (0 == 0) situations.

-1 for removing auto as option

On Mon, Feb 16, 2009 at 10:36 PM, Scott González <scott.g...@gmail.com> wrote:

On Mon, Feb 16, 2009 at 3:51 PM, Richard D. Worth <rdw...@gmail.com> wrote:

+1

Auto is going to be a very hard default to test unless it's very well specified. Let's change the default back to horizontal as that's the most common case (as all our defaults should be) and remove auto for now. If someone specifies vertical, we now have a default height of 100px, which should make it easier.

+1 for removing auto as a valid option and setting the default to horizontal

--

Paul Bakaus
UI Architect
--
http://paulbakaus.com
http://www.linkedin.com/in/paulbakaus

[Richard D. Worth]

Also, what happens when the size of the container changes? Is it auto on init or is it auto always?

And if it's set to auto, checking whether the slider is vertical or horizontal is not as simple as checking the value of the orientation option, but you'd have to check the element for a ui-slider-horizontal or ui-slider-vertical class.

- Richard

[Paul Bakaus]

On Tue, Feb 17, 2009 at 1:34 PM, Richard D. Worth <rdw...@gmail.com> wrote:

Also, what happens when the size of the container changes? Is it auto on init or is it auto always?

And if it's set to auto, checking whether the slider is vertical or horizontal is not as simple as checking the value of the orientation option, but you'd have to check the element for a ui-slider-horizontal or ui-slider-vertical class.

Right now, it's already rechecking the orientation on _setData, but it's not changing anything, so we would need to toggle those classes I guess, and a couple different things. This also applies of course if you manually change it from horizontal to vertical etc.
 

[Richard D. Worth]

On Tue, Feb 17, 2009 at 7:42 AM, Paul Bakaus <paul....@googlemail.com> wrote:

On Tue, Feb 17, 2009 at 1:34 PM, Richard D. Worth <rdw...@gmail.com> wrote:

Also, what happens when the size of the container changes? Is it auto on init or is it auto always?

And if it's set to auto, checking whether the slider is vertical or horizontal is not as simple as checking the value of the orientation option, but you'd have to check the element for a ui-slider-horizontal or ui-slider-vertical class.

Right now, it's already rechecking the orientation on _setData, but it's not changing anything, so we would need to toggle those classes I guess, and a couple different things.

I should've mentioned, I'm not suggesting we do so. If someone creates a slider and it's horizontal, it should remain horizontal. If someone wants a layout change to make the orientation of a slider change, they should do that manually. Auto currently seems to mean auto-detect on init. After that it's pretty well fixed. So I see two problems:

1. the default value of orientation means you can't expect what orientation the slider will have. Say for example someone has their browser set to be 100px wide. This could make the slider suddenly become vertical (depending on the container). They could then resize their browser and the slider would remain vertical.

2. the value of the orientation option (when set to auto, the current default) is of almost no use, because it doesn't tell you the orientation of the slider.

I don't believe we should detect and react to a change in a slider's relative width and height, so it would follow that we shouldn't do the same at init.

- Richard

[Scott Jehl]

Sortable is different. If you float a sortable list, thats a distict layout decision resulting in a floated sortable. It's great the plugin detects the float, but I wouldn't have expected I'd need an option for that anyway.  why is float a public option? This is a valid case for auto detection but I think most users would assume  you could sort a floated list anyway. We handle the complexity of making that sort work.

Back to slider, just because I drop a slider into a tall div, it doesn't mean I want a vertical slider. Vertical sliders are less common and when they're needed, it's easy to specify you want one. 

Did you see my $('<div></div>') example?  

[Todd Parker]

From a designer's perspective, I can't see a situation where I'd put a
slider on a page and not have a really clear idea of the orientation
and size I want it to be. It makes no sense to use 'auto' which is to
say "put a slider on the page, I don't care how it looks". Having the
script calculate things for collision detection for menus or flat for
draggable is nice but this is a situation where I *want* to make a
decision. It's like saying "put in a tab strip, I don't care it the
tabs are on the top or left". It would never happen in the real world.

On Feb 17, 7:53 am, "Richard D. Worth" <rdwo...@gmail.com> wrote:
> On Tue, Feb 17, 2009 at 7:42 AM, Paul Bakaus <paul.bak...@googlemail.com>wrote:

[Paul Bakaus]

This breaks our API though. We were originally commiting to the idea that you can always change options at a later point after init. Do you really think we should make an exception here?
 

- Richard

[Paul Bakaus]

On Tue, Feb 17, 2009 at 1:58 PM, Scott Jehl <sc...@scottjehl.com> wrote:

Sortable is different. If you float a sortable list, thats a distict layout decision resulting in a floated sortable. It's great the plugin detects the float, but I wouldn't have expected I'd need an option for that anyway.  why is float a public option? This is a valid case for auto detection but I think most users would assume  you could sort a floated list anyway. We handle the complexity of making that sort work.

Back to slider, just because I drop a slider into a tall div, it doesn't mean I want a vertical slider. Vertical sliders are less common and when they're needed, it's easy to specify you want one. 

Did you see my $('<div></div>') example?

It's bad that this specific example breaks, yeah. This should be fixed, so in the orientation detection, the fallback is horizontal, not vertical.
 

[Richard D. Worth]

I don't think we should make an exception here, which is why I believe this should not be an option.

- Richard

[Scott Jehl]

Btw- we went to great lengths to make a slider stretch to fit it's container for this very reason. It's entirely percentage based to fit into whater you put it in and even scales when the parent resizes without need for scripting.

Still though, a use case would be helpful to hear. If you're okay with this being a nondefault option, what purpose does it serve? You aren't removing a user decision because auto would need to be specified explicitly

[Paul Bakaus]

On Tue, Feb 17, 2009 at 2:01 PM, Todd Parker <fg....@gmail.com> wrote:

From a designer's perspective, I can't see a situation where I'd put a
slider on a page and not have a really clear idea of the orientation
and size I want it to be. It makes no sense to use 'auto' which is to
say "put a slider on the page, I don't care how it looks". Having the
script calculate things for collision detection for menus or flat for
draggable is nice but this is a situation where I *want* to make a
decision. It's like saying "put in a tab strip, I don't care it the
tabs are on the top or left". It would never happen in the real world.

Of course you care about if the tabs are top or left. But isn't it cool that
the script /knows/ what you want in advance, so you don't need to use
the option at all?
 

[Paul Bakaus]

So you mean we should remove orientation all together, and auto detect always? That's the only way I could imagine not breaking the API.
 

- Richard

[Paul Bakaus]

On Tue, Feb 17, 2009 at 2:07 PM, Scott Jehl <sc...@scottjehl.com> wrote:

Btw- we went to great lengths to make a slider stretch to fit it's container for this very reason. It's entirely percentage based to fit into whater you put it in and even scales when the parent resizes without need for scripting.

Still though, a use case would be helpful to hear. If you're okay with this being a nondefault option, what purpose does it serve? You aren't removing a user decision because auto would need to be specified explicitly

That's not a real option - as you're saying, there would be no benefit. The benefit of auto is, and always was, that the user doesn't have to care about the orientation option - at all. It's just another abstraction that's taken from the user.
 

[Richard D. Worth]

No, I'm saying remove the option to auto detect orientation. Default value is horizontal, and you can specify vertical.

- Richard

[Scott González]

On Tue, Feb 17, 2009 at 8:04 AM, Paul Bakaus <paul....@googlemail.com> wrote:

I don't believe we should detect and react to a change in a slider's relative width and height, so it would follow that we shouldn't do the same at init.

This breaks our API though. We were originally commiting to the idea that you can always change options at a later point after init. Do you really think we should make an exception here?

This has nothing to do with our API.  The height and width are set through CSS, not the plugin, so changing them has nothing to do with the plugin's behavior.  You can still change the orientation at any time by explicitly setting the orientation option.

[Paul Bakaus]

But this still means that if you change the option later after init,the plugin needs to take care of anything needed internally and externally for it to work, i.e. the right classes.

- Richard

[Scott González]

On Tue, Feb 17, 2009 at 8:08 AM, Paul Bakaus <paul....@googlemail.com> wrote:

Of course you care about if the tabs are top or left. But isn't it cool that
the script /knows/ what you want in advance, so you don't need to use
the option at all?

It's not about cool, it's about useful.  We've already gotten complaints about this "cool" feature.  Nobody expects, or wants, this behavior.

[Scott Jehl]

still need a use case to see it's value.

This 'surprise me' feature broke our select-slider plugin.

There's no way it can tell what orientation I want based on its surroundings. If I have a tall left column of filters and append a slider, it'll see the tall parent and think I must want vertical. It would be wrong.

The logic is flawed and will confuse even team members, let alone end users

[Paul Bakaus]

Ok, I didn't know it was that independent.
 

[Paul Bakaus]

Cool == useful. We might have gotten complaints, but we've also received a lot praise for our smart way of auto-determining certain options. That being said, it's a small option, and I agree that there aren't many usecases probably, so I'm fine to agree to remove it in this specific setup.

That being said, this discussion helped to finally find the time to update the "Visions and Goals" page in our wiki with another very important paragraph that was missing before, titled "Elegant API": http://wiki.jqueryui.com/VisionAndGoals . Please always remember that we are commited to bring our users a much easier and more elegant experience than most other solutions, following the path of jQuery. Every option that we can abstract away (like we did for slider) should be removed (after careful consideration, obviously).