On Sun, 19 Apr 2015, Markus Seeber wrote: Wheres my popcorn? ;) In days gone by, save did actually mean put the data on a disk. Now it means put the data in some memory buffer that the OS will sooner or later put on the disk. The first meant that when the application said it was saved, I was ok if the power failed or the powerbar switch was hit. in the second... a shutdown sequence is a must. I agree that slowing down an app by putting progress indicators is less than optimal... at least make it possible to get rid of them. Time is money or at least has some value and none of us have any to "kill". Adding complexity for no real gain just feels wrong somehow. I have seen my workflow slowed down as Linux DEs have windowfied themselves unless I spend my time to turn this stuff off and optimise it. Having a splash screen in the middle of my work area for an app I have configured to open in a corner out of the way is anoying too. Of course I would rather someone developing software I use, spend time improving it rather than adding progress indicators... I suspect the deveoloper feels the same. -- Len Ovens www.ovenwerks.net

2015-04-21 8:21 GMT+02:00 Gordonjcp &lt;gordonjcp(a)gjcp.net&gt;et>: 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 :-) -- follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !

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 seems fine with me.

On Tue, Apr 21, 2015 at 08:16:05AM +0200, Thijs van severen wrote: We also need to be aware of the following: * Developers are not necessarily coding nerds who are completely isolated from the daily practice of using software. Most of them on this list are actually users themselves. * If a developer holds some views that go against those of the average user he will have some very good reasons for that. There is *no reason at all* to assume that the average user's ideas are 'the right ones'. Most people prefer unhealthy food with a high salt/fat/sugar content. Never mind if they get diabetes sooner or later. If someone goes against that and produces some healthy food then I don't think that is 'a very wrong attitude' as you put it. * They way typical Windows SW works is not dictated by user interest. If it were no user would ever have any reason to abondon Windows and go for Linux. It is determined entirely by the short-term views of marketeers. There is no reason at all to assume that the same logic should apply to free open source software. * Every time the Linux community adopts some stupid Windows 'standard' for the sole reason that it is 'what users expect', this goes against its own long term interests. If Linux ever becomes the perfect Windows clone then it has destroyed its main reason to exist, which is to be different and better. Regarding splash screens: yes, some apps take a long time to start up. In most cases that is because they have either become bloated themselves, or depend on interaction with bloated desktop environments. That is by itself good reason for concern. Using a splash screen to fix that is at best a bandaid. That doesn't mean that a splash screen is by itself a bad idea - but it certainly is if its only reason to exist is to hide the results of crappy design. 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 pixel of it will do something when clicked on, and the result is not always so benign. I've had a musician dropping his shoulder bag on a cable to a cardbus interface during a live recording. This ripped out the card and destroyed the mechanical card locking system. So having an accidental click or key pushed is not at all such a remote risk. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Tue, Apr 21, 2015 at 04:30:14PM -0400, Paul Davis wrote: If that is a new feature in A4 it's an excellent idea. Regarding A4: I noticed that even when it discovers that Jack is already running, it invites me to set the sample rate and period size. And the suggested values are not the ones actually used. What it the rationale for this ? IMHO no app should ever try to 'take control' of a running Jack instance at all - it's a shared service. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

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 to the average user. And it instantly puts your views outside of most people's workflow needs. Additionally, the phrase "good reasons" is too ambiguous. Good for who? Perhaps, it is good for the developer, but not for the user. 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 use on stage. I don't care if dev has a technical reason to have a text field instead of a knob. I need a knob, because it is easier to use on stage. In the end, what you are suggesting is developer-centered world, not user-centered. Which is fine philosophy, but then you should understand that the likely consequence of that would be software which is generally not useful to anyone but a select few. 2. "There is *no reason at all* to assume that the average user's ideas are 'the right ones'." Actually, there is very good reason. Things that end up in most software are things that have survived the evolution and natural selection of software. Standard user interfaces are backed up by the endorsement of many-many actual users, who havin invested in the software, who have used it professionally and have chosen them over other user interfaces. Just look at the history of DAWs on Windows and see how UI and workflows have evolved. There is great deal to learn from it. Unlike most of the Linux world, proprietary software is under severe competitive pressure. That means that bad work, difficult to use GUIs and useless features generally do not survive. 3. "They way typical Windows SW works is not dictated by user interest. It is determined entirely by the short-term views of marketeers." Oh really. Can you back this up with actual evidence? Most commercial companies are extremely user-centric. Especially DAWs. They are geared towards musicians needs and most of these companies are religiously dedicated to their users. Are you saying Ableton Live is driven by short-term view of marketeers? Can you prove that? Can you explain why Ableton hired a whole number of actual performing musicians to help them test their software? Or that they have a room-full of people testing their software *everyday*? Can you show evidence that Image Line does not care about user feedback and have some short-term marketing views? Have you ever seen how these companies interact with the user and what level of feedback and actual feedback-based development is going on there? Have you ever actually used their software in studio and on stage? Honestly, I think this is a statement that you will not be able to back up. It is simply not true. 4. "If it were no user would ever have any reason to abandon Windows and go for Linux." This statement assumes that the only reason people move to Linux is because they do not like non-Linux software. Which is a highly questionable statement. Among all my friends not one cites that reason as the chief one. In fact, many people miss the great proprietary software they had and wish something like that would emerge in the FLOSS scene. No, a great many people move to Linux for ideological reasons and in some areas for security and financial reasons. But I am yet to meet a person who has a wide range of interests and who has moved to Linux because he does not like non-Linux software. Most of it is clearly superior and such a move is possible in singular cases of extremely niche products that do indeed exist only on Linux, usually of very technical nature. It would be interesting to make a more or less scientific study of that. Perhaps some exist? But surely, the initial statement is doubtful and requires more than just someone's word for it. 5. "Every time the Linux community adopts some stupid Windows 'standard' for the sole reason that it is 'what users expect', this goes against its own long term interests. If Linux ever becomes the perfect Windows clone then it has destroyed its main reason to exist, which is to be different and better." I guess I am not aware Linux community has any long term interests. Last time I checked, Linux community is a diverse group of people with very different interests. Not to mention that your version of long term interests (to be different and better) is highly ambiguous, difficult to formalize and open to all sorts of interpretations. And, of course, I would like to know what kind of "stupid Windows standards" we are talking about. A number of user-centric features that Linux Audio packages often lack do not seem stupid to me. Is the ability of a delay plugin to automatically get the hosts tempo - a stupid Windows standard? If so, I would prefer more stupid Windows standards to be adopted in the Linux Audio community, because they are sure very smart to me, the actual user of the software. Who wants to use it to compose music, you know. Not configure it to death. 6. "Regarding shortcuts for close/quit etc.: they are not always wanted." Well, the important thing here, then, is to not demand the user surrenders to what a single "wise" developer thinks, but take time and effort to actually research when various shortcuts and other things ARE wanted. And not by a couple of fellow developers, but actual musicians, actual end users. A given shortcut might not be desirable always, but it can be desirable in 97% of important cases, which might be a good reason to justify it. What I see constantly in the Linux Audio community is immaturity on a grand scale about UI and workflow design. Weak competition and often small user-base shapes many Linux Audio tools into difficult to use software. Weird, rarely needed features are put in the center under the slogan of "enforcing the user with more options", making it impossible to do simple jobs efficiently. The inability to just make a simple track is defended by criticism towards "pop music". Clear bugs and lack of convenience are explained away by technical and architectural ramblings. This is very sad, very irrational and leads to exactly the closeness of the Linux Audio community that I am seeing throughout the years. I would welcome an honest understanding of the real problems that Linux Audio community faces. This is useful even if we are not able to solve them this very moment. I can understand that UI design is a big-big job that costs a lot of money to research and develop. This is a tough challenge. But what I do not understand is that blazing conquest of dismissing the real state of things with anti-user propaganda. Get real. Linux Audio is interesting and has potential. But currently it is not the pioneering technology. And even if some of it is, most of it is too difficult to setup and use for anyone to actually notice it, in real life circumstances. Louigi. On Tue, Apr 21, 2015 at 11:26 PM, Fons Adriaensen &lt;fons(a)linuxaudio.org&gt; wrote: -- Louigi Verona http://www.louigiverona.ru/

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 &lt;paul(a)linuxaudiosystems.com&gt; wrote: -- Louigi Verona http://www.louigiverona.ru/

