I know it has been a while since you created requirements SPARK-1595 and SPARK-1596 on my behalf. First of all: thank you for listening.
SPARK-1595 speaks for itself and thanks to Wolf for acting on it.
SPARK-1596 however, I think could perhaps benefit from reconsideration. You see - I had an idea that I believe could help create a rather clever solution to the problem. First let me reiterate the business issue in a very generic sense: some users might want some messages to be notified more prominently than others. I can think of *all kinds* of corporate contexts for that generic need. I appreciate, however, that in the IM world it must be difficult to agree on implementations that require code changes on both the sender's and receiver's device. Therefore I propose that this be handled *entirely* within the receiver's client (in my case Spark). Here is how it could work:
- The receiver has a standard notification configured as it currently works. This would be the non-urgent case. For example, ROAR might not be used for most messages.
- However, there is also a configuration setting to specify a string in the message that would trigger a different notification. For example, if the receiver sets this string to be #URGENT# then whenever this string is included in the message text by the sender (which is simply a corporate procedure, not anything built into their IM client per se) then the ROAR notification is triggered.
To me it seems elegant and hopefully not too difficult to implement. It seems easier and more useful to me than the current reading of SPARK-1596. With this approach I do get to have my cake and eat it: users can participate in non-intrusive conversations, but urgent notifications are available on an exception basis. It also does not rely on a distinction between group vs individual chat, and realistically urgent notification could be useful in both contexts.
That's my suggestion.
Regards
micro