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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Apr 19 20:15:01 2015