I would like to see a lite version, geared more toward the enterprises wanting a minimal, but good-looking, IM client. Some people need all the features, but for most of my users I wish I could remove the icons and menu options for VoIP, downloads, broadcasts, etc. They just need chat, that's it. A smaller memory footprint on the 'full' client, the ability to deploy via Group Policies without needing a script to put the properties files in the right place (%USERPROFILE%/spark). I'm sure I'll come up with more later.

That's fine. Perhaps then, since I bet many users are using active directory, an ADM template for managing Spark settings via group policies. Ultimately I am just looking for tighter control over what the IM users can do. Thanks for soliciting suggestions.

Yeah, I like that.

Wow winsrev, why don't you just paint a target on your face.    Kidding.

One thought I had regarding the button bar that Todd mentions is, maybe instead of two horizontal rows, embrace the concept of the "more" or "sliding" design.  In other words.... 

More Style:

This is what you see in Windows XP in the "shortcut" area and the doc area.  When there are more icons than can fit, a little "show more" option shows up and it pops up the rest of them for you to interact with.

Slider Style:

Left and right arrows, you click right to "slide" to the right to see more buttons.

Personally I don't like the idea of cluttering vertically with two horizontal bars.  And really, any of those rows can just get wider and wider the more extra stuff is installed.  It would be better to "cut it off at the pass" so to speak.  Note that I attemped to work out the slider design and never had time to get anywhere with it.

BTW, one of the biggest things -I'd- like to see is a better chat transcript handler.  I rely on my chat transcripts and Spark pisses them away easily.  Right now, if I shut down Spark I lose all of the active transcripts.  I have to close each tab individually first to actually save each transcript.

In my ideal world, the entire thing ought to be redone from the ground up.  Adium's style is good and I think is a good model to go with.  Basically you have a transcript "task" of sorts that's sitting there writing transcript entries to disk.  Incoming messages are sent to this transcript manager/task/whatever you want to call it and it queues up messages that need to be saved, in a different thread, and is capable of throttling and such.  If you save immediately after every message in the same thread as what's displaying the messages, you will start seeing some slowdown as file systems are accessed and such.  Just gets in the way.  =)  This is another thing I was working out in my head and never had time to get anywhere with.

laugh  Could I do it?  Probably.  Do I have time to?  No way.  =)