unity-design team mailing list archive

[Martín Soto <donsoto@xxxxxxxxx>]

2010/5/5 Alex Lourie <djay.il@xxxxxxxxx>

>
>   I'd suggest, again, to begin with the "problem" cases, not solutions. For
> example, when is the intervention needed to control volume?
>

Sure, this is the purpose of writing use cases. I was just acknowledging
that ReplayGain and, in general, fully automated solutions are not excluded
from the solution space, even if the writing of the use cases seems to
suggest that they are.


>
> 1. I'm listening to a great rock music (meaning pretty loud), and VOIP call
> comes in. So, do I want to pause music, or make it more quiet relative to
> the volume of the voice chat (and maybe system will do that automatically
> when I answer the call).
>

I think this is covered by Gerhardt's case, isn't it? Your question about
what to do in this case is of course valid, but answering it takes us
immediately into the solution realm.


>
> 2. I'm in a voice chat session. Do I want to hear other system sounds or
> not? Do I want to hear them louder than the call or more quiet?
>

This would be covered for the most part by Javier's case, I guess. There are
probably situations, however, when a conversation is too important to be
interrupted by any notification sounds. A use case to the effect may be
valuable indeed.


>
> So I suggest to describe flows that require an intervention. If it is
> complicated to handle a flow then great, you have found a "problem"
> definition.
>

I'd say that uses cases should describe the whole palette of user
tasks/activities we want to support. If they are easy to support, better for
us, but having them all covered is important to make sure that the design is
complete.

Martín