Email Is For Everyone: Progress Report #2

Table of Contents

Project Summary

In an increasingly digital age it can be difficult for the elderly and disabled to keep in touch with family and friends. The lack of email communication skills can leave these people isolated. One of the primary factors which limit the adoption of email by the less technology savvy users is the complexity of modern email applications. These programs are all designed to accommodate the needs of every possible usage, and therefore add many features which unnecessarily complicate the basic usage.

The Email Is For Everyone (EIFE) application will present an email interface which is designed only with the most basic usage in mind. It will be designed with the OLPC as the target system to allow users to operate on a simple preconfigured low budget system. It will allow users to compose messages by selecting a predefined canned message, thus avoiding need of a keyboard, or by typing a custom message to be sent. EIFE users are safeguarded by a Guardian Angel, a trusted friend or family member, who will approve any new contacts before their messages are allowed through. This avoids many of the risks of email use while keeping the rewards intact.

Problem

Most e-mail clients are feature heavy, complicated, and require computer literacy to set up and use. Viruses, phishing, and other e-mail related scams are prevalent and may not be easily recognized by someone with little or no computer skills. Sending and receiving email can be risky and confusing, especially when receiving emailed attachments. In addition, accessibility becomes a challenge for people who have difficulty typing on a keyboard (especially one as small as that on the OLPC).

Proposed Solution

An advantage which this project has over other email communication systems is that it can break away from the standard email paradigms. The users are less likely to be familiar with standard email applications, so something new and more intuitive to a base level user can be modeled.

We propose an application for the OLPC which will allow for users to understand how to perform basic email tasks without requiring extensive training. Since this program will be targeted at the most basic user, many of the extensive features which are required in full email suites can be excluded. There is no need to support multiple email accounts, folders, different styles of sorting, or other features.

User Interface

The user interface for the application will feature a contact list and a message view pane. The contact list will show all of the contact which have been added. The list will be alphabetically sorted to allow for easily finding contacts, but contacts from which unread messages have been received will be displayed specially at the top of the list to attract the user's attention. When a contact is selected from the list, the full history of messages sent to and received from that contact will be displayed in the message view pane. A field in which new messages can be composed will be shown in this pane as well. The user has the ability to enter new messages to send by selecting a canned message or by typing in a customized response.

Application Features

Message composition would be accomplished by selecting a predefined canned response from a list (which would allow one to avoid using the keyboard) or a custom message could be in. On an outgoing message the user would be able to capture and attach an image from the laptop's built in webcam in order to create custom messages with minimal effort.

The messaging will operate on a white list filtering concept. EIFE users will only see messages from contacts which appear in their contact list. The user will have the ability to add new contacts to their list if they so choose, but the primary method by which contacts are added will be via a 'Guardian Angel'. The concept of a Guardian Angel is a third party which will be given permissions to manage the contacts for the EIFE user. This third party would most likely be a more computer savvy friend or family member. The Guardian Angel would be given full control to add or remove contacts from the email whitelist. When a message is received from a new contact, the Guardian Angel is notified and can either allow or block the contact. This system prevents any spam or unsolicited emails from being received by the user and protects them from email scams.

Special handling will be added for messages which contain photo attachments. When such a message is receive the user will be presented with an option for whether to import the attached images to their photo album. Rather than displaying the full image in the email, a size reduced version of the image will be shown. An optional feature for the application, if time allowed, would be a photo album screen saver which would show all of the photos received and stored from contacts.

Project Architecture

The project design follows a client-server architecture. Within the client-server architecture, there are three primary components:

• Client application to run on OLPC hardware
• Email server to provide account, email, and configuration support
• Guardian Angel web interface to allow for email and contact management.

Overall Project Architecture

Design Goals

The goals for the project are broken down into the requirements for each of the primary components presented in the Project Architecture: client, email server, and Guardian Angel.

Client

• Email Messages
  • EIFE will allow users to send to and receive email messages from users on their contact list.
  • Users will never receive email from senders not on the contact list. If email is received from a user not on the contact list, that user must be added to the contact list by the Guardian Angel before it can be viewed by the user.
• User Interface
  • The EIFE interface will provide an extremely intuitive interface which will allow for less computer savvy users to use the system.
  • The EIFE interface will allow for sending and receiving emails without requiring the use of a mouse or keyboard.
  • Keyboard is an option for sending custom messages, but canned messages can be sent without use of a keyboard
  • Primary navigation should be possible using the on screen joypad and game buttons, which would allow for the laptop to remain in tablet mode at all times.
    • If it is not possible to create an intuitive interface with these controls, the assumption of availability of a touch-screen may be made.
• User Account
  • The EIFE will provide a setup wizard to create (or modify) an account, including the emailed request for management to a Guardian Angel. This configuration may be performed by a third party on behalf of the new EIFE user.
  • Account information will be stored locally and used for each subsequent application start-up.

