[LAD] Experience driven design and Linux Audio

[tom at trellis.ch]

On Wed, October 1, 2014 17:40, Patrick Shirkey wrote:

> Usability usually requires a designers eye. Most good UX designers spend
> almost all their time on design/usability issues.

That might be true but UX isn't restricted to visual aspects IMO.

Looking at a button to indicate two statuses, is it a pure (visual) design
question how large the button is, where it is placed, how it is labeled
and how it looks? I think there is a layer between the pure design aspects
and the pure functional aspects where the line is blurred. For the button
to indicate two statuses, it's inherent that the distinction of the two
statuses must work. This is clearly a functional aspect of the (visual)
representation, in terms of operating the widget. If the button is too
small or placed where it won't be found it's also a functional aspect. The
pure visual design aspects come into play *when the above functional
aspects of operation driven by visuals are met*. The visual aspects on top
of that can be to match a common style ("we use rounded corners for our
buttons") *without breaking* the functional aspects (i.e. changing the
colors in a way that affects the distinction of statuses). This is also
where the individual preferences start whereas independently of that,
everyone needs to find, read, hit the button and distinguish its statuses.

  ___dev focus
 / __ux/design focus
/ /
| |---What is shown to the user, "make use of" the offered functionality
| |   --Wording, style/theme, "hidden-factor" of function
| |   --Documentation
| |
| |---The functionality embedded to the ecosystem of the program
| |   --Accessibility, grouping ("..is in the same category as")
| |
| |---The abstract functionality
| |   --Fits/amends the core idea, plays well with existing
|  \
|
| ---The concrete implementation
|   --Algorithm 1 faster than 2
|   --Library x
|   --Already existing (just another parametric call)
|
: ---The distribution
:   --Needs special attention to build on y
:
: ---Other aspects
:   --Legal, license etc ("can we use lib z?")
 \

(this is a free-form layering, change/comment it if you like)

Please note the the dev has/should have the full picture and shares the
top layers with a ux/design person.

I make an example using that layer stack.

Request: provide a way to add a new track in a multitrack app via keyboard
shortcut (no more actions/data entry needed)

Check legitimacy of request: is it something new or already existing, how
does it differ, does it fit to the core ideas, does it bring additional
value, does it break existing concepts etc.

Possible outcome: feature exists but it's not done in the most simple way
(clicking through menus and dialogues needed)
Possible arguments against: it can already be done. We can't know how many
channels the user wants in the track thus we can't make a shortcut without
data entry.
Possible facit: In 98% of cases, the users want's to either add a mono or
a stereo track. We provide the shortcut just for these two cases.

Layers bottom up:
--Other aspects: no change
--Distribution: no change
--Concrete implementation: already existing (just another parametric call)
--Abstract functionality: all conditions met
--Functionality embedded to the ecosystem of program: group with existing
track ops
--What is shown to the user: some minor work here (mainly: documentation)

In this case, the UX can be improved for users, without the UI changing
except for a menu entry showing the action and keyboard shortcut. All the
involved steps can be done "just" by developers.

Now one could do that again with the next request: "add a button to add a
track immediately" :) where UI/UX person will play a greater role.

Regards
Tom