Functional Specification (2.4)

Owned by Former user (Deleted)
Last updated: Feb 26, 2007Version comment
8 min read

Feature Overview

See it running in action at http://qa1-us.sakaiproject.org:8580/portal (admin password is 'sakaigers')

Set of Goals

Sakai has always provided mechanisms for broadcasting messages to the entire participant list of a given worksite, but teachers and learners often have the need to target their communications more selectively. Even the relatively recent introduction of groups and group awareness to Sakai is still too coarse-grained and inflexible for some use cases.

Along another track, there is a felt need to compose and send email messages within the context of a Sakai worksite itself. Although the Email Archive tool has encouraged a model where the external email client is the preferred composition tool, and despite the fact that there may be no procedural difference - as measured in terms of mouse clicks - between switching over to a separate client and switching to a different worksite tool to compose one's emails, there is a great conceptual divide between doing one's work in one's site and displacing oneself into another piece of software for a related task. At the same time, the external email client cannot take advantage of integration with other Sakai tools.

The mailtool seeks to address these challenges, and takes these as its driving considerations:

  • the primary persona is an instructor trying to quickly target select site participants, where communication may be relevant based on role, group or section membership, individual identity, or combinations of these.
  • a secondary persona is a member of a collaborative site of any type (e.g. research group, department coordination site) wanting to send messages to specific other site members without knowing what their email address (or preferred email address) is.
  • the patterns of communication will differ between many courses (e.g. depending on how groups are used within it, and whether a site has a large participant list or small), and so the interface for recipient selection should be flexible and adaptable to many purposes and site social structures.
  • site maintainers should have some control over default tool behaviors for their site. A number of options will be settled on early - as a matter of maintainer preference - and although the option to change them on the fly should remain available, they should not have to be explicitly opted for with each new message.

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

Directly beneath the recipient selection view is an action link which opens a widget for attaching files to the email message. These attachments are files added from the user's desktop, and thus are not handled as resources or "official" Sakai attachments.

Email composition

The Subject: line displays the site title by default.

Whichever WYSIWYG editor is declared in sakai.properties is used is the message composition pane by default, but a plain-text box can be chosen in "Instructor preferences," detailed below.

Email Archive integration

Below the composition pane are two options, and the first is simply for the sender to receive a copy of their own outgoing message. The second is whether a copy of this message should be appended to the Email Archive tool. If appended to the Email Archive it will thus be visible to all site participants. If the Email Archive is not enabled for the particular site, this latter choice will not appear.

Defaults for both these options can be set by the site maintainer (see "Instructor preferences" below).

The Send Mail button is the trigger: it distributes the message according to all the selections made.

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.