Server

• Authenticating a client
  • An EIFE client will need to be able to authenticate themselves to the EIFE server. The EIFE client will communicate to the EIFE server via TCP/IP and XMLRPC in order to provide the EIFE user’s credentials, such as a username and password combination. The EIFE server will then attempt to authenticate the client.
  • If the user credentials are valid, an authentication token will be returned to the client.
• Synchronizing with a client
  • An EIFE client will need to be able to connect to the EIFE server over a network in order to synchronize its user’s settings. This will include canned messages, contacts, and groups.
  • Synchronization attempts will need to be authenticated in order to ensure only a valid EIFE user can synchronize their accounts.
  • If a ne w contact, group or canned message has been added by the EIFE user’s Guardian Angel, it will need to be sent to the EIFE client during a synchronization request.
  • If an existing contact, group or canned message has been deleted by the EIFE user’s Guardian Angel, a notification of the item’s removal will need to be sent to the EIFE client during a synchronization request.
• Sending messages from a client:
  • The server will need to accept messages sent via the Simple Mail Transfer Protocol (SMTP) from the client application and forward those messages to the intended recipients.
  • If any errors occur, such as an invalid contact address, the server will forward the invalid message along with a description of the problem to the EIFE user’s Guardian Angel.
• Receiving messages for a client:
  • The server will need to accept messages, sent via SMTP, which are intended for any of its EIFE users.
  • The server will need to validate any sending addresses to ensure they appear on the recipient EIFE user’s approved contacts list.
  • The server will need to pass received messages to a SPAM detection program to calculate a SPAM rating.
  • If the received message exceeds the EIFE user’s SPAM rating threshold, the message will be discarded.
  • If the sending address does not appear in the EIFE user’s approved contacts list, the server will place the message in the EIFE user’s pending messages folder and the EIFE user’s Guardian Angel will be notified of a pending contact approval.
  • If the address which the message is being sent from appears in the EIFE user’s blocked list the message will be discarded and not passed on to the EIFE user.
• Sending messages to a client:
  • An EIFE client will periodically request to download any new messages received by the server via the POP3 protocol.
  • Each message download request will need to be authenticated using a username and password combination. Only a request presenting a valid username and password will be allowed to download messages or otherwise communicate to the server over POP3.

Guardian Angel Web Interface

• Management of EIFE users
  • EIFE user management requests will be received from the server. A unique management request key will be created, stored, and sent to an email recipient as a GA management request.
  • The EIFE management request will contain a URL including the unique request key. When this URL is activated the user will be directed to a web page giving them a choice of either associating the request with an existing GA account or creating a new account to associate it with.
  • If a new EIFE management request is sent out for the same EIFE user, the previous request key will be invalidated and attempting to use it to add the user for management will result in an error.
  • If an EIFE client sends out a request for a new GA they will be immediately disassociated with the old GA.
    • A GA account has no purpose without any EIFE accounts to manage, so login will be disabled if all EIFE accounts associated with the GA account are removed. The account will still be valid to allow for EIFE accounts to be added at a later date.
• Messaging with the EIFE users
  • Each GA will have the ability to send email messages back and forth with any of their managed EIFE users. A full message history for communications to and from each user will be available.
  • Incoming contact approval
  • When new messages are received from a contact which does not appear in the EIFE user’s contact list, the GA will be notified of a pending contact approval.
  • The GA will be given the opportunity to read the incoming message and decide whether or not the contact is valid. If the contact is valid they can be added to the user’s contact list and the pending message(s) will be delivered to the user.
  • If the contact is not valid, the GA has the option to block further messages from the user and delete the pending messages.
• Manual contact list management
  • The GA will have the ability to manually add new contacts to the EIFE user’s contact list. This may be done in response to a contact list addition request message sent from an EIFE user.
  • Removing existing contacts or blocking new or existing contacts will be possible through the same interface.
• Template message management
  • The list of template messages with the fields requiring user input (or no input fields for purely canned messages) will be editable by the GA. This includes the ability to add, remove, and edit any canned messages. These changes will be automatically pulled to the EIFE client on its next configuration update query.

Design and Technology Decisions

Programming Languages

Python

While the OLPC uses Linux as its underlying operating system, and therefore any general-purpose programming language available for Linux is a possible choice for development, the OLPC's sugar environment was written in python 2.5 and the python libraries that encapsulate it are already supplied. This makes it the recommended and most commonly-used programming language, and the natural choice for the client-side portion of our application.

Java/JSP

