User Testing

Selecting Students

• Users can dynamically select groups of students, by toggling the icon box on the far left for a particular student. Originally each box consisted of only the name of a student but from the feedback we got during the paper prototyping, we decided to add the student’s picture to make the interface easier to learn. We also used to have a button called "Class", that would select all the class. But from the feedback we got we decided to change it to a small selection box which selects/unselects the entire class.
• From our paper prototype testing we also learned  that users were having trouble understanding who they were communicating with, so we decided to add a context window to the left of the tabbed frame, displaying the pictures of the selected students.
• Hovering over a student’s profile picture in the context window, provides extra information about the student.
• After the heuristic evaluation we thought it was important to add a message icon beside a student’s name in the left menu when a teacher had a new message from that student’s parents.

Messages

• This page allows teachers to have different conversations with parents or groups of of parents.
• Originally, it wasn’t divided into conversations. When the user would select several students, all the messages related to those students would appear in the window. With those students selected, the user could send a message to those student's parents, which they would receive individually, without knowing who the other recipients were. This seemed to be very hard to learn, so we decided to divide messages into conversations.
• Now, when several students are selected all the conversations appear listed at the left of the messages window. The top conversation is that corresponding to the selected students.
• Hovering over a conversation provides extra information about the student.
• From the user testing, we learned that it is still hard to understand how the conversations are related to the selected students. To solve this we will add a title to the list of conversations, to clarify what they are. We have also decided that we will add the ability of labeling conversations so it is easier for teachers to remember what each group is (study group, team, etc). Finally, we are also going to edit the page so that when the user clicks on a notification, the new conversations (that triggered the notification), appear first in the list of conversations, and so the notification button disappears when the conversations are read (and not when the notification is button is pressed).

Calendar

• The calendar page allows teachers to post events. Originally, it was designed so that teachers would also post their availability. However, we learned from the paper prototype testing that users have their own calendar platforms for keeping track of their events and their availability. We therefore decided to limit this page to a page where teachers would post events they want parents to see (exams, excursions, meetings, etc )
• The user can create a new event for the selected students by clicking on a day. A popup form appears, where the user must specify an event title, and can determine a start date/time and end date/time. The user can also further details for the event such as reminder times and event details.
• By default, the date displayed in the date fields is the day the user clicked on. And the time fields are also populated if he created the event from the week or day view.
• A user can edit attributes of an event by simply clicking on it. The user can modify any field and then click ‘Save’ to make the changes. No matter what students are selected that moment, the event continues to have the same participants as before being edited. When the form displaying the event details is open, the user can click ‘Delete’ to delete the event. The event is deleted for all the participants.
• By putting his mouse over an event the user can see the pictures of the event attendees.
• There is a legend at the bottom of the page which explains what the color of an event represents. We decided to add this after the feedback we got from the heuristic evaluation. We designed it is so that you can hide it (experienced users who already know what the colors mean do not want to see the legend any more).
• Lastly, we still rarely experience an error where the calendar doesn’t load. Simply refreshing the page takes care of the problem.
  

Grades

• The grade page allows teachers to quickly see all of the grade entries, scores, and overall letter grades for each student. Although outside the scope of this project, this would ideally be imported from an external gradebook source.
• Users can send grade reports to the parents of the students selected by clicking on "New Grade Report".  This brings up a form where the user can specify the assignments he wishes to send, add comments to the report, and add SMS or email as additional means to submit the report.
• Users can see what letter grades correspond to what numeric scores by clicking on the help icon, providing information to supplement the numberic/letter meanings of grades.
• Users can edit the grade book in line by clicking on the score they want to change. This makes it more efficient than having to go to an external page to correct input grades and safer as the teacher can correct grades she entered wrong/changed.
• Originally the table colors, fonts, and font sizes were different, but after the feedback we got from the heuristics analysis we decided to use Bootstrap's table styling because of its simplicity and readability.
• Originally, sending grades did not allow for user customization and automatically send grades to the parents of whoever was selected. We designed the grade report form to be internally consistent with the calendar form, using a modal that allowed for a message to be included and treats each grade like a file attachment in email.
• After sending grade reports, the user is provided with a success message to indicate whether or not their message has been sent. This displays above the grade book table in a thin horizontal ribbon, which is similar to gmail.

Learnability & Efficiency

Minor

