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 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
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
