Interactive Prototype #1 (Group 7) CS160, Fall 2001

Group Members:Walter Rader – webmaster and programming leadAmy Wong – graphics and documentation lead

Problem and Solution Overview

eFlash is a language-learning software package that simulates real-world flashcards with added functionality. Run on a PDA, it is flexible and allows users to customize it to their needs, allowing the selection of categories to learn and test from, a glossary of words, and the ability to add and remove words to learn. In our lo-fidelity prototyping and user testing, we discovered some minor changes that need to be made to the interface to clarify the functions of all the options. These changes included things like clarifying what the “back” and “next” button did and what would happen if those buttons or “exit to main menu” would do if you were in the middle of a test. In adding new words, we left out which category to put the word in. Another problem was making the customizing options more understandable.

Tasks

Two of the tasks that we chose for our revised interface are the same tasks from the lo-fidelity prototype and the other one is different.

The first task is to go and learn new words. This requires selecting a category to learn from and choosing which options suit the user best, such as audio and method of presenting the words.

The second task is to take a test. Users will select the categories they want to be tested on and then choose whether they want to be tested by multiple-choice, fill-in, or transcribe audio, or all of them.

The third task is to display a glossary of all the words added to eFlash in the form of a dictionary and find the translation of a specific word. The user just needs to select the display mode and scroll to find the correct word.

Revised Interface Design

This hi-fidelity prototype differs from the low-fidelity prototype in some subtle ways. We ran into some limitations in implementing the same layout that we had on paper. The basic layout of the buttons on the bottom of the window is rearranged to accommodate for the space required for each button.

For both the “Learn” and “Test” mode, the first difference is that the selection of categories does not have checkboxes (Fig. A.2, B.2). Instead, every time you click a category, it gets selected and highlighted. Also, to eliminate the number of screens to proceed through, the customization screens are shortened and simplified, so that the only option is which to display or test first: English side or Spanish side and whether or not to have audio. Rather than having an icon showing how many cards are left in the “Learn” mode, it just tells you how many are remaining (Fig. A.4). Also, when the

category(s) are finished, a window pops up indicating the end so that going back to Main is not as abrupt.

For the “Test “ mode, we only implemented fill-in, rather than being able to choose multiple-choice, fill-in, or audio dictation. We also eliminated the choice between Classic Test and Adaptive Test to avoid confusion, but may be implemented again later. We modified the layout of the score sheet, so instead of having the number right, wrong, and the percent, it displays the number of questions asked, how many were right, how many were wrong, and the percentage (Fig. B.21).

Because of some limitations with the Jornadas, we were unable to implement adding words to the software. Instead, we created a glossary of words that are displayed (Fig. C.2). Users can select a category to view terms from or else search for a word in the dictionary.

The first task scenario (Fig. A.1-A.14) is to learn about words from the “house” category displaying the English side first. The user simply proceeds one by one through all of the cards until the end.

The second task scenario (Fig. B.1-B.21) is to take a test from the category “The Farm”, translating English to Spanish.

The third task scenario (Fig. C.1-C.4) is to look at the words in the dictionary for words that relate to the park.

One thing that we didn’t implement was the “help” screen. This would have looked something like this:

Prototype Overview

eFlash was developed in a Windows 2000 environment using Borland JBuilder 5 Personal. It was transferred to an HP Jornada 54x using Microsoft ActiveSync 3.1, and executed on the Jornada in Hewlett Packard’s ChaiVM 5.1.

After using text- and command-line based development tools (such as Emacs and gcc) for other computer science classes, it was refreshing to be able to use a completed integrated development environment. JBuilder, despite some minor UI quirks, is a very well-designed IDE. The JBuilder’s integrated UI design tool, which supports AWT widgets, was immensely useful. Though helpful, the screens on the HP

eFlash

Help on the Learn mode

Help on eFlash overall

Jornada appeared somewhat different than on a Windows desktop computer. For example, the ChaiVM and the Java VM bundled with JBuilder display the text on buttons a bit different. Therefore, it was still necessary to run eFlash on the HP Jornada.

Though we were impressed with JBuilder, we were somewhat less impressed with ChaiVM 5.1. When we first began coding, it was a chore to write code carefully enough that it would run in ChaiVM. Much of the first day of coding was spent discovering by chance what would work in JBuilder’s Java VM that would cause ChaiVM to crash without displaying any error message. It is to be expected that less functionality would be supported, as it is designed to run on handheld computers, but a complete reference manual indicating unsupported features would have been invaluable. Even later in the development phase, added functionality would cause ChaiVM to abort, and it was necessary to experiment by commenting out sections of code to find the offensive instruction.