In our Messages tab, users are required to select a conversation before writing a new message. Although a grey banner with "Select a conversation to the left" is displayed to inform users of this requirement, during testing, two of our users tried to click inside the message text area box to begin writing their message before they realized they first had to choose a conversation. One user commented that this threw her off a bit, and she felt like this may derail some teachers attempting to get their tasks done very quickly.

Although we attempted to provide instructions by placing a simple grey banner inside the message content pane, this was not sufficient for the users we observed in testing. Rather than requiring users to select a conversation themselves, a solution would be to have the top conversation (which contains all of the users that are selected on the left contact menu) automatically selected would indicate to users that a conversation must be selected to send a message. Because selecting a conversation selection causes it to be highlighted, this would give the affordance to users that they have to highlight a different conversation to select it. A negative effect of this solution may be decreased safety in sending messages, since users do not have to intentionally pick their conversation.

Safety & Learnability

Major

Pressing enter in the text area for messages causes the message to be sent rather than creates a new line. While trying to complete a task, one user accidentally pasted the link she was instructed to send to the parents of several students and then pressed the enter key, which sent her message. She commented that she was trying to include some context with the link and the behavior of the enter key in our UI was not externally consistent with most other message UI's (e.g.: Gmail).

A solution to this problem would be to make the text area for messages more externally consistent by making the enter key create a new line rather than send the message. Although the original intention of making the enter key send the message automatically was to make messaging more efficient, we realized that some users who are familiar with other messaging UI's would also make these slips which decreases safety.

Learnability

Major

The new message icon that is displayed on a user's row in the contact selection menu gives the affordance that clicking on it will direct the user to that new message. Two of our users tried to click on the message icon itself within a different context (i.e.: calendar, grades) to see the message. They said it was confusing that the message icon immediately went away after clicking on the corresponding row but the conversation was not selected, leaving users bewildered about what happened to the message.

The obvious solution to this problem would be to cause the new message icon to automatically direct users to the message context (despite what context they are currently in) and select the corresponding conversation, which would display the new message that the icon corresponded to. This would prevent users from getting confused over whether or not they missed or lost a message, and it would also make reading new messages much simpler and safer.

Learnability

Minor

Conversations in the Message tab are displayed in groups according to the contacts that are included in that conversation. All conversations that a selected contact has been involved in (individually or in different groups) display in the conversation tab when that contact is selected. One user commented that displaying all of these conversations at once is being confusing. When more than a couple users are selected, the label of a conversation says the first couple of student names, then "+ X more" (with X being the additional number of selected students). All conversations also contain the icons of all the students selected. We received feedback that these icons are too small to identify who is in the conversation, and names would be less helpful than subject lines or some other label.

One solution would be to allow users to include a subject for each new conversation that is created. This would be helpful for more efficient idenfication of which group of students displayed in the conversation pane corresponds to which task. However, one negative aspect of this solution would be to cause additional clutter in the conversations pane by allowing for multiple subjects for the same group of contacts, which would remove a limit from how many conversations would belong to the same group or individual contact selected. A better solution might be to allow for group creation, giving users a way to give names to groups of students that a user needed to frequenty communicate about (e.g.: Greg, Steve, and Sarah belong to Reading Group A).

Efficiency

Minor

One user commented that she worked alongside other teachers in one classroom, as it was her job to work with a specific subset of students at once, and not all of them. Another user provided feedback that although she teaches an entire class, she often organizes lesson plans around different groupings of students according to their level and behavior. These users suggested that having a way to create and select groups of students under labels or titles would be more efficient than having to select all of the users in a group every time they need to be contacted, which could introduce more errors (e.g.: including the wrong student, leaving a student out).

As mentioned in the previous solution, a way to solve this problem would be to allow for group creation, giving users a way to give names to groups of students that a user needed to frequenty communicate about (e.g.: Greg, Steve, and Sarah belong to Reading Group A).

Learnability

Major

All of our users commented that the way conversations are displayed, labeled, and scaled (height of a conversation's box) was not intuitive and was hard to figure out. Conversations are sorted by people, which users commented was useful after we explained it to them, but all of them said they were expected it to sort by recency, which would be externally consistent with other messaging UI's.

To make the way messages are sorted more externally consistent, we could simply order the conversations (beneath the dynamic one that displays all currently selected users at the top) in descending order by the most recent message that was sent/received. This would not remove the diplay of conversations by people involved, but it would order them in a way that was more relevant and intuitive.