Functional Specification (2.4)

Feature Overview

Fine-grained recipient selection

The key power, complexity, and usability pressure is found within the recipient selection area. The mailtool includes four different interfaces for recipient selection (for more information on other interfaces, see below under "Instructor preferences"), but the default OOTB interface is the one shown here, labeled "Users by Role" in the Options screen:

Beginning at the top of the "Compose" screen, the From: field will show the email address of the current user. Whether this becomes the "reply-to" address for any response is something controlled by the options screen (again, see "Instructor preferences" below).

The To: section of the interface is where recipient selection occurs through checkboxes, with selections applied to roles, groupings, individual recipients, or any combination thereof.

The recipient lists are first arranged by role, and the respective site participants for each role can be listed by clicking on the "Select <role name>" action link, which expands the list and changes to a "Collapse" action link for collapsing the list once again. Recipients are ordered alphabetically by surname (although unfortunately not so in the early screenshot shown here).

The mailtool will handle every role defined in the site in this way.

At the bottom of the To: section is a field for adding any optional email addresses, and it is labeled Other Recipient(s). These addresses will typically be for non-site participants.

Attachment handling

Email Archive integration

Instructor preferences

All roles which have the mailtool.admin permission will see an Options action link at the top of the Compose screen, which leads to this screen for setting the default behavior for the mailtool for the entire site. It is not necessary to change anything here in order to use the mailtool effectively, but "power users" may appreciate the extra options for tuning mailtool behavior.

The first and most significant choice to be made here is the interface for recipient selection. There are four choices available in the drop-down selector:

• Users (a simple listing of all users, sorted alphabetically) - most appropriate for project or other smaller site types where all participants are on the same footing.
• Users by Role (the default interface, displayed in all the screenshots on this page) - this is both the default and the "preferred" interface, from the perspective of design and development focus. It is the most flexible and powerful of the four.
• Side by Side - This provides two selection lists side by side, much like the widget for setting Section membership.
• Scrolling List - This provides a single scrolling list which allows rapid selection of sets of lines based on Ctrl-clicks and Shift-clicks, but it can be difficult for sites with large populations because of the large quantity of scrolling.

The second set of options has to do with how copies of the message are handled. The two possibilities represented here - "Send Copy to Self" and "Add to Email Archive" are also available on the Compose screen, but if they are set here they will become the defaults for the mailtool within this site.

The third set of options is for how replies are to be handled. The default behavior is for replies to be directed to the sender's address, but it is also here presented as an option for no replies to be allowed, in which case the reply-to address simply becomes 'no-reply@server.edu'.

The fourth set of options is concerned with the message composition pane, which can either use the editor specified in sakai.properties, or become a simple plain-text area.

Finally, it is possible to alter the display labels for the singular and plural versions of the roles, if that set of options has been enabled in sakai.properties. This can allow for instructors to attach their own names to the roles (at least for mailtool purposes), and to accommodate roles in the interface where the roles have unconventional singular/plural distinctions. Since this is something that could be effectively handled as an admin matter, and doing so would allow the stripping away of another set of potentially confusing options which have marginal use cases, we have left the enablement up to sakai.properties, and relegated their specification to a third screen, which is arrived at through the link at the lower left: Show rename roles menu.

Clicking on the "Update Defaults" button will store all these settings as the default behaviors for the mailtool for the entire site. Clicking on the "Cancel" button simply returns one to the Compose screen.

Group Awareness

Integrating group awareness into the fine-grained recipient selection has proved somewhat problematic, and so for the 2.4 release the following factors impinged upon the design, which we take to be an iteration suitable for further usability testing:

• we decided to focus on the default recipient view ("Users by Role") rather than introduce yet another view for explicitly handling groups alone.
• this default view takes the site roles as its initial layer of grouping, and we decided not to alter this. Even though groups may in principle span multiple roles, our use cases were strongly oriented toward groups of one role only - namely, Students.
• Since the number of roles could in principle be quite large, we did not want groups and sections to take up yet more vertical space on the Compose screen. We also wanted to avoid a significant usability problem where a single recipient could be presented in more than one place (which selection should be dispositive? There's no way to determine that with confidence, in the event of a discrepancy). As a simple way to minimize both of these problems, it was decided that grouping would simply be another way of arranging clusters of recipients in the expanded views, effectively introducing a second nested layer of grouping beneath the roles.
• Groups and sections would be mutually exclusive in their treatment, again, to minimize the problem where the same recipient could be selected (or un-selected) in more than one place. This leaves alive the possibility of multiple selections for a single recipient, simply by virtue of the fact that groups are not mutually exclusive, but we've at least confined the problem that far for now.

The end result is that there are 3 ways to expand a recipient list. The default way - an alphabetical listing of all contained members - is always available. If any groups are defined in the site, a second expansion action link becomes available: "Select Groups." If any sections are defined in the site, yet another action link becomes available: "Select Sections." The screen below shows a site with all three together for the Student role.

When the groups are expanded, initially only the list of defined groups are available.

A second expansion shows the individual members of a group. Some instructors tell us they need to check this to be sure a given group is the one they have in mind, and it also gives them the option of selecting only a few individuals within a group. The group/section views then also serve as another way of arranging large recipient lists for readability, since a full listing of all students in a large course can be unwieldy.