[Building Sakai] Messages Settings - Feature Request proposed back in 2010

[Keli Sato Amann]

Hi Jose
We haven't done any work on this, but I wanted to share our plans for Messages--it's still a pilot tool for us at Stanford but we evaluated changes between our current version (2.6 with a nice people/role/group picker from Berkeley) and 2.9 to decide if we would adopt it wholesale.

We decided to continue hiding Settings, as we did for 2.6, and let every message generate an email (users don't even get chance to elect to send or not send email when composing message). This was mostly for simplicity's sake, since the people who we've got piloting the Messages tool were users of the deprecated Mailtool. I was not even aware of the problems in Settings Jon Hayes points out with forwarding messages, but that adds to our reasoning. Users already have a campus-provided way to forward their email, so we didn't feel we needed that feature.

If the point of that setting is to prevent members from getting inundated with email, I was wondering if the rules for email generation could be more similar to Announcements and other notifications: the receiver gets to decide whether to get normal priority messages in email or just in the CLE, but the sender gets to choose to send some messages high priority, which always generates an email. While it's true that the sender should have the option to force email, I think the recipient deserves some say in the matter and I don't think the sender always wants to have to choose. I don't think this is a trivial matter and not everyone on my team agrees with me--they think our instructors think of Messages as a way to send email and that capability should not be a choice for anyone.

That being said, if allowed Message email to be optional on our campus and have users rely on the CLE for receipt of message, it needs to be very obvious to users that there is a new message waiting for them when they log in. While the current synoptic tool is decent, we made an improvement to the synoptic tool (MSGCNTR-738) when we rolled it out to the entire campus so users don't have to look through sites with no activity.

As for Jon's proposed Settings for who can send messages, I could be good, though it's probably not enough to get us to expose Settings. If Messages were in wider use and we couldn't keep up with requests to edit case-by-case in Realms, then we might expose it (though we'd hide forwarding, but we haven't had any request at all.
 
While we haven't had time to do in-depth user interviews, we did look at some stats for the 28 courses that are piloting Messages. Just by seeing how many messages were sent and received by one person in each role, we strongly suspect the following: 
• In over a third of sites, instructors were using Messages to send a message to all students, however most were doing this by sending it to only students, not everyone in the course; instructors themselves didn’t get it and when the course had guests, most often the guests didn’t get it. This specificity might be important to prevent spam in large classes with a lot of guests or admins. If this were possible in other tools like Announcements or Email Archive, perhaps that would also be appealing.
• In about a quarter of sites, instructors weren’t sending messages, but students and instructors were getting them, so either a Course Admin, teaching assistant, or a student we didn’t happen to sample were sending most messages. We suspect it was a course admin
• About a quarter of sites did not end up using Messages; either they requested, then never used it, or in the case of Law this quarter, they added it and used it once, but not extensively. These seemed to be very large classes. We'd like to follow up to find out what they did instead.
• Very few students seem to be using Messages to send a message, though we see evidence in a couple of classes that students are probably using the tool to communicate with each other. Students are also sending messages in a couple of other classes, but without sampling every student, it is hard to tell who they are sending it to. We are not sure why they would use Messages and not email, so this is not too surprising.

In summary, 
a) The ability to restrict who can send Messages might be good, but at least in our limited pilot, students don't seem to be using messages to spam their class, so hasn't been an issue yet. I'm guessing the only reason why students might want to contact other students is to share interesting but not pressing info or to ask a question or find work/study/project group members, all of which can take place in Forums with less spam. 
b) If we expose settings, we would probably remove forwarding, as it doesn't work as expected and is redundant if campuses already have forwarding.
c) is there is any interest in leaving it up to recipient how to receive normal priority messages, as with Announcements, rather than forcing sender to choose everytime? There may be use cases I'm ignoring that would make that a bad idea, and I'm sure this suggestion is not trivial.
d) Based on some of early user research showing that the the ability to target email might be why people use messages, I would imagine this ability would also be popular in Announcements and Email Archive.


Keli Amann
User Experience Specialist
Academic Computing Services, Stanford University
----- Original Message -----
From: "JOSE MARIANO LUJAN GONZALEZ" <jmariano at um.es>
To: "Sakai Developers" <sakai-dev at collab.sakaiproject.org>
Sent: Thursday, November 15, 2012 5:13:47 AM
Subject: [Building Sakai] Messages Settings - Feature Request proposed back	in 2010

Hi everyone!
First of all, Congrats to everyone involved in the 2.9.0 release!

Does anyone know if any work has been done around this 
https://confluence.sakaiproject.org/display/MFT/Messages+Settings+-+Feature+Request

It seems like a really interesting feature, maybe for 2.9.2 or 2.10?
Thanks!

-- 
******************************************
José Mariano Luján González - Aula Virtual
Area de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
UNIVERSIDAD DE MURCIA - http://www.um.es

_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"