INSTRUCTIONS FOR A TYPICAL INTERACTION

Here is a sample scenario for checking email with ICE:

1) Download "ice.jar" and run "java -jar ice.jar" in the command prompt.

2) When the login screen appears, enter a username and password and press "Login"

3) Select "Check Email" from the list of current tasks and press "Choose Task"

4) When prompted to select an email, click on any email in the Inbox

5) The helper will ask if it can open the email, so press Yes.

6) When the selected email opens, the helper will ask how you want to deal with the email

7) Select "acting" and press "Choose Decomposition"

8) The helper will then ask how you want to act on the email

9) Select "replying" and press "Choose Decomposition"

10) The helper will ask if it can create the reply message.

11) Press "Reply" and then "Done" instead of letting the helper create the reply

12) The helper will ask if it can send the reply message.

13) Edit the reply message however you want and then press "Yes"

14) The helper will then ask how you want to finish with the orginal email

15) Click "deleting" and press "Choose Decomposition"

16) The helper will ask if it can delete the email.

17) Press "Delete" and then "Done" to let the helper know you deleting it yourself

18) The helper will then reset back to its opening task selection

WHAT WORKED

My motivation for this project was to serve as a starting point for an email helper application. While there were several approaches I could have taken, I chose to deal with simple user interactions. On the one hand, keeping the interactions simple meant that there would be less time spent creating GUI features, as well as more time spent working on the underlying task model. On the other hand, I liked the idea of an email application geared towards people who are not adept at checking email, exploring the internet, or even using a computer in general.

Therefore, I originally planned on implementing two tasks: "Check Email" and "Write Email". The idea was that these two tasks would be simple enough to implement in the GUI (which was not a focus of this project), while challenging enough to implement in the task model. Additionally, it also left room for the addition of more tasks, given adequate time. While I have successfully implemented these two tasks, there are a few limitations I had to end with, which will be discussed further in the next section.

Another aspect of the project to consider was the connection between the task model and the interface. First, the interface needed to be able to interact with the task model. Since the help was being performed outside of the email application (by the Guide, which is what runs the task model), the interface needed to be able to take the input from the user and send it to the task model. Also, the interface needed to get the results from the task model and display it to the user. Second, the task model needed to be able to interact with the interface in order to perform actions on the email application (for example, creating a new email).

While I originally planned to split the helper application interface from the actual email interface, I eventually decided to combine them. The intent was to keep the interface as simple as possible, so that the majority of work could be spent on the task model. However, while the end result worked as intended, in retrospect, it wasn’t the best approach for reason described in the next section.

WHAT DIDN'T

Although my original intent was to keep the application simple, the greatest weakness of this project is it became too simple. As an example, say I want the helper to tell me how to write an email. As implemented, the interaction from the helper tells me I need to create an email, and then send it (each of which can be performed by the helper if I allow it). The problem here is that it is just as complex (if not more complex) to tell the helper to create the email as it would be for me to just press the “Compose” button (which I’d then have to press “Done”).

One way to fix this “simplicity” problem would have been to incorporate more areas of email interaction into the task model. For example, I had started looking into incorporating such features as filling in fields (for example, recipient, subject, etc.), sorting through email (for example, how to decide what to keep and what to delete), dealing with address books, and even dealing with attachments. Unfortunately, I was not able to implement these due to time constraints.

Another reason I was not able to implement some of the higher level tasks was that they would have required additional changes in the GUI at the point when I was connecting the task model to the interface. For example, if I wanted to deal with address books, I would have had to create an address book feature. I had felt that I would have been spending too much time in the GUI trying to incorporate these features when my time was needed in more important areas I was still unfamiliar with.

It was this thinking that made me decide to keep all the interface and helper code in one class. In retrospect, I should have split them up into three parts: (1) The helper application, (2) The helper interface, (3) The email interface. The problem was that the email interface became more complicated than I had originally intended. Therefore, this one class became convoluted and hard to read. Since I didn’t want to completely rewrite my code, I cleaned up my current instead. While I had originally had different functionalities spread throughout the class, it is now organized.

Other work I would have liked to incorporate into ICE includes speech, response formatting (properties file, etc.), savable email and user databases, and a folder hierarchy. If I had implemented speech, it may have partially solved the “simplicity” problem, described earlier, since actually telling the interface to perform a task would probably be more intuitive. Response formatting, or changing the “generic” output (such as “Please CreateReply”) to something more readable may have had a similar effect. And finally, savable email and user databases and folder hierarchy could have been beneficial in sorting and address book usage. Unfortunately, I was not able to implement these features due to time constraints.

FUTURE DIRECTIONS

Overall, I think ICE is a good starting point. As it stands now, it would definitely not be useful as an email helper. This is due to the limitations discussed in the previous section. In order for this project to be more useful as an email helper, it would have to be incorporated in an actual email application. If it came to a point where ICE was being tested for effectiveness, the results of a dummy email system would not provide any real insights (unless, perhaps, we wanted to know what participants think of the interaction). First of all, the participants wouldn’t really care what happens (it’s not their email after all). And second, a real email system would be more unpredictable, which would better show the program’s capabilities.

If I were to use my current program as a starting point for another semester-long project (with the same goals), I believe I would start by reformatting my application classes in order to separate the functionality between interfaces, as discussed earlier. I would then focus on my email interface first so I’d be able to put in every function I can think of in the event that I would incorporate it into my task model (in some way or another). From there, I would move onto the helper interface and helper application classes to ensure they can accurately and efficiently communicate back and forth between the guide and email interface. And, finally, I’d spend the rest of my time adding on to the task model (possible rewriting if needed).