Re: [LAD] User eXperience in Linux Audio continued
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 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 is a limitation, the desk/mouse pad could be very, very small. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 by the Linux desktop PC apps I'm using. Reminds me of consumer hifi gear were sometimes inputs are outputs and outputs are inputs. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 make a note of them, but if I can save the settings anyway, even that is moot. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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. Similar situation with 'slider switches' which show 'on' or 'off' on the flat part. If you have no other feedback, the state of the button or slider gives you a very ambiguous hint at best. 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/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 order would matter. (it shouldn't) I do not know how long it would take to learn this so it was natural to use. Hi Len, it conflicts with gestures, if you by accident don't touch the control and you do the two finger pinch, something unpleasant could happen. IMO 1 touch the control, it gets a colour that signals that it's activated 2 put a finger some distance away 3 move towards control to decrease value or farther away to increase value 4 touch the control again, to deactivate it, colour becomes normal Regards, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 user has them off (and out of the way) but on using an obscure feature can briefly re-enable them. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 way: http://folk.uio.no/ksvalast/radiummouse.webm (that's a 60fps video. Firefox doesn't seem to display 60fps videos correctly. Chrome does though) :-) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 out by my synth attack sync example: it can help to at least get coarse results very quickly This is much more true for good EQs. Sometimes I need to search a culprit using a narrow bandwidth [1] using a parametric's EQ Q and checking different frequencies, but at least a coarse mix can be done without listening. [1] Allow me to misuse this word ;). http://www.sengpielaudio.com/calculator-bandwidth.htm It's not needed to know such things, if you get a feeling for it by practise. Regarding the toy GUIs that show a graph. I'm not against graphs, but they aren't (always) useful and I don't had them over several decades when using analog mixing consoles. Regards, Ralf PS: IMO tablet PCs should be excluded from a discussion about Linux audio, that usually doesn't run on tablet PCs. Touch screens have other pitfalls. http://www.xewton.com/musicstudio/forum/viewtopic.php?f=3t=2524 JFTR I'm Unknown Crewman. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 enable/disable them from every part of your application, so that an experienced user has them off (and out of the way) but on using an obscure feature can briefly re-enable them. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 applications) I think it is the available ways of doing things on the android because even applications made by a company that also does a pc version, the android version is not as good. 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 lots get this right) The next best (best that can be done on android it seems) is that the value will not move untill you pass the current value. The third best the value will not move unless the mouse or finger first touches at the current value. Fourth best is having the value jump to where you first put the mouse or finger. The worst one looks like second best... That is putting the mouse on the slider has no effect untill getting to the current value... but because the slider control looks like a real fader knob, the value first jumps in the oposite direction the mouse/finger is moving as soon as the mouse/finger touches the graphic of the fader knob rather than waiting till the finger is at the middle of the fader knob. This one is useless. While horizontal faders can use less space (Ardour plugins use this) it becomes less stage usable real quick. In the end, for stage a hardware controller seems the best. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux 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 out all the stuff that doesn't. And finding that out in a non-playing around session isn't fun, so better play beforehand :) 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 for example, but lots get this right) +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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 it leaves the application window. 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. Hey guys. For anyone wrestling with control design and the mouse pointer being too close to the screen edge, there *IS* an attractive technique you might not be aware of or forgot. If you use a trackball, it is heaven! Er... but if it's a touch pad, as mentioned ye may be lifting yer finger. It involves hiding the mouse pointer and forcing it to do tricks. 1: Upon receiving a mousePress event, immediately *hide* the mouse pointer. 2: Now force the invisible mouse to the *centre* of the screen (to give the mouse pointer plenty of 'headroom' before it would ever reach an edge). 3: Now upon reception of a mouseMove event, do something useful with the increment given by subtracting the new position from the centre-screen position. (Add the given increment to some object's position or value, edit-box value etc.) 4: Now immediately *force* the mouse pointer back to the centre of the screen. 5: Repeat 3: and 4: until mouseRelease event is received. 6: Now turn the mouse pointer back on. Done. This technique can be used for example with: Linear-movement knobs and dials, and both vertical and horizontal sliders. Canvases (2D and 3D!). Edit boxes. I've used this technique since the mid-90's on Windows, and now Linux. It was harder to do in Windows than Linux. I know a Windows 3D app of the type Thorsten mentioned. I remember when that edge-crossing thing was added. I shook my head, laughed out loud to my friend who paid money for that and was showing me the new version. So goofy that was, it seemed to me, so I made this instead and added it to my own 3D apps! I call it Continuous borderless mouse movement and my control class names are like RollEdit RollCanvas etc. because you can roll, roll, roll, without ever lifting the mouse button and re-positioning the mouse. Coupled with mouse acceleration and accelerator modifiers, you can roll a floating point edit box value with fine resolution, or with a few more rolls plus acceleration, be into the thousands. Great for example for 3D Z-axis zooming in/out quickly, continuously. See examples in MusE, the continuous Pan and Zoom. If I recall correctly, see also LMMS, and the audio editor Sweep. I have yet to try, but believe the technique is good when you are forced to deal with short sliders because you are not forced to map one value-change per mouse-pixel movement, nor accept a mouse pointer that goes way out of positional sync with the actual slider thumb rectangle just to get good resolution/range stuffed into the short slider. We discussed this in MusE recently, about our mixer, and I said if we want short horizontal sliders stuffed into a thin vertical mixer strip, then it will be really crucial that we get these sliders right. So I believed that this technique was really a (the only?) practical way to do it. Hide the mouse. What do you think? About *circular* motion knobs and dials: The awesome thing about them is, as someone mentioned, if you need more resolution you simply move out to a higher radius. But I've always believed the 'hidden borderless continuous mouse' technique cannot be used here. Because the user needs to know that they are drawing an arc, and what radius they are at. Whether that is done by showing the mouse, or hiding the mouse but showing say a 'radius line', if you are near the screen edge you are stuck. Maybe linear-motion knobs really are best used with this technique. So I just realized now that the above mentioned border *crossing* technique may help with these circular-motion knobs. Let the mouse cross the border. Not a big problem for the user, they are mostly focused on the actual knob and its value. They can move to (almost) any radius, and sure it's a little awkward near screen edges (like Asteroids - never did well on that one). But hey what else can you do... Now, a bit far-fetched but, what about showing a sort of temporary 'proxy' circular-motion
Re: [LAD] User eXperience in Linux Audio
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 and allow the finger to be repositioned. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 '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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 money. And the result is quite different. So whom do you think I should believe ? 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/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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? No, but I know very few apps that use them correctly, despite all the guidelines. Even the simplest things often go wrong. 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 ? Similar situation with 'slider switches' which show 'on' or 'off' on the flat part. If you have no other feedback, the state of the button or slider gives you a very ambiguous hint at best. To remain in the flight deck context, imagine such a widget being used to control your landing gear... Checkboxes are another common problem, they all look the same. There's no hint at all if they control something essential or some irrelevant detail. Returning to audio, how many apps do you know where the rotary or linear controls will assure you at a glance, without having to read text, that they are set to approximately the value you expect ? Even in audio you often have to preset things before they become active, in other words before you have any feedback apart from the widgets themselves. 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. Not only at risk... 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. Yes, the screens are display only, but the actual controls are designed in the same way. There's a lot of subliminal hinting everywhere. For example on the FCU (the 'autopilot') you have rotary controls to set your target airspead, heading and altitude. They are the same size and color, but they all feel differently. Just by touching one of them you know if you have the right one, without looking or thinking. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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? 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. I've made my first knobs with circular response, and was very pleased with the behave, like Thorsten points out, distance to the center is the key therefor. jump-to-mouse is a no-go therefor, but that's thru for any (audio) controller. However, most users complain about circular response, so we've changed it to linear behave. Today, I mostly use the scroll-wheal to change values, . . ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 some argument for it I am not aware of? 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 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. 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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... but having a good adjustment rate in the first place is important for stage use when using two hands may not be possible. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 continue watching the position of the mouse when it leaves the application window. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 one end to the other if I make the wrong move are not easier to move on stage... That's just bad design. I never understood that. 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? Even if it's a bad argument? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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 needs to decide THE TARGET AUDIENCE of such product. I see myself dealing with this issue daily when working with the MOD and I imagine that any other product, be it gratis or paid, free or non-free, hardware or software, is no different in this issue. I personally believe that there is no such thing as the perfect globally accepted set of features but only the ones that are accepted by a particular group of users and thus the need to define the target audience before deciding on the features. That said, I think that eveyone is right in their arguments and the lack of concordance comes from the fact that each one is considering a different target audience. Computer users (and Linux users also for that matter) can be spread over an extensive spectrum that stretches from the 80 column monocolor terminal lover to the keyoard hater and will surely disagree on whats is a good and what is a bad designed software in terms of user experience - the thing actually working or not is a totally different matter. Best wishes to everyone. Gianfranco Ceccolini The MOD Team 2015-04-23 7:47 GMT+02:00 Thijs van severen thijsvanseve...@gmail.com: 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 etc) for a variety of reasons. It wasn't written by a software developer, but a musician. He was bemoaning how limited GUIs for audio software were because of their attempt to present things that look like hardware controls. There are different grades of that of course. Chickenheads, screws, handles and ventilation holes in a plugin GUI just look silly IMHO. But an 'abstracted' version of a rotary control can make sense, it has some advantages over most alternatives. On the other extreme, I find the 'standard' widgets offered by most GUI toolkits completely useless on anything that is supposed to be 'technical' (including audio apps) rather than an office application. 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 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 thing - Boeing or Airbus, not the Garmin etc. thingies used by sports pilots that look like (and probabaly are) Windows apps. This is a very complex environment. A large amount of information, often competing for attention, has to be displayed accurately and unambiguously, in a way that is comfortable to be viewed for hours on end, and that also remains functional in emergency situations that may require split-second decisions. A lot of research and effort has gone into designing these things. You won't find a single 'standard' widget on those displays. Nor skeuomorphic imitations of traditional flight instruments. The only thing that still looks a bit traditional would be the attitude indicator on the PFD, but even that will be a very abstract version of the old mechanical one. All of it is designed to be purely functional, no frills, no eye- candy. Even the MCDUs (the things on the central console that look like a calculator on steroids) have their own interface style and conventions that will be quite different from what you may expect. And that's not because this is a primitive, conservative, or 'ten years behind the state of the art' technology - these systems are among the most advanced you can find anywhere. The same, but probably less extreme, you'll find in almost all 'technical' environments where function is more important than looks or tradition. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org
Re: [LAD] User eXperience in Linux Audio
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 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 stage... That's just bad design. I never understood that. 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? Even if it's a bad argument? 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 needs to decide THE TARGET AUDIENCE of such product. I see myself dealing with this issue daily when working with the MOD and I imagine that any other product, be it gratis or paid, free or non-free, hardware or software, is no different in this issue. I personally believe that there is no such thing as the perfect globally accepted set of features but only the ones that are accepted by a particular group of users and thus the need to define the target audience before deciding on the features. That said, I think that eveyone is right in their arguments and the lack of concordance comes from the fact that each one is considering a different target audience. Computer users (and Linux users also for that matter) can be spread over an extensive spectrum that stretches from the 80 column monocolor terminal lover to the keyoard hater and will surely disagree on whats is a good and what is a bad designed software in terms of user experience - the thing actually working or not is a totally different matter. Best wishes to everyone. Gianfranco Ceccolini The MOD Team 2015-04-23 7:47 GMT+02:00 Thijs van severen thijsvanseve...@gmail.com: 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 etc) for a variety of reasons. It wasn't written by a software developer, but a musician. He was bemoaning how limited GUIs for audio software were because of their attempt to present things that look like hardware controls. There are different grades of that of course. Chickenheads, screws, handles and ventilation holes in a plugin GUI just look silly IMHO. But an 'abstracted' version of a rotary control can make sense, it has some advantages over most alternatives. On the other extreme, I find the 'standard' widgets offered by most GUI toolkits completely useless on anything that is supposed to be 'technical' (including audio apps) rather than an office application. 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 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 thing - Boeing or Airbus, not the Garmin etc. thingies used by sports pilots that look like (and probabaly are) Windows apps. This is a very complex environment. A large amount of information, often competing for attention, has to be displayed accurately and unambiguously, in a way that is comfortable to be viewed for hours on end, and that also remains functional in emergency situations that may require split-second decisions. A lot of research and effort has gone into designing these things. You won't find a single 'standard' widget on those displays. Nor skeuomorphic imitations of traditional flight instruments. The only thing that still looks a bit traditional would be the attitude indicator on the PFD, but even that will be a very abstract version of the old mechanical one. All of it is designed to be purely functional, no frills, no eye- candy. Even the MCDUs (the things on the central console that look like a calculator on steroids) have their own interface style and conventions that will be quite different from what you may expect. And that's not because this is a primitive, conservative, or 'ten years behind the state of the art' technology - these systems are among the most advanced you can find anywhere. The same, but probably less extreme, you'll find in almost all 'technical' environments where function is more important than looks or tradition. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___
Re: [LAD] User eXperience in Linux Audio
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 audience is possible and beneficial, sure. Once you allow a small number of distinct audiences, you get a little farther. For some generic and/or complex products, things get messy fast. Just think of possible audiences for Blender: game developers, hobby vertex pushers, 3d printed bunny enthusiasts, product designers, professional illustrators and 3d animation specialists (coffee logisticians, modelers, texture artists, rigging and animation artists ...) ... Even though you can expect conflicts and issues due to the sheer number of features, Blender can work for all of them. Note however, than some people think its unnecessarily strange and complicated, while others think it's basically sliced bread for 3D. Oustide of marketing, I think it's not that important if you can assume your typical user to be Granny Smith, Tom Broman or little Susie. Truly important are the tasks to be accomplished, the work environments and the frequency and duration of use. Guess how the last 2 points relate to the different impressions people have of Blender. Aside of all that, every single user being human has limited memory, a locus of attention easily pulled away by an important message ... or just a distraction, is better at recognizing than recalling, forms habits, is slowed down when having to consider options, ... and so on. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 gives me snip feedback if the program is not working correctly snip debug it Yes - both very good points. The latter (crashing on open) is particularly important, because if no splash exists, users expect the app is broken. Fons wrote: Using a splash screen to fix that is at best a bandaid Agreed, it is not the ideal situation, but it is much improved over no indication of feedback. Although a power-user probably won't care much for a splash screen, to novice users it does provide visibility of system status, #1 from Nielsens UX heuristics. Paul Davis wrote: (about the GUI Lock feature) - nice touch, and certainly something to be concidered for any live use software - noted as important. No synth or DAW should bomb out on Ctrl^Q during recording / playback, perhaps even with a confirm dialog when RE Dial Interaction: @Vytautas Jančauskas - For on stage use, I concider anything except slider style interaction with dials completely useless. I propose to any project using radial interaction style widgets to switch to slider style interaction. If moving 4px can cause a value jump by 50%, it is not safe to interact with that dial during a performance. Gain knobs are common offenders here - particuarly in Distortion / FX plugins. Slider style interaction has no disadvantage in the on-stage usecase, hence any OpenAV software (and AVTK) have the slider style interaction. Thorsten RE Blender UI: Its very complex yes - its also pretty cool in the features it provides. Hotkeys to hide and show parts of the UI are a nice touch for power users, and a lot of work and thinking has been put into the UI. I'm a fan - but I'm a long term Blender user, so I can't objectively comment on how UX freindly it is for novices.. Re Radial Dials: Is there a disadvantage to slider style interaction here? Set a middle rate of change, and allow the user to use various hotkeys to increase / decrease it? This avoids the 4px 50% jump issue, which is IMO catastrophic for live-use. Cheers, -Harry -- http://www.openavproductions.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 costing tons of money. And the result is quite different. So whom do you think I should believe ? 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. Hi Fons, i mostly agree with your evaluation, especially good is the example of the purely functional cockpit. 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 out all the stuff that doesn't. And finding that out in a non-playing around session isn't fun, so better play beforehand :) Regards Thomas ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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, 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. 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, but a musician. He was bemoaning how limited GUIs for audio software were because of their attempt to present things that look like hardware controls. So mileage may vary here. There are users with very different workflows, ideas, needs and backgrounds, and some of them don't want knobs. They could of course be a tiny minority and developers might be better off ignoring them. But it isn't true that text fields = developer centric, knobs = user centric. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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, 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. Years ago, I had a sequencer program that had no knobs. It had only text fields. However, holding the mouse button down and moving the mouse up or down (maybe side to side as well) adjusted the value with no text input required. The mouse pointer may end up way off the value it was adjusting but that was fine. While it was possible to make knob pictures with the graphics lib at that time (Atari ST actually) the monitor resolution was low and the author was trying to put (probably too) many controls on the screen). 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 stage... A knob picture is fine, it shows the user this is a continuously variable control while using a lot less screen realestate than a slider would. A knob that looks like a knob but works like a slider is what is needed. Being able to change value by moving the knob (or trying to) up and down or left and right is much more usable than trying to move the mouse in tiny circles. I would suggest being able to adjust using both up/down and left/right so that controls can be close to screen edge and still work. As I said above, a text field can work the same way and give a more acurate value indication... though a knob position may be enough gives a quick visual relative idea that may be more useful. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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. 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, but a musician. He was bemoaning how limited GUIs for audio software were because of their attempt to present things that look like hardware controls. So mileage may vary here. There are users with very different workflows, ideas, needs and backgrounds, and some of them don't want knobs. They could of course be a tiny minority and developers might be better off ignoring them. But it isn't true that text fields = developer centric, knobs = user centric. -- Louigi Verona http://www.louigiverona.ru/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 stage... That's just bad design. A knob picture is fine, it shows the user this is a continuously variable control while using a lot less screen realestate than a slider would. 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. A knob that looks like a knob but works like a slider is what is needed. Being able to change value by moving the knob (or trying to) up and down or left and right is much more usable than trying to move the mouse in tiny circles. I would suggest being able to adjust using both up/down and left/right so that controls can be close to screen edge and still work. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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, but a musician. He was bemoaning how limited GUIs for audio software were because of their attempt to present things that look like hardware controls. There are different grades of that of course. Chickenheads, screws, handles and ventilation holes in a plugin GUI just look silly IMHO. But an 'abstracted' version of a rotary control can make sense, it has some advantages over most alternatives. On the other extreme, I find the 'standard' widgets offered by most GUI toolkits completely useless on anything that is supposed to be 'technical' (including audio apps) rather than an office application. People writing 'GUI standards' and trying to force them on everyone should have a look at e.g. a modern 'glass cockpit'. I mean the real thing - Boeing or Airbus, not the Garmin etc. thingies used by sports pilots that look like (and probabaly are) Windows apps. This is a very complex environment. A large amount of information, often competing for attention, has to be displayed accurately and unambiguously, in a way that is comfortable to be viewed for hours on end, and that also remains functional in emergency situations that may require split-second decisions. A lot of research and effort has gone into designing these things. You won't find a single 'standard' widget on those displays. Nor skeuomorphic imitations of traditional flight instruments. The only thing that still looks a bit traditional would be the attitude indicator on the PFD, but even that will be a very abstract version of the old mechanical one. All of it is designed to be purely functional, no frills, no eye- candy. Even the MCDUs (the things on the central console that look like a calculator on steroids) have their own interface style and conventions that will be quite different from what you may expect. And that's not because this is a primitive, conservative, or 'ten years behind the state of the art' technology - these systems are among the most advanced you can find anywhere. The same, but probably less extreme, you'll find in almost all 'technical' environments where function is more important than looks or tradition. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 etc) for a variety of reasons. It wasn't written by a software developer, but a musician. He was bemoaning how limited GUIs for audio software were because of their attempt to present things that look like hardware controls. There are different grades of that of course. Chickenheads, screws, handles and ventilation holes in a plugin GUI just look silly IMHO. But an 'abstracted' version of a rotary control can make sense, it has some advantages over most alternatives. On the other extreme, I find the 'standard' widgets offered by most GUI toolkits completely useless on anything that is supposed to be 'technical' (including audio apps) rather than an office application. 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 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 thing - Boeing or Airbus, not the Garmin etc. thingies used by sports pilots that look like (and probabaly are) Windows apps. This is a very complex environment. A large amount of information, often competing for attention, has to be displayed accurately and unambiguously, in a way that is comfortable to be viewed for hours on end, and that also remains functional in emergency situations that may require split-second decisions. A lot of research and effort has gone into designing these things. You won't find a single 'standard' widget on those displays. Nor skeuomorphic imitations of traditional flight instruments. The only thing that still looks a bit traditional would be the attitude indicator on the PFD, but even that will be a very abstract version of the old mechanical one. All of it is designed to be purely functional, no frills, no eye- candy. Even the MCDUs (the things on the central console that look like a calculator on steroids) have their own interface style and conventions that will be quite different from what you may expect. And that's not because this is a primitive, conservative, or 'ten years behind the state of the art' technology - these systems are among the most advanced you can find anywhere. The same, but probably less extreme, you'll find in almost all 'technical' environments where function is more important than looks or tradition. 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 loading progress meter in the status bar or similar?). This gives the user the opportunity to load a different preset or close the app/plugin again as quickly as possible. Speaking of: 2: Presets Going a step further than the usual preset selection drop-down boxes: having a dedicated preset browser can be very nice. This can be integrated into the main gui view or replace it on a button click or open in new non-model window (not ideal IMHO). The u-he plugins (e.g. TyrellN6) give a good example of this. https://youtu.be/1FQ_Hpyh7rs?t=109 Having such a browser gives the opportunity to attach and show meta info on the presets, such as author, description, tags etc. and use them to organize and find presets easier. Also, please make the presets switchable via a keyboard shortcut, via the plugin host and via MIDI program changes (the latter esp. if it is a standalone program)! Chris signature.asc Description: OpenPGP digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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
Re: [LAD] User eXperience in Linux Audio
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 i'm not going to implement one is (IMHO) a very very wrong attitude. The same goes for any other feature I still don't get why splash screens are a good thing. I don't want a big modal picture blotting out the middle quarter of the screen just because an app is waiting to start up. Maybe there are other things I'd like to do with the computer while I'm waiting. 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 :-) -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- follow me on my Audio Linux blog http://audio-and-linux.blogspot.com/ ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 :-) I,m not sure if these guidelines explicitly mention splash screens, but i'm pretty sure that getting feedback from the app about what it is doing is high on the list 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 attitude. The same goes for any other feature Keep it simple and dont use 'alt-b' for what the rest of the world knows as 'ctrl-c' because you think thats better. It's not Anyway, thumbs up for this effort ! Grtz Thijs Op 19-apr.-2015 00:40 schreef Harry van Haaren harryhaa...@gmail.com: 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 the user experience. 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. Ensure the splash is shown immediately, before lengthy operations such as scanning for files or loading content. 2: Presets Synths and Effect plugins often provide presets - show a preset selection in the main UI, or 1 click away. A fast way to browse presets greatly enhances UX when searching for a sound. Ideally support scroll-wheel interaction for changing presets. 3: Hotkeys - Ctrl Q, Quit - Ctrl W, Close Project - Ctrl S, Save - Ctrl Shift S, Save As - Escape, Context sensitive close I'm aware most of the recommendations above are obvious, and that many programs support these already. Cheers, -Harry -- http://www.openavproductions.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 attitude. The same goes for any other feature I still don't get why splash screens are a good thing. I don't want a big modal picture blotting out the middle quarter of the screen just because an app is waiting to start up. Maybe there are other things I'd like to do with the computer while I'm waiting. -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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. I would add that the splash should be fairly small, informative, and if possible carry occasional status messages. As soon as the main interface shows, the splash should disappear. Possibly, set it with a short-ish timer, so if it doesn't get updates from the application it disappears anyway, possibly after a short delay with a failure message. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 was launched ;). Depending on what some apps need to establish, before the next app can be launched, we sometimes need to add delay ... roxterm --tab -n ♪ foo -e foo --option=bar ; sleep 2 The app already might be running, just establishing some things might take a while after the splash screen already disappeared. It e.g. might take two seconds after loading _data_ (not the app) and the app likely displays information by the terminal emulation output or by a log message window. The script/terminal emulation approach might be out of fashion, anyway, an app still could display a splash screen, while the important part of the app already segfaulted. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 - 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. Hence the new Lock feature which disables all GUI interaction entirely (except for a click on the lock window to unlock, of course). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 unlock, of course). 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) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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. Ensure the splash is shown immediately, before lengthy operations such as scanning for files or loading content. to be honest, I personally do not like spash sreens. If you implement such a feature do not forget to give your user a preferences option to disable it: [ ] Do not show (this annoying) spash sreen [...] I'm aware most of the recommendations above are obvious, and that many programs support these already. I would like to add one more point: 4: Support internationalization Guido -- http://wie-im-flug.net/ http://www.lug-burghausen.org/ signature.asc Description: Digital signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio
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 the user experience. 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. Ensure the splash is shown immediately, before lengthy operations such as scanning for Just as long as it's not modal, or better yet make it optional. There's nothing worse than a big ugly graphic blotting out the middle of your screen preventing you from doing anything while you wait for some buggy slow piece of crap to load. Splash screens are a symptom, not a solution. -- Gordonjcp MM0YEQ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio (rambling)
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 directly to collaborate on a splash screen graphic if necessary. Ensure the splash is shown immediately, before lengthy operations such as scanning for Just as long as it's not modal, or better yet make it optional. There's nothing worse than a big ugly graphic blotting out the middle of your screen preventing you from doing anything while you wait for some buggy slow piece of crap to load. Splash screens are a symptom, not a solution. I think both have a point here. Users, especially Windows users are often quite strange creatures. They come from an environment where Software is notoriously slow, bloated and faulty, so for example they come with a few subconscious expectations and assumptions: Wheres my popcorn? ;) Nr 4 did actually happen to a fellow developer in the past, so what did he do? After all his effort to uncouple the UI from the background processing and optimizing the speed and responsiveness of the application, he silently shed some tears and put in progress bar that runs for a fixed time of maybe 1.5 Seconds.Now the user can be sure, that the program has actually received his command and acted (or at least acted as if it acted) according to the users command. Because seriously, saving must at least take one second because it is hard work, otherwise it is obviously broken ;) 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] User eXperience in Linux Audio (rambling)
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 consider supporting each item. It will improve the user experience. 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. Ensure the splash is shown immediately, before lengthy operations such as scanning for Just as long as it's not modal, or better yet make it optional. There's nothing worse than a big ugly graphic blotting out the middle of your screen preventing you from doing anything while you wait for some buggy slow piece of crap to load. Splash screens are a symptom, not a solution. I think both have a point here. Users, especially Windows users are often quite strange creatures. They come from an environment where Software is notoriously slow, bloated and faulty, so for example they come with a few subconscious expectations and assumptions: 1. I do not trust this thing in front of me, sometimes it works, most of the time it doesn't. I hate it, I don't want to use it and it is a PITA. 2. If I command my computer to do something, it must be complex and complicated, otherwise why would I have the computer do it anyway? If it was easy, I could do it myself! 3. Because computers do complex and difficult stuff, this stuff takes time and makes noise, (Freezing the gui for a few satisfying moments, loud rumbling of the hard drive, and and and, Sometimes displaying an ominous loading- or progress-bar). This kind of feedback is the resemblance of hard work, exactly the hard work I expect the computer to do for me (see 2.). While it does the hard work, I anxiously sit in front of it full of awe and expectations whether the hard work will show any usable result or just abort with a cryptic message some stupid programmer most certainly put in just for the purpose of annoying me. 4. If I click on a button and I can't notice any hard work, something must certainly be wrong because no work was done. So this save button must obviously be broken, so better press it again and again... oh wait, it is greyed out and deactivated, better call the developer and tell him, that the save button does not work... Nr 4 did actually happen to a fellow developer in the past, so what did he do? After all his effort to uncouple the UI from the background processing and optimizing the speed and responsiveness of the application, he silently shed some tears and put in progress bar that runs for a fixed time of maybe 1.5 Seconds.Now the user can be sure, that the program has actually received his command and acted (or at least acted as if it acted) according to the users command. Because seriously, saving must at least take one second because it is hard work, otherwise it is obviously broken ;) Someone nasty could say, that users want slow and buggy software, but I am not that cynical, I guess some feedback is enough to give the user a good feeling. There are other alternatives than classic splash screens. 1. locking the UI in a visible way 2. displaying a loading bar 3. Be creative, maybe play some hard-drive crackling sound via speakers? Splash screens have the advantage of empowering the developer to put marketing relevant stuff there, Donation Buttons, logos, version numbers... so it's probably not entirely about UX I guess. Just my 2€ -- Markus ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