JSP and Java were chosen for the Guardian Angel web interface. The project team already has strong experience with both of these languages which helps decrease development effort. Any selection of web interface language would end up generating html content for the client browser in the end, so the question comes down to the coding and server side effort. JSP and Java web applications are easy to maintain and deploy in a container like Apache Tomcat. The popularity of these languages makes them a natural choice, as libraries and forums can help to solve any issues encountered. Java was also chosen for the Server component of EIFE to provide simple interaction with the Guardian Angel web interface by having both run inside the same Java Virtual Machine (JVM). A search of open source email server applications turned up a well designed and documented Java application "Java Email Server" which will function well as a library for our application and decrease the code which needs to be written.

Data Storage

The data storage requirements for the client and server components were vastly different in terms of scale, available tools, and processing capabilities.

Client

There are many open-source relational and non-relational database systems which are mature and readily available. The choice of a database system for the EIFE client would ideally be one that is both small and integrates well with a standard Python API. Options such as using the MySQL RDBMS were not considered practical since such as system would add considerable overhead and bloat the client side OLPC application. Other options included much smaller systems, such as the Derby RDBMS, which are much more practical to embed and distribute in an application. However, the Derby system did not have the support of a Python API and would require the use of Java and a JVM installed on the OLPG. This would also add considerable bloat and overhead to the client-side application and therefore would not be practical. Finally, it was decided to use the SQLite RDBMS. SQLite is extremely small and is frequently embedded in applications as a back-end database system. Furthermore, SQLite comes with Python API support and is already included in the current OLPC SDK.

Server

The server requirements for a database system did not have the programming language or size constraints that the client had. However, the server could be expected to handle much larger amounts of data. MySQL is a well-supported, open-source database RDBMS and is commonly used today as the back-end for many of the large sites on the Web.

Email

An important decision during the project was to choose an e-mail system which would meet the needs of the OLPG project. With the timeframe of the project being relatively short, it was preferred that as much of the e-mail system as possible would be adapted from an existing e-mail system. This would save time by not requiring the project members to have to implement basic e-mail functionality from the ground up.

E-mail is mature technology, with many open source systems readily available to choose from. For the EIFE project, it was preferable to minimize the number of different technologies and programming languages used. Most of the EIFE client application will be developed in Python, while the Guardian Angel system was already planned to be developed in Java. Ideally, the e-mail system chosen would therefore be implemented in either Python or Java. This narrowed down the choices a lot. For a Python system, the only acceptable choice would be to use the SMTPLib library. However, this library only implemented very basic e-mail functionality, such as sending and receiving messages. Further functionality such as message validation, storage, and filtering would need to be implemented from scratch. After spending some time implementing a prototype SMTP e-mail server in Python, it was discovered that the amount of work needed would be considerable. However, an open-source, GPL licensed alternative called the Java Email Server (JES) was found which appeared to offer much more needed functionality. As its name suggests, JES was written in Java and would integrate nicely with the other server components which are also being written in Java. JES came with both a POP3 and SMTP service already implemented, as well as a framework for storing and handling messages received by the server. It was decided that JES would save considerable development effort and therefore should be used as the e-mail system for the EIFE server.

Use Cases

Client Use Cases

Use Case #1: UC-Request (Add Contact Request)

Client Use Case: Add Contact Request

Use Case #2: UC-Receive (Receive a Message)

Client Use Case: Receives a Message

Use Case #3: UC-Send (Send a Message)

Client Use Case: Send a message

Use Case #4: UC-Settings (Set Up or Modify Use Settings)

Client Use Case: Configuration

Server Use Cases

Use Case #1: UC-AddGroup (Server Requested to Add a Group)

Server Use Case: Add to Group

Use Case #2: UC-ServerRecieve (Server Receives a Message for an EIFE Client)

Server Use Case: Receive a Message

Use Case #3: UC-MessageRequest (Client Requests New Messages From Server)

Server Use Case: Request New Messages

Use Case #4: UC-ServerSend (Client Sends E-mail to Server)

Server Use Case: Send a Message

Use Case #5: UC-AddContact (Server Requested to Add a Contact)

Server Use Case: Add a Contact

Guardian Angel Use Cases

Use Case #1: UC-Associate (Guardian Angel Registration)

GA Use Case: Registration

Use Case #2: UC-Auth (GA Authentication)

GA Use Case: Authentication

Use Case #3: UC-Contact (Approval of New Incoming Contact)

GA Use Case: New Contact

Use Case #4: UC-Template (GA Add a New Template Message)

GA Use Case: New Template Message

Prototype

Client User Interface

The user interface for the application will consist of one mail screen divided into a contact list and a message view pane. The contact list will show all of the contacts that the user is able to communicate with. The list will be alphabetically sorted by last name to allow for easily finding contacts. Contacts from which unread messages have been received will be displayed again at the top of the list to attract the user's attention.

The main user interface with a selected template message.

