On Mon, 27 Apr 2015 02:31:06 +0200, t...@trellis.ch wrote:
-font size
-color contrast
Theoretical this should be solvable by the font sizes and the colour
theme the user does chose for the DE/WM. Colour themes shouldn't get
broken after updates of the DE/WM and if fonts are large, windows
On Sat, 25 Apr 2015 08:50:21 +0100, Will Godfrey wrote:
One of my pet hates is erratic implementation of tooltips... that
can't be disabled!
Tooltips showing the value instead of a description of the option IMO
are good.
___
Linux-audio-dev mailing list
On Fri, 24 Apr 2015 23:55:31 -0400, Tim E. Real wrote:
My centre-screen technique is in fact limited to half-screen
The real desk might be limited to, e.g. a mini mouse pad on a synth,
so the mouse wheel option could be very important to avoid huge mouse
movements. It's not only the screen that
On Sat, 25 Apr 2015 10:23:14 +0200, Thorsten Wilms wrote:
https://afaikblog.files.wordpress.com/2013/01/date-and-time.png
We already know a solution since decades. Checkboxes
+1
I see that on my iPad every day and never become used to it, there's
always doubt. I've never noticed such a bad thing
On Sat, Apr 25, 2015 at 11:01:54AM +0100, Will Godfrey wrote:
Tooltips showing the value instead of a description of the option IMO
are good.
Debatable. If I'm twiddling knobs to get a particular 'sound' I'm not at all
interested in what the numbers are. At a later date I might want to
On 24.04.2015 23:40, Fons Adriaensen wrote:
Consider a button that toggles between 'stop' and 'play'. Does
it show the current state of the player, or the one you get
when you click on it ?
Yes, a classic. It's the general problem that using any toggle-action
successfully requires the user to
On Fri, 24 Apr 2015 20:33:05 -0700 (PDT), Len Ovens wrote:
another idea for a touch screen:
1 touch control with finger one.
2 put finger two some distance away.
3 move finger two towards control to decrease value or farther away to
increase value.
4 lift both fingers. I am not sure if lift
On 25.04.2015 09:50, Will Godfrey wrote:
One of my pet hates is erratic implementation of tooltips... that can't be
disabled!
I'm not sure where I saw it ... an interesting alternative is to have a
status line in a static location. It can be used for tooltip text,
parameter values and
On Fri, 24 Apr 2015 22:18:57 -0400, Tim E. Real wrote:
What do you think?
Hi Tim,
if the mouse courser reaches a screen border, the mouse movement should
continue to increase/decrease the fader/knob value, but the mouse
cursor should stay at the boarder, without movement, close to the
knob/fader.
One of my pet hates is erratic implementation of tooltips... that can't be
disabled!
Either provide them for *every* control or not at all, and *please* provide a
way to disable them.
Ideally there should be a way to enable/disable them from every part of your
application, so that an experienced
Tim E. Real:
6: Now turn the mouse pointer back on. Done.
Ehm, missed on of the best parts:
6: Now return the mouse pointer to where it was when originally clicked.
7: Now turn the mouse pointer back on. Done.
Sounds like the perfect way to do it, and Radium works exactly the same
On Sat, 25 Apr 2015 10:53:07 +, Fons Adriaensen wrote:
Second, because that way I will learn the relation between the values
and the resulting sound, and be able to do the same on different HW or
SW without having to search blindly by twiddling the knobs.
Couldn't say better.
As I pointed
On Saturday 25 April 2015 03:50:21 Will Godfrey wrote:
One of my pet hates is erratic implementation of tooltips... that
can't be disabled!
+10
Either provide them for *every* control or not at all, and *please*
provide a way to disable them.
+100
Ideally there should be a way to
On Sat, 25 Apr 2015, Thorsten Wilms wrote:
I for one can't take anyone serious who thinks this is acceptable:
https://afaikblog.files.wordpress.com/2013/01/date-and-time.png
If one wanted to infer a guideline from that screenshot, it could be:
Make sure there is a huge gap between labels and
On 23.04.2015 21:55, Len Ovens wrote:
That is why being able to adjust with both horizontal and vertical
movement is a plus. Take a look at zita-mu1 for an example. It is also
important to continue watching the position of the mouse when it leaves
the application window.
Yes. If the linear
On Fri, 24 Apr 2015, Thorsten Wilms wrote:
I think in many cases, horizontal sliders with labels and numerical values
inside the slider area, are the better approach.
Like knobs, sliders can be done right or wrong too. Pick up a handy
android device for examples of wrong. (In audio
On Fri, Apr 24, 2015 at 01:14:08AM +0200, t...@trellis.ch wrote:
The only point i'd challenge is that play around a bit isn't useful. I
even think if developers don't do it themselves, it's absolutely necessary
that users do it. If you're too focused on stuff that should work, you
won't find
On Fri, Apr 24, 2015 at 2:26 PM, Len Ovens l...@ovenwerks.net wrote:
In my opinion the best slider will allow the pointing device (finger or
mouse) to be placed anywhere on the slider and moving the mouse will move
the value from where it was in the direction the finger moves. (Ardour fader
On April 24, 2015 10:04:36 AM Thorsten Wilms wrote:
On 23.04.2015 21:55, Len Ovens wrote:
That is why being able to adjust with both horizontal and vertical
movement is a plus. Take a look at zita-mu1 for an example. It is also
important to continue watching the position of the mouse when
On April 24, 2015 10:04:36 AM Thorsten Wilms wrote:
With pointer-based usage, you can allow the pointer to go beyond the
edge. Some 3D application will have the pointer appear on the other
side, as if it traveled through a portal. But with touch, you are out of
luck, have to move the active area
On April 24, 2015 10:18:57 PM Tim E. Real wrote:
6: Now turn the mouse pointer back on. Done.
Ehm, missed on of the best parts:
6: Now return the mouse pointer to where it was when originally clicked.
7: Now turn the mouse pointer back on. Done.
Although, realizing now that when using this
On 23.04.2015 22:59, Fons Adriaensen wrote:
And in the case I mentioned (flight deck displays and user interfaces)
were are talking about*specialists* in ergonomics who have conducted
a not one but a series of studies and experiments involving a large
group of*expert* users and costing tons of
On Fri, Apr 24, 2015 at 09:47:16AM +0200, Thorsten Wilms wrote:
Writing a letter sitting safely at a desk leads to slightly
different requirements for a UI than piloting an airplane ...
Certainly. But mixing a live show or controlling a complex
broadcast setup would be more similar.
You do
Am 23.04.2015 um 13:49 schrieb Thorsten Wilms:
On 23.04.2015 11:50, Vytautas Jancauskas wrote:
Who would think that having to operate a circular knob by moving the
mouse in a little circle is convenient? It's also a bit harder to
implement. Is there some argument for it I am not aware of?
On 4/23/2015 2:10 PM, Hermann Meyer wrote:
Am 23.04.2015 um 13:49 schrieb Thorsten Wilms:
On 23.04.2015 11:50, Vytautas Jancauskas wrote:
Who would think that having to operate a circular knob by moving the
mouse in a little circle is convenient? It's also a bit harder to
implement. Is
On Thu, 23 Apr 2015, Ivica Ico Bukvic wrote:
One thing that comes really handy here is using a modifier, like shift or
ctrl that does micro-adjustments vs. regular adjustments. Ideally, when this
is coupled with an editable number box, you get the best of both worlds.
Yes that is helpful...
On 23.04.2015 20:51, Ivica Ico Bukvic wrote:
One thing that comes really handy here is using a modifier, like shift
or ctrl that does micro-adjustments vs. regular adjustments. Ideally,
when this is coupled with an editable number box, you get the best of
both worlds.
Support for modifiers is
One issue is the placement of the knob relative to the edges of the screen
and what you do when the pointer (ignoring touch) reaches them.
That is why being able to adjust with both horizontal and vertical
movement is a plus. Take a look at zita-mu1 for an example. It is also
important to
On Thu, Apr 23, 2015 at 07:47:50AM +0200, Thijs van severen wrote:
People writing 'GUI standards' and trying to force them on everyone
should have a look at e.g. a modern 'glass cockpit'.
We are not talking about someone that suddenly decided to make up there own
set rules and then tried
On Wed, Apr 22, 2015 at 11:39 PM, Fons Adriaensen f...@linuxaudio.org
wrote:
On Wed, Apr 22, 2015 at 06:34:25AM -0700, Len Ovens wrote:
A knob is ok if it works similar. Knobs that insist that I touch the
knob pointer and move that in a tiny arch to adjust and where the
pointer flips from
Gianfranco,
Thanks for your comment. I wholeheartedly agree. Target audience is a super
important question in these matters.
On Thu, Apr 23, 2015 at 1:01 PM, Gianfranco Ceccolini
gianfra...@portalmod.com.br wrote:
Hi eveyone
Although I normally refrain from entering this kind of
On Thu, Apr 23, 2015 at 12:50:06PM +0300, Vytautas Jancauskas wrote:
On Wed, Apr 22, 2015 at 11:39 PM, Fons Adriaensen f...@linuxaudio.org
wrote:
On Wed, Apr 22, 2015 at 06:34:25AM -0700, Len Ovens wrote:
A knob is ok if it works similar. Knobs that insist that I touch the
knob
Hi eveyone
Although I normally refrain from entering this kind of discussions, I just
can help myself from entering this particular one :-)
I think that the point that most of us are missing is that, prior to decide
the features on a particular product (a software in the discussed cases),
one
On 23.04.2015 12:01, Gianfranco Ceccolini wrote:
I think that the point that most of us are missing is that, prior to
decide the features on a particular product (a software in the discussed
cases), one needs to decide THE TARGET AUDIENCE of such product.
There are cases where defining a
On 23.04.2015 11:50, Vytautas Jancauskas wrote:
Who would think that having to operate a circular knob by moving the
mouse in a little circle is convenient? It's also a bit harder to
implement. Is there some argument for it I am not aware of?
Properly done radial knobs do not force you to move
Hi *,
Some good points, and interesting points of view. @Thijs van Severen:
I completed various UX / UI modules during my undergrad - that,
together with the most obvious lacks (IMO) of Linux Audio UX is what
prompted my composing of that exact list.
Tracey Hytry wrote:
a brief splash screen
On Thu, April 23, 2015 22:59, Fons Adriaensen wrote:
And in the case I mentioned (flight deck displays and user interfaces)
were are talking about *specialists* in ergonomics who have conducted a not
one but a series of studies and experiments involving a large group of
*expert* users and
On Wed, Apr 22, 2015 at 6:05 AM, Louigi Verona louigi.ver...@gmail.com
wrote:
Linux Audio packages are plagued by reasons that are relevant to the
developer, but which should be irrelevant to the user.
I don't care if dev thinks knobs are a bad idea, I want a knob and not a
text field,
On Wed, Apr 22, 2015 at 6:05 AM, Louigi Verona louigi.ver...@gmail.com wrote:
Linux Audio packages are plagued by reasons that are relevant to the
developer, but which should be irrelevant to the user.
I don't care if dev thinks knobs are a bad idea, I want a knob and
not
Sure. This was only an example. It could have been any other feature or GUI
element.
On Wed, Apr 22, 2015 at 3:43 PM, Paul Davis p...@linuxaudiosystems.com
wrote:
On Wed, Apr 22, 2015 at 6:05 AM, Louigi Verona louigi.ver...@gmail.com
wrote:
Linux Audio packages are plagued by reasons that
On Wed, Apr 22, 2015 at 06:34:25AM -0700, Len Ovens wrote:
A knob is ok if it works similar. Knobs that insist that I touch the
knob pointer and move that in a tiny arch to adjust and where the
pointer flips from one end to the other if I make the wrong move are
not easier to move on
On Wed, Apr 22, 2015 at 08:43:11AM -0400, Paul Davis wrote:
Just one little note here. Back in 2001, I read an article in the US
Keyboard magazine that made a strong case for stopping the use of
skuomorphic GUIs (knobs etc) for a variety of reasons. It wasn't written by
a software developer,
Op 23-apr.-2015 00:14 schreef Fons Adriaensen f...@linuxaudio.org:
On Wed, Apr 22, 2015 at 08:43:11AM -0400, Paul Davis wrote:
Just one little note here. Back in 2001, I read an article in the US
Keyboard magazine that made a strong case for stopping the use of
skuomorphic GUIs (knobs
I would like to comment on two things in your list:
Am 19.04.2015 um 00:40 schrieb Harry van Haaren:
1: Splash Screen
I would rephrase that to: show something as quickly as possible. If you
need to load stuff, do it in the background, but show the main GUI
window already (possibly with a
Hey everyone!
I was reading what you, Fons, wrote, and I must say that I very strongly
disagree with the direction your arguments are taking.
1. If a developer holds some views that go against those of the average
user he will have some very good reasons for that.
I guess this is irrelevant
2015-04-21 8:21 GMT+02:00 Gordonjcp gordon...@gjcp.net:
On Tue, Apr 21, 2015 at 08:16:05AM +0200, Thijs van severen wrote:
We need to be aware of the fact that most people on this list are devs
and
therefore do NOT represent the average user
In other words : I dont like splash screens so
Hi Harry
Just wondering where you got your inspriation for the above list?
There are of course numerous documents on ui design .Something like this
http://www.ambysoft.com/essays/userInterfaceDesign.html (but there are
better documents that go into the details. I just i cant find them right
now
On Tue, Apr 21, 2015 at 08:16:05AM +0200, Thijs van severen wrote:
We need to be aware of the fact that most people on this list are devs and
therefore do NOT represent the average user
In other words : I dont like splash screens so i'm not going to implement
one is (IMHO) a very very wrong
On Tue, 21 Apr 2015 04:07:15 -0700
Tracey Hytry sha...@bayarea.net wrote:
As a user, a brief splash screen gives me a little feedback
that I actually clicked the program icon.
This is very much my view too.
It also tells me that if the program is not working correctly
after that, then I
On Tue, 21 Apr 2015 08:43:15 +0200, Thijs van severen wrote:
i dont think it has to be modal, and i'm also curious what other thing
you will be doing in those 3-5 sec that the splash is there
surprise me :-)
Maybe taking a look at the messages displayed in the terminal
emulation where the app
As a user, a brief splash screen gives me a little feedback
that I actually clicked the program icon.
It also tells me that if the program is not working correctly
after that, then I should start it from the command line
and trouble shoot it from there.
Most of what Harry stated in is post
On Tue, Apr 21, 2015 at 4:26 PM, Fons Adriaensen f...@linuxaudio.org
wrote:
Regarding shortcuts for close/quit etc.: they are not always
wanted. When I'm recording live I don't want any single key
or mouse click to accidentally interfere with that. It's bad
enough with e.g. Ardour's GUI -
On Tue, Apr 21, 2015 at 04:30:14PM -0400, Paul Davis wrote:
Hence the new Lock feature which disables all GUI interaction entirely
(except for a click on the lock window to unlock, of course).
If that is a new feature in A4 it's an excellent idea.
Regarding A4: I noticed that even when it
On Tue, Apr 21, 2015 at 08:16:05AM +0200, Thijs van severen wrote:
We need to be aware of the fact that most people on this list are devs and
therefore do NOT represent the average user
We also need to be aware of the following:
* Developers are not necessarily coding nerds who are
Nobody else has noticed this to date.
On Tue, Apr 21, 2015 at 4:47 PM, Fons Adriaensen f...@linuxaudio.org
wrote:
On Tue, Apr 21, 2015 at 04:30:14PM -0400, Paul Davis wrote:
Hence the new Lock feature which disables all GUI interaction entirely
(except for a click on the lock window to
Am Sat, 18. Apr 2015 um 23:40:10 +0100 schrieb Harry van Haaren:
Hi All,
Hi Harry,
1: Splash Screen
If an app takes more than one quarter of a second to open, use a
splash screen to give feedback. Feel free to contact me directly to
collaborate on a splash screen graphic if necessary.
On Sat, Apr 18, 2015 at 11:40:10PM +0100, Harry van Haaren wrote:
Hi All,
As promised just at the closing ceremony of LAC, an email opening the
discussion of User Experience on Linux Audio. To all Developers,
please use this as a checklist and consider supporting each item. It
will improve
On Sun, 19 Apr 2015, Markus Seeber wrote:
On 04/19/2015 01:35 PM, Gordonjcp wrote:
On Sat, Apr 18, 2015 at 11:40:10PM +0100, Harry van Haaren wrote:
1: Splash Screen
If an app takes more than one quarter of a second to open, use a
splash screen to give feedback. Feel free to contact me
On 04/19/2015 01:35 PM, Gordonjcp wrote:
On Sat, Apr 18, 2015 at 11:40:10PM +0100, Harry van Haaren wrote:
Hi All,
As promised just at the closing ceremony of LAC, an email opening the
discussion of User Experience on Linux Audio. To all Developers,
please use this as a checklist and
59 matches
Mail list logo
