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

Tue Nov 20 09:51:42 PST 2012

Hi Kely,
wow, thanks for your complete and extensive answer!

Thanks to it we found out about MSGCNTR-738 which seems like a great 
improvement to us, we actually discussed it some time ago since our 
replaced homegrown eLearning environment had also a synoptic tool which 
only showed sites with new activity (messages, forums, announcements...).

We have the messages tool in production in over 4000 sites and we've 
seen some wrong and common "use cases" from our users. Maybe some of 
them can be helpful to you in order to make a decision.

Our main problem comes from the implementation of the course management 
that we've done since most of the sites we have are divided in sections 
and we try to have every section working independently in the site. Of 
course, we couldn't achieve total independence between sections because 
some tools are note section aware and therefore we ran into some 
problems also with the messages tool.

[Most of this issues could be seen as LOCAL to our institution - we also 
include some suggestions made by our users]
i.e.: - when someone (instructor or student) want to send something to 
their whole group, they send it to "All Participants" not being aware 
that there are more sections included under "All Participants"
        - when a student from section A wants to communicate with his 
Instructor, sometimes the message is sent to the "Instructor Role" not 
being aware that all Instructors (from all sections of the site) are 
getting the message. In these cases, instructors complain because they 
get messages from students not associated with his section.
        - sometimes, students use have sent several messages to All 
Participants that have been considered as Spam by their instructors.
        - First time users in sakai don't feel well notified by the 
messages tool since they are not receiving anything to their email 
unless the sender marks "Send a copy of this message to recipients' 
email address(es)".
        - The "To" box is small - we usually have (name, middle name and 
two last names) + user email
        - When users replies to a message, the message should be marked 
somehow in UI - for example with an Icon.
        - Some users also suggested to show the profile picture of the 
message's Author.
        - If users of a site have configured the Messages tool to 
forward their messages "Email address for forwarding" to their personal 
email address, when a message is sent to them, all participants with 
that option configured, receive the same email with all "personal email 
addresses" visibles in the TO field.

There are Jiras opened for some of them. Also, some improvements have 
been made for MSGCNTR 3.0 so upgrading to 2.9.0 will help to prevent 
some those use cases.

Regarding to your summary:
a). I would say that in most cases the tool is not used for spamming but 
when you have so many sites, and so many people, in some cases there 
should be a way for preventing it or for banning it.
b). Forwarding can be important for first time users (freshman and new 
instructors maybe) but when you get used to Sakai, we think that most 
people prefer to set their preferences so that they decide if they get 
email notifications or not.
c). it should be up to users to decide.
d). Yup, we find that most instructors ask for tools that allow them to 
send notifications to students. Maybe, because that used to be the way 
our homegrown system used to work... If they create an exam, they want 
the exams tool to notify all users, if the add an event to the calendar, 
they ask also for notification...

Hope it helps!
Thanks again for your answer,
mariano

El 16/11/2012 22:15, Keli Sato Amann escribió:
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20121120/425079d0/attachment.html 