When a contact is selected from the list, the full history of messages sent to and received from that contact will be displayed in the message view pane. A field in which new messages can be composed will be shown in this pane as well. The user has the ability to enter new messages to send by selecting a template message or by typing in a customized response. The user can then capture and add images taken from the onboard webcam.

The main user interface with a custom message.

The image capture interface with a custom message.

Special handling will be added for messages which contain photo attachments. When such a message is receive the user will be presented with an option for whether to import the attached images to their photo album (figure i). Rather than displaying the full image in the email, a size reduced version of the image will be shown. An optional feature for the application, if time allowed, would be a photo album screen saver which would show all of the photos received and stored from contacts.

The main user interface displaying a received message with attached pictures.

The first time the program is run the set-up wizard will be automatically activated and displayed. This user will walkthrough steps necessary to set-up the user account. The set up steps are as follows: 1) Prompt the user for their name, 2) Ask the user to choose a EIFE user id and password. 3) Ask the user to enter the email address of the person they are designating as their Guardian Angel, and 4) Confirm all information.

Guardian Angel Web Interface

The Guardian Angel Web interface is designed to be used by a user with more computer savvy than those using the EIFE system, so its complexity can be higher. It will allow for a single Guardian Angel user to manage communications for several EIFE clients. The following presents a walkthrough of the user interface prototype for the web interface.

1. The requirements for the login page are simple. The user must enter a login and password and press sign in to login. If login fails the user is presented with an error, otherwise they are directed to the user home page. Note that a registration button is not required, as registration is only possible through an EIFE user management request.
   

   Guardian Angel Prototype: Login Page

2. Upon successful login the user is presented with their home page. This presents them with a summary of the account activity and status of their managed users. A list of the managed users is available which consists of links to the management page for each EIFE user. These links are updated to indicate the number of items requiring user attention.
   

   Guardian Angel Prototype: Main Page

3. When an individual user is selected for management, a specialized management page will open. This page shows more detailed account activity for the user which may not be shown in the summary on the home page. A list of the account management activities is shown which show the different ways in which the client can be managed.
   

   Guardian Angel Prototype: User Management Page

4. The User Messages page can be used for sending and receiving messages from a managed user. These messages will appear in the EIFE users ‘Guardian Angel’ communication section. Message history with date and sender information is shown and new text messages can be sent using the provided text field. Note that once the User Messages page has been opened. The messages are assumed to have been read and the unread messages count will be cleared. The new messages will still be specially highlighted to draw attention.
   

   Guardian Angel Prototype: User Messages Page

5. The Pending Contacts page is used to manage incoming messages from addresses which do not appear on the EIFE user’s contact list. Messages are grouped by sender and displayed on a single page. The contact sending the message can be added to the contact list, in which case a new contact page will be shown, after which the messages will be sent to the client and no longer appear in the pending contacts page. The contact can also be blocked, meaning that future messages from that address will be automatically deleted. Messages can be deleted which clears out the current messages but does not require blocking the contact. A spam detection tool will be used to rate messages on the likelihood of spam. Messages with very high ratings could be automatically deleted, and those which are allowed to pass would be marked with the spam rating to aid the Guardian Angel in filtering messages. Note that unlike the User Messages section, the Pending Contact items requiring attention count does not change until the user takes action to add, delete, or block the new contact.
   

   Guardian Angel Prototype: User Contacts Page

Database Design

Database Design

Deliverables and Timeline

Project Timeline

• Progress Report #1 - January 23
• Use Cases Complete - February 1
• Design and Research Complete - February 4
• Progress Report #2 - February 27
• Database Design Complete - March 2
• Development Complete - March 18
• Test Plan Complete - March 21
• Testing Complete - March 25
• Project Website Compelete - March 26
• ELW Presentation - March 27
• Final Project Report - April 3
• Web Presentation - April 3

Assigned Tasks

• Progress Report #1 - Crystal, Jeff, Torben
• Design and Research Complete - Crystal, Jeff, Torben
• Client Use Cases - Crystal
• Server Use Cases - Torben
• Guardian Angel Use Cases - Jeff
• Progress Report #2 - Crystal, Jeff, Torben
• Database Design - Torben
• Development Complete - Crystal, Jeff, Torben
• Test Plan -Crystal, Jeff, Torben
• Testing - Crystal, Jeff, Torben
• Project Website - Crystal
• ELW Presentation - Crystal, Jeff, Torben
• Final Project Report - Crystal, Jeff, Torben
• Web Presentation - Jeff

Progress Overview

The current team progress made includes the following:

• Several project meetings have been held.
• The project's scope and team organization has been defined.
• The team organization and project description form has been submitted.
• The team has acquired an OLPC and investigated the user interface, features, and capabilities of the OLPC.
• Research and set up of the development environment and emulator has been completed.
• The overall design has been completed and development is now in progress.
• The first and second progress reports have been written.