On Wed, Apr 22, 2015 at 06:34:25AM -0700, Len Ovens wrote: That's just bad design. Exactly. Also our vision is much better at perceiving angles than linear positions, in particular in situations where you have to verify something quickly. Something similar is true for real knobs. They provide support for your hand while you're using them. Try controlling a linear fader on a portable recorder while you're running. All the 'rotary' controls on my apps work that way. And you can also adjust them with the mouse wheel. Finer steps with Shift pressed. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Thu, Apr 23, 2015 at 12:50:06PM +0300, Vytautas Jancauskas wrote: I used to have that in nekobee but at some point (possibly not in a released version, possibly only in Gtk3) I switched to vertical movement. I really ought to dust that off. Maybe I'll make time next weekend, this weekend is a full of shite goth music and Landrover offroad contests :-D -- Gordonjcp MM0YEQ

On 23.04.2015 11:50, Vytautas Jancauskas wrote: Properly done radial knobs do not force you to move the pointer in a little circle, but allow you to increase the distance. This way, you get adjustable precision. In my own experience, this can work very well for parameters that have a huge range (i.e. _many_ steps) and control something sensitive to the smallest changes. 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. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

On 4/23/2015 2:10 PM, Hermann Meyer 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.

On 23.04.2015 21:55, Len Ovens wrote: Yes. If the linear knob happens to be too close to a corner of the screen, both part of the vertical and the horizontal range may be out of screen, though. Changing direction forces you to spend attention instead of relying on autonomous movement, trained by repetition. 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 and allow the finger to be repositioned. I think in many cases, horizontal sliders with labels and numerical values inside the slider area, are the better approach. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

