|
Requests such as the ones below are increasing in frequency - sometimes several in one day. If it is not possible to implement notification at this time, perhaps the attachment process should be rethought. I think a lot of the confusion stems from the fact that a student making an attachment ends up at a screen that has a Finish button - there is no indication that this button only completes the attachment process rather than ending the submission process. Perhaps change the button to read "Finish Attachment"?
---------------------------------------------------------------- Entered on 10/05/2006 at 19:07:55 (Ticket 62263) I am currently teaching OMS502 class. Several students learnt that their submissions were not correctly uploaded into the CTOOLS. The assignments were take-home quiz and we need to post their grades as soon as possible as we already announced the grades for other students. Instead of asking them to contact CTOOLS individually, I decide to ask the CTOOLS to recover their files and send them to me directly. The names of students and their login IDs are as follows ----------- Entered on 10/05/2006 at 18:43:42 (Ticket 62262) I do not see quiz submissions for the quiz that closed this past Monday (Quiz Module II) from the following students, yet based on past experience I'll bet all tried to upload their quizzes. Can you find these files for me? ---------- Entered on 10/05/2006 at 17:38:12 (Ticket 62258) My students had to submit an assignment by Thursday, 04 Oct. 2006, 4 pm. Two students assert that they have done so, but CTools malfunctioned, yet it was invisible to them. The respective uniquenames are - [removed] - [removed] The latest release of the sakai code fixes this issue by renaming the button in the file picker to continue rather than finish.
Kristol, I've re-opend this because while changing the name of the button hopefully helps, it still doesn't address the request for a confirmation email, which is what this issue is really asking for.
Right, I should actually read the issue next time. :)
I would vote for an option to do each, one checkbox for sending email to student and one checkbox for sending email to instructor. In a big class like Global Change, I don't want 168 emails for each lab the students turn in :) In smaller classes, however, there's always the use case of trying to get feedback to a student as quickly as possible, so being pro-actively notified that someone has submitted something so that I can start work on it right away would be nice.
Actually, from Brad's message, it looks like he would prefer that the student automatically receives an email once the system receives their submission and really mentions nothing about the instructor receiving notification. The point of this request is really to ease the student's mind. We do something similar to this in Samigo by giving the student a confirmation screen with a unique confirmation number. That way, if the instructor doesn't receive the assignment, at least the student has verification that the assignment was received by the system. This would require no UI changes to an already busy interface. If you would like, I can verify this assumption with Brad.
I second Peter's vote. If at all possible, giving the flexibility for either one or both is ideal.
Kristol, brings up a good point. For the students I'm not sure I can envision a reasonable scenario where it shouldn't be checked. I would suggest that the student email "receipt" of submission be a system-wide property, and that it be enabled by default.
On the instructor notification side I can see it going both ways, but I'd guesstimate unchecked as the more common preference and use that as the default. This feature, however, is getting away from the original request, so maybe you should just stick with the student email for now, and we can create another one for Instructor notification emails. Peter, are you suggesting that the setting would be a student preference rather than a per-site tool setting? Just want to be clear.
I was thinking along the lines of sakai.properties here.
Its too late to get this in as a feature for 2.3.0, as freeze has come and gone. So I'll post this out the the Assessment Tools DG to poll them on what they think the right granularity and default setting is for student-email-receipts on submitted assignments, and you can take it from there. How does that sound?
For the email to students confirming their submission, I don't think it should be an option for the instructor to turn on or off. From the student's standpoint, they want to know if it was actually submitted or not. If the instructor failed to turn that option on, or turned if off if the defautl was on, then we are back to students not knowing for sure that their submission was turned in. This seems like an automatic function that is just part of the system. Students will get used to the email and after receifving one, will know that if they didn't get one, their submission wasn't made for some reason.
If there was an option to email the instructor (or owner, or all instructors, including assistants?) then that should probably be off by default, and they have to opt in. I suppose there should be a permission to control who receives those emails so that they can go to whichever roles, since there is often more than one instructor type in the class. Setting the option for student notification in the hands of the student makes the most sense as they are the "customer" of this notification. This is also consistent with the message notification preferences. If they don't care to get these emails, then they can turn it off for themselves, rather than the instructor needing to balance the potentially conflicting preferences of their students.
If we take as one of the goals of the notification email to be to provide the students with an "official" receipt that their assessment has been received, then I think we can interpret both the instructor and student as customers. Allowing either one to disable the noticiation email to the student opens things up for more contention; it becomes less clear why a student didn't get an email, did they not submit, did they forget to check a box, did the instructor forget to check a box, did the student just save a draft and not sumbit it? Whereas, a system-wide setting builds an expectation that an email will always be sent, wanted or not, leaving less room for mis-understanding. If a student doesn't get the email, then they can start wondering nearly immediately what's wrong and work on correcting it.
Agreed, neither the student nor the instructor should have the option of disabling this confirmation message. If you really want to build in a choice somewhere, the only level I believe would be beneficial is to give the system administrator the option of enabling or disabling the notification for the entire system through sakai.properties.
Zhen, I can write up a spec for this if you can give me a couple of days so that all of the information about how this should work is there for all to see. This requirement really hasn't been fully thought out, it was just some quick thoughts put together to get this in front of the community for voting. Now that it seems we have decided to work on this, it makes sense to have a spec to agree to. A couple things to consider:
This will be setting the stage for other high stakes submissions - for example, we might want such a confirmation email when an instructor submits final grades to the registrar (if/when that functionality is developed). An alert page that pops up, or is at least very prominant, after the attachment is made in the Assignment tool would go a long way to preventing the problems the email confirmaiton is trying to address. After the student attaches something, an alert would appear notifying them to remember to submit to actually send their work in. Something they have to ok to get by so that they are sure to read it. That alert wouldn't necessarily obviate the need for the confirmation email - that is still useful as submission proof in case of a system problem. The confirmation email still though is after the fact, and without the alert, there will still be those who don't know they haven't submitted. Once they get a confirmation email successfully, they'll learn to expcet it, but until they do, they don't know, and so it's not much different than the learning curve now - once they have a problem and learn to submit then they know. The sent date of the email needs to accurately reflect the submission time, regardless of how long it takes for the email to arrive in the student's inbox. I agree with a system wide sakai.properties function to enable/disable the email confirmation for the entire system. Probably defaulted to on though. Thanks John for pointing out the adding attachment != submission issue. The big thing we're coming across is that students will go to a separate screen to add an attachment. To exit this screen to get back to the main submission screen, they click "Finish". This language is problematic, as it implies completion of the submission. All of the faculty that have reported this issue said that their students figured this out amongst themselves in the classroom after the fact, but it seems widely misunderstood.
I agree that the addition of the alert would go a long way to helping with the issue this ticket is trying to address. I would also suggest changing the "Finish" label on the attachment screen to "Done" as it seems (at least to me) to imply that the user is Done adding attachments, rather than having finished submitting the assigment. I realize this slightly changes the scope with regard to the name of the ticket, but it seems like the overarching issue is better user notification both via the notification system and the user-interface. Can we expand this issue to address both, or should the suggested UI changes be a separate ticket? I'd also like to suggest that the spec include the ability to disable this per site, as some instructors may not want this on for their particular site.
Mike (and all), let's keep this issue focused on the email notification issue. They UI change for an alert pop-up or the like should be a separate issue. The attachment confusion is not the only reason to send an notification email, keep in mind REQ-28 here too; the notion that a student should expect to receive an official "reciept" via email that their assignment has been processed.
I'm -1 on "the spec include the ability to disable this per site". I think leaving students to wonder if their instructor in one course enabled it, but another didn't, as to why they didn't get their receipt for a particular item would lead to too much concern and confusion for the students. I think this is an item for which uniform student expectation and experience should win out over instructor personalization.
I also vote for consistent server-wide behaviour. There should be some confirmation ID that's provided on submission both on the UI and in the email. This should be verifiable in some way, e.g. match up with the db entries and the event posted.
On the subject of the attachment button, I think 'Continue' might be better than either 'Done' or 'Finish'. A mock-up intended for 2.2., perhaps part of the solution to the problem for 2.3
A mock-up intended for 2.2., perhaps part of the solution to the problem for 2.3
From my email to the assessment group.
I understand the nature of this feature request ( The interface for uploading a file as an attachment is simply too cumbersome. Even if students are rewarded with an email receipt for doing it correctly, they will continue to do it incorrectly. Even after failing to get a receipt (Gee, wasn't I supposed to get some kind of email notification if I did it right? Oh well, maybe I deleted it.), the same students will struggle to properly upload the attachment the second time around. What students need is the field to upload a file right *on the same page* as the field where they type their inline response... as if we were asking them to upload a resource with a description. The assignment attachment process needs to be completely de-coupled from the attachment widget. The fact is that students will almost never need to attach a resource from the resource area (or from the resource area of some other site). And they will almost never need to point to an outside URL since the text editor now lets them create inline links. Just give them a straightforward way to attach a file. I'm not just making this up. Our usability specialist did some important work on this, although she has since left Sakai. She conducted interviews, led users through paper mockups, presented to the larger design group. I've attached a slide from a presentation called "Refractored Design in 2.2": [I attached the screenshot to the issue]] The current implementation is clearly marked as Workaround.jpg in her work. 2.2 was really about getting it out the door, but it feels like maybe we have some breathing room with 2.3. I don't think this slide is perfect, it doesn't account for the option to Save instead of Submit, but I think this approach deserves another look. I agree that high-risk transactions deserve receipts, but no receipt is going to improve the UI of this transaction, and adding three more steps (check for receipt, didn't get receipt, return to Assignments to figure out how to do it right, check for receipt again,...) onto the end of the workflow isn't going to make it more efficient nor reduce frustration. It might reduce support calls, but not significantly. Here's a URL to her archive of documents about assignment attachments: https://ctools.umich.edu/access/content/group/CTNG-Support/Michelle_s%20Archive/CTools%20%26%20Sakai/Design/Attachments/ Diana - I certainly agree with your (and Michelle's :) assessment, that the interface for uploading an attachment is cumbersome and that has most likely led to the creation of this feature request. (Note: At IU, we have changed the text for the button in the file picker to Continue rather than Finish in an attempt to alleviate some of these problems.) With that said, I don't believe IU is requesting this functionality to resolve the problem with the file picker. The idea of receiving a confirmation is to give students a peace of mind to know that whether there are file picker problems or not, their assignment was submitted successfully to the system and they now have a receipt to prove this. We use the confirmation process at IU with our test and survey tool and I have to say that it has eased the mind of many a student and an instructor when for some reason the student received a confirmation, but the test is nowhere to be found. This peace of mind is really what we're going for with this functionality and not necessarily a band-aid for the problems with the file picker. I hope this information is helpful and I do support the revamping of the file picker. If there isn't an issue open on this already, we should open one and see if we can get Jim to work on this! Please let me know if you have any questions.
I agree with the general direction of what I am reading here.
Email notification should be a 'user' preference by each assignment. It is not something that the instructor or sys admin should set or control, but rather something that the user selects. I would like to see the feature implemented in a way that it allows the user to make a choice for email notification, selectively, when creating or submitting an assignment. I seriously doubt that instructors will want all the traffic from email notifications, but it could be an option for them, as well. I don't know what you have in mind, but here is a possible design that gives users control: ** For instructors, there could be a checkbox when creating or revising an assignment: "Notify me via email when students submit assignments successfully." They should be able to get rid of the check (under 'revise' assignment) if annoyed after they get spammed with a bunch of messages in a large class. Once they see that all is coming in, they may want to simply turn this off. ** For students, there could be a checkbox right above the submit button with something along the lines, "Notify me via email when assignment is submitted successfully." As I reflect on this, I realize that instructors and support staff will probably get lots of new type of traffic from this feature -- and that is from students claiming that they check the box but they didn't receive an email notification. This could be due to an invalid email address in their Account, over quota account, spam filtering, etc. This can be an issue with a large size production.... Verified using Sakai (tags/sakai_2-4-0_QA_007) - Server qa1-uk & Server qa1-us
However, I will note that qa1-us gives you the following text when you submit: "You will receive an email confirmation containing this information." qa1-uk does not have this text implemented - checked on nightly.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Major
Assignments: Email notification once submitted assignment accepted by system
The problem stems from students uploading their attachment and then thinking that they have finished their assignment. But, they have forgotten to click the SUBMIT button, so their work is lost and the isntructor cannot view their submission.
Notification of a successfully submitted assignment would let students and instructors know that the submission was successfully completed (and will also let instructors know that there's something new for them to grade).
This is a REALLY important request for many users -- is there a developer who would be willing to work on this for 2.3?