Most of the limitations of ChaiVM that we discovered were relatively easy to work around. For example, though it doesn’t support a case-insensitive string compare, it would be a quick job to code one ourselves. ChaiVM lacked some features that would have been nice, such as AWT’s GridBagLayout. The GridBagLayout is the most powerful, flexible, and complicated layout manager in AWT. Because it was unsupported, we were forced to use the null layout manager to get the widget placement as precise as possible. Though designing with the null layout manager is easier by far (as you can place widgets anywhere on the form and make them any size,) it is not a portable solution.

Other severe limitations of ChaiVM were discovered very late in the development process, and all attempts to work around them have failed. One feature that we feel is absolutely necessary in eFlash is audio support, and we could not find any in ChaiVM. Additionally, another feature of eFlash that we want to implement is the capacity for users to add their own words to the eFlash dictionary. As each word is associated with a picture file and a few audio files, it is necessary for the user to indicate to eFlash where the appropriate files are located on the Jornada. Unfortunately, file dialog boxes are implemented in Swing, but not AWT.

These last two limitations are severe and caused us considerable consternation. Both were discovered late in the development for this phase. Though it would be possible to custom-code a file dialog box, the lack of audio support is crippling. We investigated other possible methods of supporting audio. For example, we considered writing a separate application in another programming language whose sole purpose would be to play the audio files. Unfortunately, ChaiVM appears to lack the functionality to execute an external program from within the Java code. Because we consider audio support to be absolutely vital to eFlash, we have made the decision to rewrite the code in Microsoft Embedded Visual Basic 3.0 for the next design iteration.

As mentioned above, the user interface was designed in JBuilder using AWT. Hand-tweaking of code was frequently necessary. The main menu (screenshot A1) provides a central access point to all areas of functionality within eFlash. We attempted to make the UI as cohesive as possible, and to do so, most eFlash screens inherit from a DefaultScreen class. This class includes the title at the top of the window, configuration of the title-bar, and inclusion of the forward, back, main menu, and help

buttons as well as their default functionality (see screenshot A3). The functionality of the buttons can be re-configured in any class that inherits DefaultScreen.

AWT doesn’t appear to support using graphics (rather than text) to appear on command buttons, so we attempted to create an ASCII representation of a speaker to indicate the “replay audio” command button (A4). The text entry boxes in the test mode and in the dictionary look-up mode were positioned so that the keyboard and character-recognizer text-entry method on the Jornada wouldn’t overlap the boxes (B8 and C2). The dialog boxes (A14, B10, B13, B16, B19, B20) were hand-coded (as AWT doesn’t appear to support dialog boxes). We were unable to get their display to be uniform – hopefully this will be corrected for the next iteration.

The following were left out of this iteration of eFlash design:Audio support – no audio support available in ChaiVMWord addition – no file dialog box support availableStatistics – considerable additional coding would be necessary to support user statistics. We felt that this feature, though useful, could be omitted from eFlash at this point, as it will presumably not be the most frequently used feature of eFlash.Program options button – currently all options are configurable through the screens prior to the learn mode and test mode. In the future, the user may want to configure default options, but again, we felt this was unnecessary for this iteration.Help – we felt that we needed to get a good indication from the user what kind of information would be necessary before designing the help system.Some test mode options – due to the short design period, we left out other testing options such as multiple choice questions, audio translation, getting “hints” during the test, and a more comprehensive test score page that includes a list of questions answered incorrectly. These will be included for the next iteration.

We were able to cope with the lack of file dialog boxes by ignoring the problem for now and changing one of our tasks. Unfortunately, we feel that the lack of audio support will seriously detract from the eFlash demonstration. As audio isn’t supported, we will be forced to use the “Wizard of Oz” technique and speak the audio ourselves. With luck, the Visual Basic re-code will be completed quickly and this will be unnecessary.

Prototype Screen Dumps

A. LearnA1. A.2 A.3

A.4 A.5 A.6

A.7 A.8 A.9

A.10 A.11 A.12

A.13 A.14

B. Test

B.1 B.2 B.3

B.4 B.5 B.6

B.7 B.8 B.9

B.10 B.8 B.9

B.10 B.11 B.12

B.13 B.14 B.15

B.16 B.17 B.18

B.19 B.20 B.21

C. Dictionary

C.1 C.2 C.3

C.4