21 Aug
2004
21 Aug
'04
1:46 a.m.
I just installed jack-rack and find the mouse wheel behavior a bit odd.
The sliders are horizontal, and turning the wheel 'up' (away from you)
decreases the slider value, and vice versa.
This seems backwards to me. What does everyone else think? This is one
of those things that will *have* to work the same way in every app,
otherwise it's maddening for users, so we had better agree on it now.
Alternatively, there has to be one place where this behavior can be set
for all apps. What is not acceptable is for 50% to do it one way and
50% the other.
What is really needed is a set of human interface guidelines for Linux
audio apps. Better to do this now, while much of the code is not
mature, than later, and have a bunch of different apps which work,
except that the widgets work completely different from one app to
another for no good reason other than that person A felt like doing it
like this and person B like that. You can talk about freedom all you
want but the users do not care about this kind of thing, it just looks
like the left hand is not talking to the right. Professional users
(rightfully) demand a consistent interface, unless there is a good
reason (extra functionality) not to provide one.
I would like to start putting these guidelines together. A good place
to start is to document the behavior of the most popular and mature
existing apps. Any suggestions are welcome.
Lee
21 Aug
21 Aug
4:43 a.m.
On Sat, Aug 21, 2004 at 01:30:59AM -0400, Lee Revell wrote:
I just installed jack-rack and find the mouse wheel
behavior a bit odd.
The sliders are horizontal, and turning the wheel 'up' (away from you)
decreases the slider value, and vice versa.
Both QT and GTK sliders work that way.
Anybody knows how it's on Windows or Mac OS?
I would argue with vertical sliders the high value should be at
the top, turning the wheel up should move the slider up, just
like with scrollbars.
Horizontal sliders should be seen as rotated 90 degress to the right,
so that highest value is to the right, to match with reading direction
(from low to high, just like you would put numbers in a row).
That means wheel up -> slider moves to the right.
The behaviour as described above seemed so naturaly to me, that
I never though about having it the other way for fan-sliders
But the standard set by QT/GTK is hard to ignore, at least as long
as normal sliders are used.
---
Thorsten Wilms
8:08 a.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
I never noticed the behavior of horizontal scrollbars in GTK because
I've never encountered any. Just checked out the behavior of
Rhthymbox's seek indicator, it's just as you described (i.e., dain
bramaged). That's a bug, plain and simple.
--Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
8:04 a.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] mouse wheel behavior and RFC: human interface guidelines
At Sat, 21 Aug 2004 01:30:59 -0400,
Lee Revell wrote:
What is really needed is a set of human interface guidelines for Linux
audio apps. Better to do this now, while much of the code is not
mature, than later, and have a bunch of different apps which work,
except that the widgets work completely different from one app to
another for no good reason other than that person A felt like doing it
like this and person B like that. You can talk about freedom all you
want but the users do not care about this kind of thing, it just looks
like the left hand is not talking to the right. Professional users
(rightfully) demand a consistent interface, unless there is a good
reason (extra functionality) not to provide one.
I definitely agree. One of the main reasons PHAT was created was
to encourage standard behavior across apps. I don't think folks
are terribly interested in actually getting this done, but it's
Really Important.
I'm all ears.
--Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
11:51 a.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] mouse wheel behavior and RFC: human interface guidelines
On Sat, Aug 21, 2004 at 01:30:59 -0400, Lee Revell wrote:
I just installed jack-rack and find the mouse wheel
behavior a bit odd.
The sliders are horizontal, and turning the wheel 'up' (away from you)
decreases the slider value, and vice versa.
This seems backwards to me. What does everyone else think? This is one
of those things that will *have* to work the same way in every app,
otherwise it's maddening for users, so we had better agree on it now.
Alternatively, there has to be one place where this behavior can be set
for all apps. What is not acceptable is for 50% to do it one way and
50% the other.
In jack-rack I would expect it to scroll the window. I generally have
enough plugins in the window that it wont all fit on one screen.
- Steve
4:14 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] mouse wheel behavior and RFC: human interface guidelines
On Sat, 2004-08-21 at 11:35, Steve Harris wrote:
On Sat, Aug 21, 2004 at 01:30:59 -0400, Lee Revell
wrote:
I agree, unless you are mousing directly over the 'grabbable' part of a
slider.
Lee
I just installed jack-rack and find the mouse
wheel behavior a bit odd.
The sliders are horizontal, and turning the wheel 'up' (away from you)
decreases the slider value, and vice versa.
This seems backwards to me. What does everyone else think? This is one
of those things that will *have* to work the same way in every app,
otherwise it's maddening for users, so we had better agree on it now.
Alternatively, there has to be one place where this behavior can be set
for all apps. What is not acceptable is for 50% to do it one way and
50% the other.
In jack-rack I would expect it to scroll the window. I generally have
enough plugins in the window that it wont all fit on one screen.
12:21 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 2004-08-21 at 01:30, Lee Revell wrote:
I just installed jack-rack and find the mouse wheel
behavior a bit odd.
The sliders are horizontal, and turning the wheel 'up' (away from you)
decreases the slider value, and vice versa.
This seems backwards to me. What does everyone else think?
Yep, definitely backwards.
-DR-
12:55 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
Hi,
it's backwards in a "numerical" sense, in that the numbers increase with
one slider type, but decrease with another, using the same command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left to
right, top to bottom. Therefore, up MUST map to left, down MUST map to
right, otherwise, non-mathematically minded people get uttely confused.
Melanie
On 2004.08.21 18:07 Dave Robillard wrote:
On Sat, 2004-08-21 at 01:30, Lee Revell wrote:
I just installed jack-rack and find the mouse
wheel behavior a bit odd.
The sliders are horizontal, and turning the wheel 'up' (away from you)
decreases the slider value, and vice versa.
This seems backwards to me. What does everyone else think?
Yep, definitely backwards.
-DR-
1:56 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
Hallo,
Melanie hat gesagt: // Melanie wrote:
Left is generally associated with up, right with down,
as we read left to
right, top to bottom. Therefore, up MUST map to left, down MUST map to
right, otherwise, non-mathematically minded people get uttely confused.
Well, if I qualify as mathematically minded: I think left is smaller
than right, as in a coordinate system:
... -2 ... -1 ... 0 ... 1 ... 2 ...
Ciao
--
Frank Barknecht _ ______footils.org__
2:09 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 21 Aug 2004 18:35:44 +0200
Melanie <melanie(a)t-data.com> wrote:
Hi,
it's backwards in a "numerical" sense, in that the numbers increase
with one slider type, but decrease with another, using the same
command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left
to right, top to bottom. Therefore, up MUST map to left, down MUST map
to right, otherwise, non-mathematically minded people get uttely
confused.
Melanie
Hmm, i cannot believe that users really expect the horizontal scrollbars
to go right when wheeling down. That just doesn't feel natural at all.
Has there been research done? I would like to see some sources to back
that up..
flo
2:31 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
Hi,
On 2004.08.21 20:05 Florian Schmidt wrote:
Hmm, i cannot believe that users really expect the
horizontal scrollbars
to go right when wheeling down. That just doesn't feel natural at all.
Well, it does feel perfectly natural to me...
Has there been research done? I would like to see some
sources to back
that up..
Micro$oft has done the most extensive UI research known to man. Their
sliders move left when wheeling up.... go figure!
Melanie
4:28 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 02:06 pm, Melanie wrote:
Hi,
On 2004.08.21 20:05 Florian Schmidt wrote:
They do have some other motivations.
Hmm, i cannot believe that users really expect
the horizontal scrollbars
to go right when wheeling down. That just doesn't feel natural at all.
Well, it does feel perfectly natural to me...
Has there been research done? I would like to see
some sources to back
that up..
Micro$oft has done the most extensive UI research known to man. Their
sliders move left when wheeling up.... go figure!
Melanie
4:42 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 21 Aug 2004 20:06:01 +0200
Melanie <melanie(a)t-data.com> wrote:
Hmmm. I never knew windows could even do this. Well it's been a while :)
I personnally would wish at least for user configurability so everyone
can have it to his/her liking..
flo
Hi,
On 2004.08.21 20:05 Florian Schmidt wrote:
Ok, then it's different for the two of us. Reading the responses of the
others here i think the vast majority of people would prefer it my way
[of course this conclusion is based on very very thin empiric data :)].
But w/o further research we cannot make a judgement about which way
is "right".. Especially as there is no "right" way as we can see in
this
thread..
Hmm, i cannot believe that users really expect
the horizontal
scrollbars to go right when wheeling down. That just doesn't feel
natural at all.
Well, it does feel perfectly natural to me... Has there been research done? I would like to see
some sources to
back that up..
Micro$oft has done the most extensive UI research known to man. Their
sliders move left when wheeling up.... go figure!
4:27 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 02:05 pm, Florian Schmidt wrote:
On Sat, 21 Aug 2004 18:35:44 +0200
Melanie <melanie(a)t-data.com> wrote:
I guess that would depend on the direction their native language is read in.
Hi,
it's backwards in a "numerical" sense, in that the numbers increase
with one slider type, but decrease with another, using the same
command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left
to right, top to bottom. Therefore, up MUST map to left, down MUST map
to right, otherwise, non-mathematically minded people get uttely
confused.
Melanie
Hmm, i cannot believe that users really expect the horizontal scrollbars
to go right when wheeling down. That just doesn't feel natural at all.
Has there been research done? I would like to see some
sources to back
that up..
flo
2:11 p.m.
it's backwards in a "numerical" sense, in
that the numbers increase with
one slider type, but decrease with another, using the same command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left to
right, top to bottom. Therefore, up MUST map to left, down MUST map to
right, otherwise, non-mathematically minded people get uttely confused.
this doesn't seem right to me. in all countries that use left->right
writing conventions, i think right is considered the default
"up".
also, when i think of road driving signs used to indicate significant
uphill or downhill sections, my recollection is that in the US and in
Europe they obey this right=up association if they actually show the
slope.
--p
2:43 p.m.
On Sat, Aug 21, 2004 at 01:56:03PM -0400, Paul Davis wrote:
also, when i think of road driving signs used to
indicate significant
uphill or downhill sections, my recollection is that in the US and in
Europe they obey this right=up association if they actually show the
slope.
IIRC correctly, it's different for ascending and downward slopes.
left is start, right is end, which could be up or down, at least in
germany:
http://www.vkwodw.de/vk_zeichen/z_110.htm
http://www.vkwodw.de/vk_zeichen/z_108.htm
bests,
martin
4:24 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 2004-08-21 at 14:26, martin rumori wrote:
On Sat, Aug 21, 2004 at 01:56:03PM -0400, Paul Davis
wrote:
LOL. In the USA, where the '12%' is, there would just be a truck, so
you can immediately see whether its an up or a down slope.
The '12%' would be below the whole thing.
Lee
also, when i think of road driving signs used to
indicate significant
uphill or downhill sections, my recollection is that in the US and in
Europe they obey this right=up association if they actually show the
slope.
IIRC correctly, it's different for ascending and downward slopes.
left is start, right is end, which could be up or down, at least in
germany:
http://www.vkwodw.de/vk_zeichen/z_110.htm
http://www.vkwodw.de/vk_zeichen/z_108.htm
2:26 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
At Sat, 21 Aug 2004 18:35:44 +0200,
Melanie wrote:
Left is generally associated with up, right with down, as we read
left to right, top to bottom. Therefore, up MUST map to left, down
MUST map to right, otherwise, non-mathematically minded people get
uttely confused.
This is perhaps the archetypal example of how a useful concept (making
connections between the UI and the Real World) gets turned into a
religion at the expense of that which it putatively helps and the
profit of...
uh...
yeah.
There's too much of this everywhere, but the infection seems to be
particularly insidious in CompSci (I LOST 25 POUNDS IN TWO WEEKS WITH
OOP) and UI design (pixels, being small, become unusable in light of
Fitt's law; they MUST be discarded).
I guarantee you that the last thing on 99.8% of users' minds when
they're adjusting a horizontal volume slider is "This is kind of like
reading a book, which goes left to right and top to bottom; and if we
assume an association between beginnings and ends, then it follows
that left and up are vaguely synonymous. Therefore, to decrease the
volume with my mousewheel, I MUST spin up."
Bah, humbug.
--Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
P.S. Guess what profession/hobby the remaining 0.2% have.
4:31 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 02:10 pm, Pete Bessman wrote:
At Sat, 21 Aug 2004 18:35:44 +0200,
Melanie wrote:
Indeed.
Left is generally associated with up, right with
down, as we read
left to right, top to bottom. Therefore, up MUST map to left, down
MUST map to right, otherwise, non-mathematically minded people get
uttely confused.
This is perhaps the archetypal example of how a useful concept (making
connections between the UI and the Real World) gets turned into a
religion at the expense of that which it putatively helps and the
profit of...
uh...
yeah.
There's too much of this everywhere, but the infection seems to be
particularly insidious in CompSci (I LOST 25 POUNDS IN TWO WEEKS WITH
OOP) and UI design (pixels, being small, become unusable in light of
Fitt's law; they MUST be discarded).
I guarantee you that the last thing on 99.8% of users' minds when
they're adjusting a horizontal volume slider is "This is kind of like
reading a book, which goes left to right and top to bottom; and if we
assume an association between beginnings and ends, then it follows
that left and up are vaguely synonymous. Therefore, to decrease the
volume with my mousewheel, I MUST spin up."
Nope, they try one way, then the other, then make a mental note if it doesn't
fit the expectation.
Bah, humbug.
--Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
P.S. Guess what profession/hobby the remaining 0.2% have.
4:40 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 2004-08-21 at 16:14, John Check wrote:
On Saturday 21 August 2004 02:10 pm, Pete Bessman
wrote:
Which is why is HAS to work the same way in every app. You can't expect
users to make mental notes of differences like this from app to app.
Lee
I guarantee you that the last thing on 99.8% of users' minds when
they're adjusting a horizontal volume slider is "This is kind of like
reading a book, which goes left to right and top to bottom; and if we
assume an association between beginnings and ends, then it follows
that left and up are vaguely synonymous. Therefore, to decrease the
volume with my mousewheel, I MUST spin up."
Nope, they try one way, then the other, then make a mental note if it doesn't
fit the expectation.
4:53 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 04:24 pm, Lee Revell wrote:
On Sat, 2004-08-21 at 16:14, John Check wrote:
I agree, but I think "should" is a more realistic position than "has
to".
On Saturday 21 August 2004 02:10 pm, Pete Bessman
wrote:
Which is why is HAS to work the same way in every app. You can't expect
users to make mental notes of differences like this from app to app.
I guarantee you that the last thing on 99.8% of
users' minds when
they're adjusting a horizontal volume slider is "This is kind of like
reading a book, which goes left to right and top to bottom; and if we
assume an association between beginnings and ends, then it follows
that left and up are vaguely synonymous. Therefore, to decrease the
volume with my mousewheel, I MUST spin up."
Nope, they try one way, then the other, then make a mental note if it
doesn't fit the expectation. Lee
5:06 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 2004-08-21 at 16:36, John Check wrote:
On Saturday 21 August 2004 04:24 pm, Lee Revell
wrote:
Sorry, I disagree. This kind of thing is MADDENING for users and makes
Linux look fly-by-night.
Of course, you can't force people to follow human interface guidelines
in the free software world. All we can do is carefully develop them
based on what users want, then if you choose not to comply you are
explicitly stating that you are hubristically choosing to ignore the
users need for a consistent experience.
Lee
On Sat, 2004-08-21 at 16:14, John Check wrote:
I agree, but I think "should" is a more realistic position than "has
to".
On Saturday 21 August 2004 02:10 pm, Pete Bessman
wrote:
Which is why is HAS to work the same way in every app. You can't expect
users to make mental notes of differences like this from app to app.
I guarantee you that the last thing on 99.8% of
users' minds when
they're adjusting a horizontal volume slider is "This is kind of like
reading a book, which goes left to right and top to bottom; and if we
assume an association between beginnings and ends, then it follows
that left and up are vaguely synonymous. Therefore, to decrease the
volume with my mousewheel, I MUST spin up."
Nope, they try one way, then the other, then make a mental note if it
doesn't fit the expectation.
5:48 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 04:51 pm, Lee Revell wrote:
On Sat, 2004-08-21 at 16:36, John Check wrote:
That presumes we have a monopoly on inconsistency. ;)
Having a consistent interface will definitely work to our advantage, but
I'm talking about near term when I say things like that. Being as I'm not
going to be the one coding, I can't say "must" or "has to".
On Saturday 21 August 2004 04:24 pm, Lee Revell
wrote:
Sorry, I disagree. This kind of thing is MADDENING for users and makes
Linux look fly-by-night.
On Sat, 2004-08-21 at 16:14, John Check wrote:
I agree, but I think "should" is a more realistic position than "has
to". On Saturday 21 August 2004 02:10 pm, Pete Bessman
wrote:
> I guarantee you that the last thing on 99.8% of users' minds when
> they're adjusting a horizontal volume slider is "This is kind of
> like reading a book, which goes left to right and top to bottom;
> and if we assume an association between beginnings and ends, then
> it follows that left and up are vaguely synonymous. Therefore, to
> decrease the volume with my mousewheel, I MUST spin up."
Nope, they try one way, then the other, then make a mental note if it
doesn't fit the expectation.
Which is why is HAS to work the same way in every app. You can't
expect users to make mental notes of differences like this from app to
app. Of course, you can't force people to follow human
interface guidelines
in the free software world. All we can do is carefully develop them
based on what users want, then if you choose not to comply you are
explicitly stating that you are hubristically choosing to ignore the
users need for a consistent experience.
And in that case one gets what one deserves. From what I can see so far
WRT proprietary stuff, there are a lot of little annoyances that add up to a
lot of opportunity for LA.
6:03 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 2004-08-21 at 17:31, John Check wrote:
Yes, see above. The list of annoyances people have with the 'state of
the art' in proprietary software is a major motivating factor for many
Linux audio developers. It should be the same way for users, but we are
not there yet.
Lee
Lee
On Saturday 21 August 2004 04:51 pm, Lee Revell
wrote:
It's easy enough (well it should be, I would imagine you can set this
behavior when you create a GTK slider, if not then it's a completely
reasonable feature request) for a coder to fix that I think we can
safely say it must work a certain way (in order to meet the Linux Audio
HIG that I guess I am proposing).
Right now, I would have the HIG state that this behavior must be
globally configurable. Globally for the sake of the above mentioned
consistency, and configurable because obviously one way is intuitive to
some people, and the other way to others.
On Sat, 2004-08-21 at 16:36, John Check wrote:
That presumes we have a monopoly on inconsistency. ;)
Having a consistent interface will definitely work to our advantage, but
I'm talking about near term when I say things like that. Being as I'm not
going to be the one coding, I can't say "must" or "has to".
On Saturday 21 August 2004 04:24 pm, Lee Revell
wrote:
Sorry, I disagree. This kind of thing is MADDENING for users and makes
Linux look fly-by-night.
On Sat, 2004-08-21 at 16:14, John Check wrote:
> On Saturday 21 August 2004 02:10 pm, Pete Bessman wrote:
> > I guarantee you that the last thing on 99.8% of users' minds when
> > they're adjusting a horizontal volume slider is "This is kind of
> > like reading a book, which goes left to right and top to bottom;
> > and if we assume an association between beginnings and ends, then
> > it follows that left and up are vaguely synonymous. Therefore, to
> > decrease the volume with my mousewheel, I MUST spin up."
>
> Nope, they try one way, then the other, then make a mental note if it
> doesn't fit the expectation.
Which is why is HAS to work the same way in every app. You can't
expect users to make mental notes of differences like this from app to
app.
I agree, but I think "should" is a more realistic position than "has
to". Of course, you
can't force people to follow human interface guidelines
in the free software world. All we can do is carefully develop them
based on what users want, then if you choose not to comply you are
explicitly stating that you are hubristically choosing to ignore the
users need for a consistent experience.
And in that case one gets what one deserves. From what I can see so far
WRT proprietary stuff, there are a lot of little annoyances that add up to a
lot of opportunity for LA.
6:59 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 05:47 pm, Lee Revell wrote:
Yes, see above. The list of annoyances people have with the 'state of
the art' in proprietary software is a major motivating factor for many
Linux audio developers. It should be the same way for users, but we are
not there yet.
Lee
Lee
On Sat, 2004-08-21 at 17:31, John Check wrote:
Sounds reasonable to me.
On Saturday 21 August 2004 04:51 pm, Lee Revell
wrote:
It's easy enough (well it should be, I would imagine you can set this
behavior when you create a GTK slider, if not then it's a completely
reasonable feature request) for a coder to fix that I think we can
safely say it must work a certain way (in order to meet the Linux Audio
HIG that I guess I am proposing).
Right now, I would have the HIG state that this behavior must be
globally configurable. Globally for the sake of the above mentioned
consistency, and configurable because obviously one way is intuitive to
some people, and the other way to others.
On Sat, 2004-08-21 at 16:36, John Check wrote:
That presumes we have a monopoly on inconsistency. ;)
Having a consistent interface will definitely work to our advantage, but
I'm talking about near term when I say things like that. Being as I'm not
going to be the one coding, I can't say "must" or "has to".
On Saturday 21 August 2004 04:24 pm, Lee Revell
wrote:
> On Sat, 2004-08-21 at 16:14, John Check wrote:
> > On Saturday 21 August 2004 02:10 pm, Pete Bessman wrote:
> > > I guarantee you that the last thing on 99.8% of users' minds
> > > when they're adjusting a horizontal volume slider is "This is
> > > kind of like reading a book, which goes left to right and top
> > > to bottom; and if we assume an association between beginnings
> > > and ends, then it follows that left and up are vaguely
> > > synonymous. Therefore, to decrease the volume with my
> > > mousewheel, I MUST spin up."
> >
> > Nope, they try one way, then the other, then make a mental note
> > if it doesn't fit the expectation.
>
> Which is why is HAS to work the same way in every app. You can't
> expect users to make mental notes of differences like this from app
> to app.
I agree, but I think "should" is a more realistic position than "has
to".
Sorry, I disagree. This kind of thing is MADDENING for users and makes
Linux look fly-by-night. Of course, you can't force people to follow human
interface guidelines
in the free software world. All we can do is carefully develop them
based on what users want, then if you choose not to comply you are
explicitly stating that you are hubristically choosing to ignore the
users need for a consistent experience.
And in that case one gets what one deserves. From what I can see so far
WRT proprietary stuff, there are a lot of little annoyances that add up
to a lot of opportunity for LA. 
22 Aug
22 Aug
9:56 a.m.
New subject: [linux-audio-dev] Re: mouse wheel behavior and RFC: human interface guidelines
John Check wrote:
no we don't ;)
on any system where one can install components there will allways be
inconsistency. mutations make sure the species... sorry interfaces evolve.
Sorry, I
disagree. This kind of thing is MADDENING for users and makes
Linux look fly-by-night.
That presumes we have a monopoly on inconsistency. ;) Having a consistent interface will definitely work to
our advantage, but
I'm talking about near term when I say things like that. Being as I'm not
going to be the one coding, I can't say "must" or "has to".
"consistent interface" is idealisation that professors of human
interaction use. it's a useful idealisation but it has troubled
surviving in the real world.
if the whole bunch of people sais the consistent behavior is braindead -
it's better off changed. after all the goal of consistency was to make
people not notice the interface.
>Of course, you can't force people to follow human interface guidelines
>in the free software world. All we can do is carefully develop them
>based on what users want, then if you choose not to comply you are
>explicitly stating that you are hubristically choosing to ignore the
>users need for a consistent experience.
people do not need consistent experience, people need to get the work
done. consistency is one of the tools that make getting the work done
easier, but it isn't a goal in itself.
2:33 p.m.
New subject: [linux-audio-dev] Re: mouse wheel behavior and RFC: human interface guidelines
On Sunday 22 August 2004 09:18 am, Artem Baguinski wrote:
John Check wrote:
no we don't ;)
on any system where one can install components there will allways be
inconsistency. mutations make sure the species... sorry interfaces evolve.
Hobgoblin of small minds and all that. ;) People do like to complain though,
so a spirit bead is always good.
Sorry, I
disagree. This kind of thing is MADDENING for users and makes
Linux look fly-by-night.
That presumes we have a monopoly on inconsistency. ;) Having a consistent interface will definitely
work to our advantage, but
I'm talking about near term when I say things like that. Being as I'm not
going to be the one coding, I can't say "must" or "has to".
"consistent interface" is idealisation that professors of human
interaction use. it's a useful idealisation but it has troubled
surviving in the real world.
if the whole bunch of people sais the consistent behavior is braindead -
it's better off changed. after all the goal of consistency was to make
people not notice the interface.
>Of course, you can't force people to
follow human interface guidelines
>in the free software world. All we can do is carefully develop them
>based on what users want, then if you choose not to comply you are
>explicitly stating that you are hubristically choosing to ignore the
>users need for a consistent experience.
people do not need consistent experience, people need to get the work
done. consistency is one of the tools that make getting the work done
easier, but it isn't a goal in itself.
23 Aug
23 Aug
11:25 a.m.
New subject: [linux-audio-dev] Re: mouse wheel behavior and RFC: human interface guidelines
At Sun, 22 Aug 2004 15:18:52 +0200,
Artem Baguinski wrote:
people do not need consistent experience, people need to get the work
done. consistency is one of the tools that make getting the work done
easier, but it isn't a goal in itself.
++kudos;
--Pete
<http://www.gazuga.net>
"Nothing great was ever achieved by being realistic!" --Tom Venuto
21 Aug
21 Aug
2:52 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, Aug 21, 2004 at 06:35:44PM +0200, Melanie wrote:
it's backwards in a "numerical" sense,
in that the numbers increase with
one slider type, but decrease with another, using the same command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left to
right, top to bottom. Therefore, up MUST map to left, down MUST map to
right, otherwise, non-mathematically minded people get uttely confused.
OK, if things 'increase' from L to R and from top to bottom,
then a vertical gain slider should have the 'off' position at
the top. For a slider controlling a frequency, the lowest
one should be at the top.
I suspect most people would find that counterintuitive,
regardless of reading directions.
--
FA
4:38 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 2004-08-21 at 14:38, Fons Adriaensen wrote:
On Sat, Aug 21, 2004 at 06:35:44PM +0200, Melanie
wrote:
I suspect that a GUI programmer or interface designer would expect
things to increase from top to bottom. In GUI programming, the origin
is at the top left of the screen, and X,Y coorinates increase going
right and down respectively. I am not sure why they didn't just follow
the Cartesian conventions here, but I believe it has been this way
forever.
However the fact that there are people who feel strongly both ways means
this NEEDS to be configurable in a control panel somewhere. Like
'invert mouse' in any FPS game - this is the intuitive way to play for
me, like a flight simulator, pushing forward with the mouse will tilt
you forward. However there are apparently anough people who feel both
ways that every FPS has this option.
Lee
it's backwards in a "numerical"
sense, in that the numbers increase with
one slider type, but decrease with another, using the same command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left to
right, top to bottom. Therefore, up MUST map to left, down MUST map to
right, otherwise, non-mathematically minded people get uttely confused.
OK, if things 'increase' from L to R and from top to bottom,
then a vertical gain slider should have the 'off' position at
the top. For a slider controlling a frequency, the lowest
one should be at the top.
I suspect most people would find that counterintuitive,
regardless of reading directions.
4:51 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 04:22 pm, Lee Revell wrote:
On Sat, 2004-08-21 at 14:38, Fons Adriaensen wrote:
For flightsims there is no question because when you push a yoke forward
you pitch down even in a chopper.
On Sat, Aug 21, 2004 at 06:35:44PM +0200, Melanie
wrote:
I suspect that a GUI programmer or interface designer would expect
things to increase from top to bottom. In GUI programming, the origin
is at the top left of the screen, and X,Y coorinates increase going
right and down respectively. I am not sure why they didn't just follow
the Cartesian conventions here, but I believe it has been this way
forever.
However the fact that there are people who feel strongly both ways means
this NEEDS to be configurable in a control panel somewhere. Like
'invert mouse' in any FPS game - this is the intuitive way to play for
me, like a flight simulator, pushing forward with the mouse will tilt
you forward. However there are apparently anough people who feel both
ways that every FPS has this option. it's backwards in a "numerical"
sense, in that the numbers increase
with one slider type, but decrease with another, using the same
command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left
to right, top to bottom. Therefore, up MUST map to left, down MUST map
to right, otherwise, non-mathematically minded people get uttely
confused.
OK, if things 'increase' from L to R and from top to bottom,
then a vertical gain slider should have the 'off' position at
the top. For a slider controlling a frequency, the lowest
one should be at the top.
I suspect most people would find that counterintuitive,
regardless of reading directions.
Lee
23 Aug
23 Aug
11:35 a.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, Aug 21, 2004 at 04:22:36PM -0400, Lee Revell wrote:
I suspect that a GUI programmer or interface designer
would expect
things to increase from top to bottom. In GUI programming, the origin
is at the top left of the screen, and X,Y coorinates increase going
right and down respectively. I am not sure why they didn't just follow
the Cartesian conventions here, but I believe it has been this way
forever.
I believe it's a historical artifact of early GUI software being
pretty close to the hardware. CRT screens put the origin at top
left and scan from left to right, top down.
--
Paul Winkler
http://www.slinkp.com
24 Aug
24 Aug
2:16 a.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Mon, 2004-08-23 at 11:19, Paul Winkler wrote:
On Sat, Aug 21, 2004 at 04:22:36PM -0400, Lee Revell
wrote:
OK, so if I were to start writing the Linux Audio Human Interface
Guidelines based on all of the feedback from this post, I would say
something like the following. I have used the type of language you
would find in an Internet RFC.
"Sliders MUST be operable with the mouse wheel. This MUST only be
enabled when mousing over a slider, otherwise, the mouse wheel MUST
retain its normal behavior of scrolling the window.
For a vertical slider, rolling the mouse button away from you
(hereafter: wheel-up event) MUST increase the value of the parameter,
and wheel-down MUST decrease the value.
For a horizontal slider, wheel-up SHOULD increase the value, and
wheel-down SHOULD decrease the value by default. However, this behavior
MUST be configurable system-wide. If a system-wide facility to control
this is unavailable then the app MUST provide a configuration
mechanism."
Additional submissions are welcome.
Lee
I suspect that a GUI programmer or interface
designer would expect
things to increase from top to bottom. In GUI programming, the origin
is at the top left of the screen, and X,Y coorinates increase going
right and down respectively. I am not sure why they didn't just follow
the Cartesian conventions here, but I believe it has been this way
forever.
I believe it's a historical artifact of early GUI software being
pretty close to the hardware. CRT screens put the origin at top
left and scan from left to right, top down.
2:57 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Tuesday 24 August 2004 02:00 am, Lee Revell wrote:
On Mon, 2004-08-23 at 11:19, Paul Winkler wrote:
No arguments here.
On Sat, Aug 21, 2004 at 04:22:36PM -0400, Lee
Revell wrote:
OK, so if I were to start writing the Linux Audio Human Interface
Guidelines based on all of the feedback from this post, I would say
something like the following. I have used the type of language you
would find in an Internet RFC.
"Sliders MUST be operable with the mouse wheel. This MUST only be
enabled when mousing over a slider, otherwise, the mouse wheel MUST
retain its normal behavior of scrolling the window.
For a vertical slider, rolling the mouse button away from you
(hereafter: wheel-up event) MUST increase the value of the parameter,
and wheel-down MUST decrease the value.
For a horizontal slider, wheel-up SHOULD increase the value, and
wheel-down SHOULD decrease the value by default. However, this behavior
MUST be configurable system-wide. If a system-wide facility to control
this is unavailable then the app MUST provide a configuration
mechanism."
Additional submissions are welcome.
Lee I suspect that a GUI programmer or interface
designer would expect
things to increase from top to bottom. In GUI programming, the origin
is at the top left of the screen, and X,Y coorinates increase going
right and down respectively. I am not sure why they didn't just follow
the Cartesian conventions here, but I believe it has been this way
forever.
I believe it's a historical artifact of early GUI software being
pretty close to the hardware. CRT screens put the origin at top
left and scan from left to right, top down.
21 Aug
21 Aug
3:01 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, Aug 21, 2004 at 06:35:44PM +0200, Melanie wrote:
Hi,
it's backwards in a "numerical" sense, in that the numbers increase with
one slider type, but decrease with another, using the same command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left to
right, top to bottom. Therefore, up MUST map to left, down MUST map to
right, otherwise, non-mathematically minded people get uttely confused.
I couldn't find anything on the web abou this.
But I asume the behaviour was thought out for
scrollbars and transfered to sliders.
With scrollbars scrolling lets say a table, the vertical scrollbar
has top = start, bottom = end. Horizontal scrollbar left = start,
right = end. Wheeling up on vertical sliders means scrolling
toward the vertical start. Wheeling up on the horizontal slider
should therefor mean scrolling to the horizontal start -> scrolling
left.
But there's nothing to scroll with sliders. They're not about
a position in space.
Today might well have been the first time I used the wheel
on common sliders, and it felt backwards!
Fan-slider wheeling will stay as is, differing from QT and
GTK sliders. But I doubt the folks behind the toolkits would
listen and change wheeling direction.
---
Thorsten Wilms
4:57 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 2004-08-21 at 14:45, Thorsten Wilms wrote:
On Sat, Aug 21, 2004 at 06:35:44PM +0200, Melanie
wrote:
Very interesting. You are probably correct.
Hi,
it's backwards in a "numerical" sense, in that the numbers increase with
one slider type, but decrease with another, using the same command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left to
right, top to bottom. Therefore, up MUST map to left, down MUST map to
right, otherwise, non-mathematically minded people get uttely confused.
I couldn't find anything on the web abou this.
But I asume the behaviour was thought out for
scrollbars and transfered to sliders.
With scrollbars scrolling lets say a table, the vertical scrollbar
has top = start, bottom = end. Horizontal scrollbar left = start,
right = end. Wheeling up on vertical sliders means scrolling
toward the vertical start. Wheeling up on the horizontal slider
should therefor mean scrolling to the horizontal start -> scrolling
left.
But there's nothing to scroll with sliders.
They're not about
a position in space.
Today might well have been the first time I used the wheel
on common sliders, and it felt backwards!
Agreed. I can understand why Microsoft (and thus QT and GTK) chose to
do it this way, but I bet audio users make MUCH heavier use of sliders
than almost anyone else. So, an informal survey of Linux audio users is
actually pretty good data.
Fan-slider wheeling will stay as is, differing from QT
and
GTK sliders. But I doubt the folks behind the toolkits would
listen and change wheeling direction.
True, no reason to break it for people who are used to the old behavior,
and MS does do extensive usability testing. However this NEEDS to be
made configurable system-wide. This way CCRMA and AGNULA (for example)
can ship with the non-default slider behavior if their users prefer it.
Lee
5:50 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 04:41 pm, Lee Revell wrote:
On Sat, 2004-08-21 at 14:45, Thorsten Wilms wrote:
The latter two, probably to fit in with the former. I think I may be missing
something because my KDE sliders work like I expect.
On Sat, Aug 21, 2004 at 06:35:44PM +0200, Melanie
wrote:
Very interesting. You are probably correct.
Hi,
it's backwards in a "numerical" sense, in that the numbers increase
with one slider type, but decrease with another, using the same
command.
However, UI designers don't think in numbers, but associations.
Left is generally associated with up, right with down, as we read left
to right, top to bottom. Therefore, up MUST map to left, down MUST map
to right, otherwise, non-mathematically minded people get uttely
confused.
I couldn't find anything on the web abou this.
But I asume the behaviour was thought out for
scrollbars and transfered to sliders.
With scrollbars scrolling lets say a table, the vertical scrollbar
has top = start, bottom = end. Horizontal scrollbar left = start,
right = end. Wheeling up on vertical sliders means scrolling
toward the vertical start. Wheeling up on the horizontal slider
should therefor mean scrolling to the horizontal start -> scrolling
left. But there's nothing to scroll with sliders.
They're not about
a position in space.
Today might well have been the first time I used the wheel
on common sliders, and it felt backwards!
Agreed. I can understand why Microsoft (and thus QT and GTK) chose to do it this way, but I bet audio users make MUCH
heavier use of sliders
than almost anyone else. So, an informal survey of Linux audio users is
actually pretty good data.
Fan-slider wheeling will stay as is, differing
from QT and
GTK sliders. But I doubt the folks behind the toolkits would
listen and change wheeling direction.
True, no reason to break it for people who are used to the old behavior,
and MS does do extensive usability testing. However this NEEDS to be
made configurable system-wide. This way CCRMA and AGNULA (for example)
can ship with the non-default slider behavior if their users prefer it.
Lee
6:05 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, 2004-08-21 at 17:33, John Check wrote:
On Saturday 21 August 2004 04:41 pm, Lee Revell
wrote:
Hmm, someone else said QT sliders work the same way as GTK. I don't
have KDE here so I can't tell.
Probably this behavior can be set at widget creation time.
Lee
On Sat, 2004-08-21 at 14:45, Thorsten Wilms
wrote:
The latter two, probably to fit in with the former. I think I may be missing
something because my KDE sliders work like I expect.
Today might well have been the first time I used
the wheel
on common sliders, and it felt backwards!
Agreed. I can understand why Microsoft (and thus QT and GTK) chose to
7:04 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 05:50 pm, Lee Revell wrote:
On Sat, 2004-08-21 at 17:33, John Check wrote:
It could be a windowmanager preference... Okay I see a "reverse scroll
direction" option in the KDE3.3 mouse configuration dialog.
How does this sound for a test..
I'll flip the preference, logout, log into a non KDE session, then see what
happens with a KDE app vs a QT app.
I have GNOME installed, but I generally don't use the desktop. If somebody is
a regular user and a similar option exists (I'm thinking it's probably in
Gconf) I suggest doing the same on the GTK side.
On Saturday 21 August 2004 04:41 pm, Lee Revell
wrote:
Hmm, someone else said QT sliders work the same way as GTK. I don't
have KDE here so I can't tell.
Probably this behavior can be set at widget creation time.
On Sat, 2004-08-21 at 14:45, Thorsten Wilms
wrote:
The latter two, probably to fit in with the former. I think I may be
missing something because my KDE sliders work like I expect. Today might well have been the first time I used
the wheel
on common sliders, and it felt backwards!
Agreed. I can understand why Microsoft (and thus QT and GTK) chose to Lee
7:30 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Saturday 21 August 2004 06:48 pm, John Check wrote:
On Saturday 21 August 2004 05:50 pm, Lee Revell
wrote:
Well, _that_ was enlightening.
I used Kmix for the sliders.
I flipped the setting in KDE and it took effect immediately contrary to the
request to log out and back in again.
I logged out and logged into GNOME using metacity as a WM and fired up Kmix.
It worked like it originally did before flipping the KDE scroll reverse
option.
The GNOME mouse configuratorizer didn't have a scroll toggle, but the main
menu had "Control Center" at the toplevel, so I opened it.
It was the KDE control center.
I checked the mouse scroll option and it was in "reverse", so I inverted it.
The Kmix sliders were now inverted. Apparently it sets relative to whatever
the window manager is doing when you start the CC applet. Since it was a
different windowmanager it probably didn't read the defaults on KDE side.
For kicks I tried it against the GNOME volume control applet and it was
consistent with the KDE app when changing the setting. Looks like it uses the
same mechanism WRT the windowmanager, but that doesn't tell us anything about
individual apps. Perhaps there is already a guideline somebody didn't apply.
I didn't try a plain QT app or other widget set, and I kind of forgot what
specific app kicked off this question, but that's the deal with Kmix and
whatever the GNOME mixer applet is called.
On Sat, 2004-08-21 at 17:33, John Check wrote:
It could be a windowmanager preference... Okay I see a "reverse scroll
direction" option in the KDE3.3 mouse configuration dialog.
How does this sound for a test..
I'll flip the preference, logout, log into a non KDE session, then see what
happens with a KDE app vs a QT app.
I have GNOME installed, but I generally don't use the desktop. If somebody
is a regular user and a similar option exists (I'm thinking it's probably
in Gconf) I suggest doing the same on the GTK side.
On Saturday 21 August 2004 04:41 pm, Lee Revell
wrote:
Hmm, someone else said QT sliders work the same way as GTK. I don't
have KDE here so I can't tell.
Probably this behavior can be set at widget creation time. On Sat, 2004-08-21 at 14:45, Thorsten Wilms
wrote:
> Today might well have been the first time I used the wheel
> on common sliders, and it felt backwards!
Agreed. I can understand why Microsoft (and thus QT and GTK) chose
to
The latter two, probably to fit in with the former. I think I may be
missing something because my KDE sliders work like I expect. > Lee
25 Aug
25 Aug
4:26 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
>>>> "Lee" == Lee Revell
<rlrevell(a)joe-job.com> writes:
True, no reason to break it for people who are used to
the old
behavior, and MS does do extensive usability testing. However
this NEEDS to be made configurable system-wide. This way CCRMA
and AGNULA (for example) can ship with the non-default slider
behavior if their users prefer it.
My AI-based whizbang `did-somebody-say-agnula?' filter just went on!
Jokes apart, I'm following the thread on AHIG (Audio Human Interface
Guidelines?) with much interest. Having a reference document on how
audio applications should interact with the user system-wide would be
a major plus.
Maybe, once you have a basic RFC prepared, you could post it on:
users(a)lists.agnula.org
(besides LAU and all other relevant mailing lists, of course)
so that those A/DeMuDi users that don't follow LAD can express their
opinion on the subject, too (after all, my guess is that user input is
what you need most, isn't it?).
Just so that you know,
--
Andrea Glorioso sama(a)miu-ft.org +39 333 820 5723
.:: Media Innovation Unit - Firenze Tecnologia ::.
Conquering the world for fun and profit
21 Aug
21 Aug
8:48 p.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On Sat, Aug 21, 2004 at 06:35:44PM +0200, Melanie wrote:
Left is generally associated with up, right with down,
as we read left to
right, top to bottom. Therefore, up MUST map to left, down MUST map to
right, otherwise, non-mathematically minded people get uttely confused.
That's crap. It makes no sense at ALL. I will never ever write software
where moving the wheel up moves a slider left. Sorry., Braindead.
22 Aug
22 Aug
11:54 a.m.
New subject: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines
On lör, 2004-08-21 at 07:30, Lee Revell wrote:
I just installed jack-rack and find the mouse wheel
behavior a bit odd.
The sliders are horizontal, and turning the wheel 'up' (away from you)
decreases the slider value, and vice versa.
This is not just you. Generally when you install software from FSF, you
will find that it works against you half (but *only* half) of the time.
Perhaps this is a a way of getting around silly patents ...
/jens
7190
days inactive
7194
days old
linux-audio-dev@lists.linuxaudio.org
43 comments
17 participants
participants (17)
-
Andrea Glorioso -
Artem Baguinski -
Dave Robillard -
Florian Schmidt -
Fons Adriaensen -
Frank Barknecht -
Jens M Andreasen -
John Check -
Lee Revell -
martin rumori -
Melanie -
Paul Davis -
Paul Winkler -
Pete Bessman -
Steve Harris -
Thorsten Wilms -
Tim Hockin