On Fri, Apr 24, 2015 at 2:26 PM, Len Ovens &lt;len(a)ovenwerks.net&gt; wrote: +1. Jumps in output value should be avoided but interaction should occur immidiatly on movement - this is the only choice that satisfies those criteria. -- http://www.openavproductions.com

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 order would matter. (it shouldn't) I do not know how long it would take to "learn" this so it was natural to use. -- Len Ovens www.ovenwerks.net

On April 24, 2015 10:18:57 PM Tim E. Real wrote: 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 'mouse hiding' technique, it doesn't really matter if we use crossing borders or centre-screen mouse. As long as it returns to where it was when clicked (6:). Hmm, realizing now that hidden cross-border might actually be simpler and better than my hidden centre-screen thing: My centre-screen technique is in fact limited to half-screen height maximum movement ie. DOES have screen borders that could be hit. With hidden cross-border we roll for a full screen after another after another... T.

On Fri, 24 Apr 2015 22:18:57 -0400, Tim E. Real wrote: 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. Repositioning it, far a way from the area were we are working isn't good. There's no need to see a moving mouse cursor, since the fader/knob is moving. 2 Cents, Ralf

On 25.04.2015 09:50, Will Godfrey wrote: 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 a few messages. A drawback is of course the distance between the line and whatever the pointer is hovering. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

On Sat, 25 Apr 2015 08:50:21 +0100, Will Godfrey wrote: Tooltips showing the value instead of a description of the option IMO are good.

On Sat, 25 Apr 2015 11:01:54 +0100, Will Godfrey wrote: Assumed you have several sound presets for the same synth and you like to sync attack times without playing notes and comparing those sounds, it's nice to at least have a tooltip showing the value. IOW it can help to at least get coarse results very quickly, fine tuning is another thing. When mixing with Qtractor I like that I can use the keyboard to type coarse fader values, before I start doing the fine tuning using the mouse and keyboard.

On Sat, Apr 25, 2015 at 11:01:54AM +0100, Will Godfrey wrote: Musicians and sound engineers will have a different view on that. When I'm mixing, I *want* to know the values of e.g. equaliser parameters, for two reasons. First to be sure I'm not doing anything insane. 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. It's somewhat strange that musicians expect a sound engineer to have this sort of competence and complain if he/she takes too much time to find the right settings, but don't want to learn any of it themselves. Not even the wannabe sound engineers among them. Some time ago I was editing a long radio documentary. At some point we had to fix a badly recorded interview, so I launched an EQ/filter. On seeing the UI (knobs only), the director (an OSX user) said 'oh god, that's Linux, no graphical display or spectrum analyser, how are we going to adjust that thing'. I ignored his remark, set the EQ to what I knew was needed, and only then activated it. The result was right on spot. At that point I just said 'real sound engineers don't need toys'. He refrained from making more silly remarks for the rest of the production. Probably remembered that he came to me because he wasn't able to get things right himself. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Saturday 25 April 2015 03:50:21 Will Godfrey wrote: +10 +100 And, whoever thought it was a good idea, gets 10 lashes for doing the 10 second time out when the thing is stting on the next damned button you need. Damit folks, if you have to have it, kill the SOB when the mouse moves the next pixel! Let us get on with our work. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>

On 23.04.2015 20:51, Ivica Ico Bukvic wrote: Support for modifiers is nice as long as its configurable. Don't forget the WMs, they may be configured to respond to modifiers and mouse actions, too. e.g. I move windows (they're all borderless) around with ALT+MOUSEMOVE and resize them with CNTRL+MOUSEMOVE. Events intercepted by the WM thus won't reach the knob...

Op 23-apr.-2015 00:14 schreef "Fons Adriaensen" &lt;fons(a)linuxaudio.org&gt;rg>: written by for We are not talking about someone that suddenly decided to make up there own set rules and then tried to fore it upon us We are talking about a group of people that conducted a study on a large group of random users, and based on that study they defined a set of guidelines for us to use ... or ignore #freedom :-) I mean the real

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 < gianfranco(a)portalmod.com.br&gt; wrote: -- Louigi Verona http://www.louigiverona.ru/

