Hello Ignite Community,
Okay, so, i’ve been fixing and adding some new features to Spark, but, what the Jira seems to lack the most is what features that the community are actually look for, so, today i pledge to you to share with us the features that you would like to see in the next spark (not 2.5.9 but 3.0.0 is Daniel wants to go to that for the next version)
Try and give a good description of the feautre too.
Thanks,
WinSrev
A smaller footprint would be real nice.
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.
mtstravel wrote:
A smaller footprint would be real nice.
Yeah, i believe that Daniel and one of his friends (sorry, don’t remember heir name) discovered a problem in the SIP plugin relating to memory usage.
jeffreyvsmith wrote:
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.
Well, maybe a “lite” version could be possible (not sure on the practicality of it though or the sort of functions that it would carry).
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.
Now this post made me remember some reall issues:
Preferences on OS X and Windows are stored in the wrong location. The root of a profile is not the proper location for preferences. OS X should be in the Library folder of the user at the very least. Windows should have it in the Application Data of the user profile.
Default download location should be outside of the spark preferences folder. Ideally it should be in a subfolder of the My Documents folder of windows or Documents folder of OS X (10.5 has a downloads folder). The best solution would be to cause a wizard to run the first time spark is launched to set the downloads location, and other custom settings.
Broadcasts should honor the server settings. If broadcasting is disabled users should not be able to do this. Currently they can.
Sepparate the Gateway Icon bar and the Function Icon bar (Downloads, Broadcast, etc) onto 2 different horozontal bars. When the roster window is made thinner the gateway icons are not available (see image, I have 5 gateways running).
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.
Thanks Daniel, if you can buy the paint, i’ll draw the target
Anywho, in terms of the new structure. 2.5.9 is gone, doesn’t exist anymore, it’s now infact going to be 2.6.0 (the current Jira issues list there is pretty locked unless a major issue comes up), so, any new issues and features should go into 2.6.1.
So, in terms of the idea of this seperate of slider idea for the Gateways is: http://www.igniterealtime.org/issues/browse/SPARK-998 (if you feel you can do this Daniel feel free to assign this to yourself).
Also, on another note, the broadcast issue has been move to 2.6.1 and is currently at: http://www.igniterealtime.org/issues/browse/SPARK-977
I will continue to look into the current issues
I like the slider idea as well. Better than my lame idea.
laugh Could I do it? Probably. Do I have time to? No way. =)
In terms of the transcript viewer, i’ve come up with this issue: http://www.igniterealtime.org/issues/browse/SPARK-999
It also links every issue that relates to transcripts and the fixing that may need to be done.
Currently, even after clearing the roster cache on the server, spark must log out and then log back in for roster group changes to appear. Would be nice if the client occasionally requested roster updates if any and applied without logging in and out.
Roster changes are delivered to spark but it takes a very long time. This does need to be improved.
Also like broadcasts spark does not care what settings you have on the server, it will allow file transfers.
Added the file transfer issue to the Jira: http://www.igniterealtime.org/issues/browse/SPARK-1000
(1000th Spark Jira Issue )
I would like to see a feature similiar to remote desktop or tight VNC built in to Spark. Not crummy either like streaming jpegs, but an actual Remote Desktop Client Server design. If you wanted to take it further you guys could create a remote desktop web portal that could view Spark client Computers from the actual OpenFire admin Console. Wow, this idea actually turns me on thinking about it!!!
that seems a good deal above what spark currently does. to get what you mentioned spark would need to install its own video driver. as an admin, I personally don’t need another app installing its own video driver. whats wrong with rdp, rdesktop (linux), and vnc? there are other commercial products also that already do this. I think spark should stick with being an IM client.
My biggest feature request, use less resources or use something besides java
Basically, i think it’s very unlikely that this feature would be added anytime soon and on that note, viewing people’s computer from the admin console is literally a big no, in my opinion, privacy comes first and that would be a big invasion of privacy.
jledhead: basically, using less resources is being looked into and something besides java is not an option for SparkJava although i do believe that David is intending to make a desktop version of SparkWeb in Adobe Air (or something along those lines).
Yes, tight VNC works really well, that is why I have it installed on over 300 computers, but from an IT standpoint less software to maintain is better. That being said, I enjoy the features of Spark, but it would be a very useful feature if an IM client could also act as a remoting tool to access clients in need of technical support, document viewing, application sharing, etc… I am sure that this is a bit too much for the ignite team right now, but perhaps something to think about for the future.
Allow choice of tabbed discussion windows or separate windows. If tabbed, have an option to drag one out to its own window.
Don’t steal the keyboard/mouse focus even if the ‘bring window to front’ is set.
Add a way to hook one chat window to a text-to-speech output.