Opinions Needed

[bfarrell]

We need to gather a general consensus from users about a certain feature and how it will end up. Right now, if you are in channel A, and two people in channel B are talking, you _cannot_ see their light to indicate they are talking. We need to know whether you want this to stay as is, or if users in channel A should be able to see if users in channel B are talking.

Reasons why/why not are appreciated :)

[Skuggi]

Is there an a way to make it an option?

One reason to keep it that way, is so people can be talking in private and it can stay that way. Also nobody thinks your talking about them.

A reason to change it would be, with the way the a lot of people use ventrilo they'll just hop into a lobby to see if anyone is online, not afk and actually doing something.

[Knaledge]

Short Answer
I like it; I'd use it. It offers at-a-glance functionality that saves me time in determining which channel is active and which one to join/not join based on specific user activity ("radio" channel, anyone?)

Long Answer
For feature comparison sake - I'd certainly one-up Ventrilo here and make this a client-side (or at least a server-side) option.

For practicality sake - I don't think it needs to be an option (reduced time to implement). How much longer until release (not considering build release)? Personally, I do not consider this a high priority issue, though a feature nonetheless. I'd certainly embrace this product if delivered sooner as opposed to delaying for feature.

Also, there's nothing wrong with "adding value" to your product over time. Consider competition reaction in the market if your uber product releases with everything everyone else doesn't do - and then they turn around and implement it. You're now dealing with high user-base (=high familiarity) products that 1:1 your own. Now it's down to cost. Solution? VALUE-ADD!

Add value to your product over time by implementing deliverable features "That Just Work". Food for thought...

And let's not forget scope: time-line of product delivery vs. ROI in opposition of this feature. If the scope warrants the time available to implement, perhaps you should go for it. If you're delivery+ (out X days post deadline), perhaps consider committing this to the "wish list" bin, develop "Agile", deliver the product, and start drafting a P&L (for ROI sake). Paint the bigger picture.

Making that call
Functionality & Impact Breakdowns (FIBs) help flesh out the "full story" when determining scope vs. delivery - all in direct relation to "Why implement this?"

So... why does the average Joe want this feature?

Let's take a look:

User joins

Common intent?

To communicate with others


Feature: User voice xmit indicator (global)

At a glance, user may see:

Who is talking
Which channel is least/most active
Specific member is talking/not talking


Feature Impact?

User moves

User joins (or does not join) channel based on visual feedback relative to active/inactive status of users




I find this feature useful based on the "Functionality & Impact Breakdown" (FIB) above. I'm one person, so it's up to the rest to chime in and help you build metrics.

[Turbo123]

I DO want it!

Reason Why:

I like to joined peoples channel when there talking/Yell at them about random things then LEAVE! :P

Real Reason:

I enjoy knowing who is talking and who is AFK, Basically what "Knaledge" said.

[DougK94]

It does not make any difference to me, I can see valid points for and against it. I will go with whatever is decided.