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
auto
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 a
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 enab
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
"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
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
On Sat, 2015-04-25 at 12:36 +0200, Ralf Mardorf wrote:
> On Sat, 25 Apr 2015 11:01:54 +0100, Will Godfrey wrote:
> > On Sat, 25 Apr 2015 11:23:49 +0200
> > Ralf Mardorf wrote:
> >
> > > On Sat, 25 Apr 2015 08:50:21 +0100, Will Godfrey wrote:
> > > > One of my pet hates is erratic implementation o
On Sat, 25 Apr 2015 11:01:54 +0100, Will Godfrey wrote:
>On Sat, 25 Apr 2015 11:23:49 +0200
>Ralf Mardorf wrote:
>
>> 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 val
On 04/25/2015 09:43 AM, Thorsten Wilms wrote:
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 f
On Sat, 25 Apr 2015 11:23:49 +0200
Ralf Mardorf wrote:
> 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.
Debat
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 thin
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 lis
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 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 lif
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.
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 perhaps
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
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
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 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: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
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
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
On Fri, Apr 24, 2015 at 2:26 PM, Len Ovens 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
> for example, but
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 applicatio
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 kno
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, 24 Apr 2015 07:58:09 +0200, Thijs van severen wrote:
>If you are writing a softsynth that will be used by a pilot i guess you
>might want to use this approach
>If you want more people to be able to use it i sugest you dont. ;-)
>All kidding aside i think that Gianfranco nailed it when he wa
On Fri, April 24, 2015 07:58, Thijs van severen wrote:
> Op 23-apr.-2015 22:59 schreef "Fons Adriaensen" :
>> 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 expe
Op 23-apr.-2015 22:59 schreef "Fons Adriaensen" :
>
> 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 th
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 c
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
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
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... b
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 cont
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 there
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?
Pro
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 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
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 target
On Thu, Apr 23, 2015 at 12:50:06PM +0300, Vytautas Jancauskas wrote:
> On Wed, Apr 22, 2015 at 11:39 PM, Fons Adriaensen
> 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
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 discuss
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 nee
On Wed, Apr 22, 2015 at 11:39 PM, Fons Adriaensen
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 one end to
Op 23-apr.-2015 00:14 schreef "Fons Adriaensen" :
>
> 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 v
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 develope
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 stag
On Wed, Apr 22, 2015 at 6:05 AM, Louigi Verona 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, because i
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 loadin
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
wrote:
>
>
> On Wed, Apr 22, 2015 at 6:05 AM, Louigi Verona
> wrote:
>
>>
>> Linux Audio packages are plagued by reasons that are relevant to the
>> developer, but wh
On Wed, Apr 22, 2015 at 6:05 AM, Louigi Verona
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, because it is easier to
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
Nobody else has noticed this to date.
On Tue, Apr 21, 2015 at 4:47 PM, Fons Adriaensen
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 unlock, of cour
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 4:26 PM, Fons Adriaensen
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 - every single pixe
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 complete
On Tue, 21 Apr 2015 04:07:15 -0700
Tracey Hytry 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 should start it
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 see
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
2015-04-21 8:21 GMT+02:00 Gordonjcp :
> 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 go
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 wro
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 :-)
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 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 directl
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 a
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 imp
66 matches
Mail list logo