2010/5/5 Alex Lourie
<djay.il@gmail.com>
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.