[LAD] User eXperience in Linux Audio (rambling)

Len Ovens len at ovenwerks.net
Sun Apr 19 16:04:14 UTC 2015


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



More information about the Linux-audio-dev mailing list