"Email student" link for instructors

[boonebgorges]

Here's the original request from the document:

Add a quick response button or checkbox for faculty next to the submit button communicating the idea: “This student has not asked a full question/provided enough info. Send them auto response email “lorem ipsum lorem ipsum.” Andrew suggests also considering simultaneously flagging the question for removal (as this auto-response suggests that the student question is unlikely to be answered in its current form).

I suggested an email link instead, which is easier to implement and gives the instructor lots of flexibility.

Could I get confirmation that we like this idea, and perhaps a quick mockup?

[drdrew42]

What would be the purpose of the email link? You're just suggesting that the notification part is easier to implement than the rest of it - so perhaps that is where we start?

Essentially we have the situation where:

1. A student is stuck on a WeBWorK problem.
2. The student clicks over to OL-WW.
3. The student fails to communicate their issue (say, something like "help me" and no further detail)
4. This question remains 'unanswered' because there isn't a real question.

We want to construct a function that minimizes instructor effort in accomplishing:

1. Notifying the student that their question did not provide sufficient detail to receive an answer (and perhaps include a link to a "how to ask OL-WW questions" page)
2. Preventing the offending question from being seen as "unanswered" (flag for removal? outright removal?) It was suggested that the student may return to the question in order to provide more detail (after they'd been notified), at which point, it would be useful if their original question hadn't disappeared.

[boonebgorges]

Thanks for chiming in, @drdrew42. Here's my thinking. The original request from the OpenLab team was along the lines of what you've described here. It is technically very easy for me to add a button for instructors that, when clicked, will send an email to the author of the question with hardcoded text along the lines of "Your question at [url] does not contain enough information ... etc ... Sincerely, [instructor name]". But the comment here https://docs.google.com/document/d/14BPjgQTSHyqbB9dG-BFwrr5tO-W1mnvCOsaOFAauPis/edit?disco=AAAACwNWQfA suggests that a hardcoded message may not be flexible enough, and that instead we should have default boilerplate text, which should then be editable by the instructor before sending. My concern was that adding a new interface for editing this boilerplate introduces a large amount of UI overhead - where does this interface go? how is it triggered? etc - to introduce what is, essentially, an email with some default text. Based on this, I suggested that it'd be far easier from a technical and design perspective to trigger the email client, and to let the instructor type whatever message they'd like (we may be able to pre-fill a limited amount of text), a solution that also provides maximum flexibility for instructors who want to email students for any reason, including "incomplete questions" or whatever.

Your idea about a "flag for removal" etc feature is interesting, but wasn't part of the requests sent to me by the OpenLab team a couple months ago. I'm afraid that it'd require a fair bit of technical and design work, and in order to fit it in scope we'd have to bump some other stuff. We can do this if it's high priority. cc @jennaspevack @bree-z

[jennaspevack]

Maybe something like this that is only visible to faculty. This would trigger the email client as Boone describes.

However, I'm not sure it solves the "unanswered" issue. Even though we've removed "unanswered" as a state, it might be weird to show that the question now has 1 reply.

[jennaspevack]

Here's another idea: Maybe when the incomplete box is checked, some default text is added to the reply box "This question needs additional information. The question author has been notified via email."

When the reply is submitted, the student is notified by email and the default text is added to the thread as a reply. This would then give the question "1 reply" and leave it up to the student to edit it to receive further help.

The default text in the email could be something like: "Your WeBWorK OpenLab question [link] did not provide sufficient detail to receive an answer. Please review the Ask Questions page [link:https://openlab.citytech.cuny.edu/ol-webwork/help/ask-questions/] and edit your question to receive additional help."

@drdrew42 any thoughts?

[boonebgorges]

Just to chime in:

• The checkbox text in the most recent mockup says "The student will be notified...". But - unless they've explicitly unsubscribed - users are already subscribed to notifications of activity on their own questions. So all this checkbox really does is to add the placeholder text.
• Making the notice public feels wrong to me - I can imagine students being uncomfortable or embarrassed.

[jennaspevack]

Thanks, Boone!

• Yep, just an easy way to add a default reply that that minimizes instructor effort. Maybe we could remove the bit about the author being notified by email. The aim of the additional email was to provide guidance/links to Help. However, we could add that into the default reply to simplify the process and to provide guidance to other students who might be in the same boat.

• I don't think a default reply asking for more information would be that different from a faculty member posting a reply with the same request. And also seems less harsh than being flagged for removal. :)

• If the reply is hidden and the heading says "1 reply" that seems a bit confusing. Some of the student feedback was about concerns that questions were going unanswered, when in fact some questions were not fully stated (ie: "help me"). Since we've removed the Answered and In-Progress states and gone with replies instead, not sure how to proceed.

I'll keep thinking. As @drdrew42 stated above, the goal here is to provide an easy way for faculty to respond so users know that questions are being reviewed while letting the author know they need to better state their question.

[drdrew42]

Jenna is correct. We don't need to worry about sending an email if the action is to post a pre-formulated response.

In order to avoid stigma and promote the growth in awareness of what constitutes a "well-formulated question", the pre-formulated response could include:

• This question does not contain enough detail for a useful response to be provided.
• Please see URL for guidance on how to better phrase your question so that we can help you better.

[boonebgorges]

If we're just providing canned responses, perhaps a checkbox is not the best UI. For one thing, it implies a toggle - the ability to turn the canned response both on and off. But if you edit the suggested text, it won't be possible to remove it from the box (and anyway, if it's editable, that's what the Delete key is for). Maybe a button or link of some sort would be better?

My impression that we're merely providing suggested text, which can then be edited, comes from Jenna's earlier mockup. @drdrew42's comment above suggests that we "post a pre-formulated response", which could mean that we don't allow it to be editable. IMHO, it's still best in this case to keep the Submit button as the sole way to submit a "response" (even a canned one), but that we fill the text box and then gray it out.

[jennaspevack]

I think in this last incarnation, the text would not be editable. I italicized it in the mockup, but grayed out seems fine (#595757 passes contrast checker). Here's another version.

So just to clarify, if a student's question is incomplete, the faculty member can choose to use the non-editable, canned reply. It would not be checked by default, but they can toggle the canned reply on/off. @boonebgorges If we went instead with a button or link, where do you imagine it residing?

Here's a slightly tweaked version of @drdrew42 's suggestion with the link: "This question does not contain enough detail for a useful response to be provided. Please review the Ask Questions page for guidance on how to phrase your question so that we may help you.

[boonebgorges]

Thanks, Jenna. If the content is non-editable, I think the checkbox interface is fine.

Here's a friendly-amendment: When the checkbox is checked, the 'Add Images' and 'Preview' buttons are hidden, and the editor is forced into 'Preview' mode, with the suggested content filled in. Then it's not necessary to gray anything out, since Preview mode is non editable.

[jennaspevack]

Perfect!

[boonebgorges]

Thanks, @jennaspevack.

I've built this, but it feels funny to me. See gif above. Does this capture what others have in mind?

[bree-z]

This is working as expected -- as shown in the gif above. The functionality seems OK to me.

@jennaspevack do you want to take a look? If it seems OK to you we can close this.

Thanks!

[drdrew42]

I like the fact that this requires two interactions - decreasing the odds of an accidental use.

[jennaspevack]

Functionality seems great.

These can wait until a future release or I can open another ticket, but if they're quick....

Can we adjust the line-height of the preview text to 1.4rem and the font size to 1rem to match the .ww-response-content?

And also adjust the .incomplete-toggle label { / font-style: italic; / font-size: 0.9rem; line-height: 1.4rem; }

Sort of unrelated question: did the text in the response box (.response-form textarea) get smaller at some point? It's really tiny. Is it possible to adjust the font size?

.response-form textarea { font-size: 1rem; }

[boonebgorges]

I've changed the styling as suggested by Jenna.

[jennaspevack]

Preview text and response box look good!

I'm not sure if you changed the .incomplete-toggle label or the .anonymous-toggle label. Looks like maybe the latter by accident? It's a small thing, so fine to just keep both as they were. :):)

[boonebgorges]

Hm, yes, I must have changed the wrong label. I've implemented your .incomplete-toggle styles - can you confirm?

[jennaspevack]

Great! Thanks!