Mike and Raphael have just had a quit chat session on our channel. Mike
has presented a very interesting and concise summary of the survey
results. Here's the excerpt for those that would have wished to follow.
If anyone is interested please mail me for the complete log
<moren> ok, I'll start out with a quick summary
<moren> For those that don't know the survey was conducted for 2 weeks and participants were recruited through SIP Communicator, Pidgin, and Miranda
<moren> Miranda participants were recruited via a forum post, SIP Communicator and Pidgin users were recruited via a post to the user mailing list and Open IM mailing lists respectively
<moren> It was an electronic survey conducted using SurveyMonkey and consisted of 28 questions
<moren> Raphael and I were trying to assess who the users were, how they use multi-protocol IM applications, the features that were most important to them, and try to find out their opinions about some possible future features
<moren> The results indicated some potential survey bias due to over 3/4 of respondents being male and the possibility of a more tech savvy audience than the general population (over 50% of respondents use Linux, general population is closer to 5%)
<moren> However, that may just be the population that multi-protocol messengers appeal to, and the Linux skewing may just be due to a correlation between use of open source messengers and use of open source operating systems. Further studies would need to be done to verify or disprove that there was sample bias.
<moren> With that disclaimer aside, the full report covers most of my recommendations and the results, but the most interesting ones (in my opinion) are the ones related to the future design and development of SIP Communicator
<moren> The survey indicated that most IM features are rarely used, so the design of the chat window can take this into account by not having toolbar icons for most features
<moren> the features that SHOULD have easy access are calling a contact, sending a file, group chat, and possible direct/private connections are the most important. For contacts not in the buddy list, adding a contact is critical as the majority of respondents indicated they add contacts weekly to monthly (more frequently than we had originally thought)
<raphman> what do you mean by "possible direct/private connections"
<moren> The vast majority of respondents indicated that they use IM much more frequently than voice chat so having the default double-click behavior resulting in opening an IM session seems to be the best way of handling things. However, some users skew much more toward voice so it would be a good idea to do a system wide and/or contact by contact preference for IM vs call
<moren> Jabber/XMPP allow for private connections and AIM allows for direct connections
<moren> this can also be viewed by some messengers as encrypted connections
<moren> it was a feature that was fairly popular but isn't consistent across all protocols
<moren> direct connection through AIM cuts out the server and the two messengers act as client and server
<moren> since not all protocols support it and they all view it slightly differently, I am not sure if it can be added to the toolbar, but I think it would be helpful to users if it could be in some way
<moren> for the additional features, I think it would be best to do two mock-ups (one where they are in the right-click contextual menu, and the other where they use a Kopete style message box menu) and run a traditional user study to see which method is easier for users to figure out how to access those features
<moren> and that might also lead to discoveries that some users want certain features to be slightly more accessible
<moren> It was also found that respondents for the most part indicated that they would be happy if SIP Communicator would do a fail-over to a different protocol when communicating with a meta-contact if one protocol does not support the feature they wish to use (or if the feature simply failed to work)
<moren> e.g. if they were in a voice chat and the connection dropped, they would be happy if it went to IM until the voice connection could be restored
<moren> one (of 22 users) indicated that would make them angry
<moren> However, fail-over to e-mail was not nearly as liked by users and it is recommended that if such a feature is implemented it would not be automatic--the user would have to enable the feature and confirm each e-mail before it gets sent as several respondents indicated e-mails being sent automatically would upset them and we do not want to alienate users.
<moren> that's basically the quick summary
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org