On Thu, Apr 23, 2015 at 07:47:50AM +0200, Thijs van severen 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 money. And the result is quite different. So whom do you think I should believe ? During my lunch break today I'be been reading a number of UI design guidelines. Of course there is some truth in them. It would be rather difficult not to find out the value of consistency, of reasonable color schemes and layout etc. But *all* of them, without exception, seem to assume that the user is some ignorant nitwit, without any prior knowledge about the application domain and too lazy to learn, let alone read a manual or $GOD help us, configure the software he is trying to use. Or not actually use but just play around with it a bit. That type of user may and actually does exist, and that may be where the money (or fame) is, but it is *not* the type of user I'm writing for or even remotely interested in. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Fri, Apr 24, 2015 at 01:14:08AM +0200, tom(a)trellis.ch wrote: Agreed, playing around to get to know your equipment or software is a good thing to do, certainly if later you have to use it in potentially stressy circumstances. Any professional will do that, and probably won't mind if things don't work immediately and he or she has to consult some documentation or configure something. But it's not that sort of playing around that I referred to. There is a class of users (non-users would be more correct) that will 'play around' with everything they can get their hands on without having any intention to really learn anything. Just for the fun of it, to kill some time and because it's free anyway. Since they have no real interest in whatever they are playing with, they will give up immediately when they don't get instant results or have to think for longer than a second. Those are also the ones that will complain about 'bad user eXperience'. As said before, I'm not interested in that type of user. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Fri, April 24, 2015 07:58, Thijs van severen wrote: these are two separate things.. knowing the audience certainly helps. ok, my target user only speaks spanish. well.. i don't speak. nothing gained. maybe a specialist needed?

On 23.04.2015 22:59, Fons Adriaensen wrote: Writing a letter sitting safely at a desk leads to slightly different requirements for a UI than piloting an airplane ... You do not seriously believe common aspects of mainstream desktop environments and core applications like the behavior of radio buttons, checkboxes, menus, dialogs and so on came to be without many rounds of research and refinement, do you? There may admittedly be a problem with cargo-cult guideline writing, copying without taking first principles into account. Plus the people now working at Microsoft, Apple or Gnome and KDE are at risk of forgetting some of the things the GUI pioneers already understood. Now in intensity and information load, applications like Blender or Ardour may come closer to a cockpit than a spreadsheet application does. But I guess the glass cockpits, just the screens, are not meant for direct manipulation, which surely influences the design. Centralized pure display combined with a shitload of buttons and doodads do not lend themselves as a model for a multi-purpose computer UI. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

On 24.04.2015 23:40, Fons Adriaensen wrote: Yes, a classic. It's the general problem that using any toggle-action successfully requires the user to be aware of the current state. That might sound like a non-issue seen in isolation, but if a user has to deal with lots of such states over a long period of time, mistakes will happen. At the very least frustrating double and triple triggering. The reason to use one toggle button over 2 action buttons is saving space. Likewise, one shortcut over 2 shortcuts. A DAW can get away with Play/Pause toggling, but less often changed states that affect other actions are more troublesome as toggle. I mean to recall that Rhino3D has buttons that will always enable / keep enabled something on left click and will always disable / keep disabled on right click. Regarding ambiguous icons on toggle buttons that might display either state or action: If you can't avoid them, didn't find icons that imply action or state, the last line of defense is convention. Always state or always action. The blind copying of Apple's sliding switches is one of the saddest things to happen in recent GUI design. 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 associated widgets. This slows the user down to avoid stress and gives his eyeballs a nice workout." We already know a solution since decades. Checkboxes with their identifying graphics on the left side. Taking touch into account should not mess up pointer-based use. If you can't make sure of that, maybe a hybrid is a bad idea? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/

On Sat, 25 Apr 2015, Thorsten Wilms wrote: Also make the colour theming such that the widget is effectively invisible in one of it's states. This more helpful when using the device in bright sunlight of course. -- Len Ovens www.ovenwerks.net

On Mon, 27 Apr 2015 02:31:06 +0200, tom(a)trellis.ch wrote: 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 automatically should add scroll bars if needed. Unfortunately several apps don't care about the users DE/WM settings without providing good themes on their own and unfortunately the Linux DEs are a PITA because each upgrade might break the theme and WMs are often not that easy to configure as DEs are. However, I never noticed an issue caused by an upgrade of openbox and JWM, but Xfce4 became a PITA. A completely no-go are all those apps that try to provide photo-realistic GUIs, that fake to be analog hardware. Apart from the bad taste of this kind of theme art, the bigger issues is, that this kind of theme art often make fonts and controls less good visible. It seems to be out of style to work in front of a monitor at daylight while wearing reading glasses.