Phase 3: System Prototype and Evaluation Plan

• Overall description of the final design.
• Multiple prototypes illustrating various portions of the final design. 
  • Sufficient visual material to convey the prototype.
  • At least one scenario from an end-user's perspective.
  • An assessment of the aspect of the design. 
    • Feedback from potential users.
• Detailed evaluation plan. 

Many garden enthusiasts visit the Atlanta Botanical Garden (ABG) to observe the natural habitats and wealth of flora available. Visitors interested in plants often find that a plant of interest does not have a sign at all. The remaining plants with signs do not offer the in-depth information many horticulturists are looking for. A visitor who wishes to obtain more information about a plant currently questions nearby ABG staff or goes to the library and looks up interesting plants whose signs have not been broken or missing. Inevitably, there will be missing/broken signs for plants and not enough staff members to answer the detailed questions of every curious visitor. The proposed Plant Tracker® system aims to provide the garden enthusiast with customizable levels of detailed information about plants of interest, even ones with missing labels. The system is being designed for ABG members and draws from many technologies that have been assessed by potential users. With feedback gathered from prototyped pager-sized textual/audio systems, PDA like information devices, and tablet computer ideas utilizing GPS technology, we have come up with our latest prototype. Potential users were again asked to assess the prototypes, and criteria for evaluation of our design was also formed.

The Atlanta Botanical Garden, though offering a wealth of flora accessible through direct observation, does not offer in-depth information about the various plants observed. With the members subgroup of the garden visitors containing many garden enthusiasts, providing more detailed plant information to members is expected to benefit that particular subgroup. Our project proposes a system that will given the members the opportunity to have more detailed plant information at their fingertips. Many members have expressed a desire to have more information about plants and a way to identify plants that lack signs. In order to design/propose a good system for horticulturists, we assessed that user population to find out their needs. Based on the data collected from our iterative assessments, we found that the members need a system that has exceeds many usability criterion; to make a feasible evaluation plan for our project we chose to focus on customizability, task conformance, and learnability due to their particular importance in our domain.

Customizability is very important for the users of our system because it allows the users to access different levels of detailed plant information. In order for our system to be task conformant, we are offering the user different ways to search or system for plant information. Learnability is always important when a designer is trying to implement something new into an environment. If a system is not learnable, it ultimately will not be useful, therefore, our users must feel that the system is easy to learn.

As for the requirements for our design, we divided them into two categories: functional and non-functional. The following list summarizes the functional requirements:

1. Accessible to groups as well as individuals

2. Reflects current state of information

3. Selectable depth/customizable

4. User must be able to identify plant

5. User must have access to these data fields about plants:

a. Scientific name

b. Common name

c. Physical attributes

d. Location on ABG map

6. Information must be disseminated in various environmental conditions

7. System must be retrievable (theft prevention)

8. Screen size must be sized to accommodate a map view of entire ABG

9. Take-home option must be provided

Some of the non-functional requirements are the following: a learnable system that will not impinge on the natural landscaping, a system that will be durable, and a system that will gather feedback.

Our system will not have many problems fitting into the larger system. In part one of our project we declared our larger system to include the following: maintenance, marketing, educational programs, and outreach programs. Our system will provide answers to questions that were normally asked to the gardener’s and other staff freeing up their time to maintain the gardens. Marketing could benefit from our system by enabling strategic partnerships with plant vendors. A partnership could be formed with Pikes, when information is printed up on plants, the print outs can include coupons for such a plant at stores and could lead to a percentage of the sale coming back to ABG. The ABG is a non-profit organization; if a plant vendor sees the Plant Tracker as a way to make revenue then they may subsidize the cost of the technology. Vendors may also agree to contribute a percentage of the coupon sales from Plant Tracker print outs to keep the ABG running, which is something the users definitely want. Plant Tracker devices can also be used in the curriculum of the educational programs at the garden as quick reference to plant details. The outreach program can use the device to form relationships with schools and loan Plant Trackers to groups of visiting students who are doing reports on plants hopefully inspiring young horticulturists (potential members).

Group members contributed ideas to what our system should look, feel, and operate like during part two of the project. We gathered feedback from potential users at the ABG and discussed amongst each other what would be a reasonable way to incorporate the ideas that would best serve our user population. We came up with the following attributes of the Plant Tracker to begin part three. We realize this is an iterative project and continued to make improvements to the design as part three progressed. In this report you will find a revised design summary which includes changes we have made/plan to make to our design to match against our final evaluation plan.

The 6.5" x 9" x .8", 1.2 lbs. Plant Tracker features an adjustable shoulder strap, an earbud, stylus-based capture, and 6" x 8" active matrix LCD screen. The frame of the device is 1/2" wide to accommodate holding while not obstructing the screen with phalanges. The dimensions for the Plant Tracker are such to offer semi-powerful computing and information display in a unit that can be handled by males and females of varying ages without being cumbersome. The adjustable shoulder strap is a feature that affords users hands-free carrying so they can still perform other actions, i.e. photography. The strap also alleviates the weight of the device when not in use, and protects the device from possibly being dropped. Users can operate the device using the screen with the stylus provided. The stylus rests in a carve-out in the device molding when not in use, and is attached to the device by a 13" cord. The cord serves as a security device to prevent lost/stolen styluses. The length of the cord is designed to reach all points of the screen without becoming entangled with the shoulder strap or other user accessories. The Plant Tracker also has a single earbud attached to provide optional audio plant information to the user. The volume of the earbud will be controlled by the user interface with a variable volume level from mute to loud. The stylus and the earbud will connect to the device at the top in the center to enable easy access to left- and right-handed users. Since the device rests in a power cradle while not in use, there is no need for a power button. There will be a power LED that flashes when the battery is low to provide feedback when a system will shut off shortly.

The active matrix display was decided on so that users from can see the screen from multiple angles. It will present the user interface which provides buttons to reach plant information by text as well as a detailed ABG map. Information about a plant can be reached by locating it on the map and stylus-tapping it, causing the map to zoom in one level at a time centered around the tap. The map is initially set to a bird’s eye view showing the whole garden (Home screen). If a user zooms into a section that they are not near, the map will display an arrow pointing to the user’s location in reference to the current display. The location arrow provides a reference for users interested in navigating to plants they are not near at the time of the search. A map mode search was essential for the design given the environment does not offer signs for all plants of interest. Zoom capabilities are available to get to a level of granularity in which plants can be displayed 40 pixels apart for ease and accuracy of selection. The HOME button can be used at any time to return to the bird’s eye view of the map, and indicate the user’s position in the garden. In addition, users can navigate to a different site in the garden to view a specific plant, by text search and then locating it on the map. The buttons that will be persistently visible in all modes are: a HOME button to allow for recovery from any wrong turns when searching; a zoom button to call the variable ZOOM available when map is displayed (greyed out when not available); a SEARCH button that will become disabled after the search screen has been invoked; a SAVE button that will be made available in the plant detail screen; and a HELP button to recall a device tutorial.

There are many plants that have accurate signs in the garden; to retrieve information on these plants, a search function is available in Plant Tracker. In text mode, instead of zooming according to location, the search button will load the search screen. The search screen has four ways to search for plant information. A user can search by "common name", "botanical name", listed plants within a certain "Garden area", or listed plants with these "plant attributes". Only form fields associated with their respective search methods will be displayed — the search screen will have items available according to the search type selected. These items are: buttons for TEXT DISPLAYs or MAP LOCALEs; a list to show plant fast find results (partial words are completed and plants containing those letters are displayed); a keyboard; plant attribute drop down menus; a SAVE button to keep plant information in an optional "wheelbarrow" to take home at check out time; and the main interface buttons.

The PLANT DETAIL screen can be reached from the map mode or text mode. This screen shows details of the plant under many headers. The headers where influenced by what potential users would like to know about a given plant and the questions that gardeners hear frequently. When this page is reached, high level information is displayed next to headers, which can be expanded by tapping the metaphorical shovel icon to its left. When the PLANT DETAIL page is reached, audio begins to stream to an earbud, the page features an AUDIO on/off button . In this screen, pictures of the plant are also available. There will be a dial that allows the user to view plants in different seasons by tapping the appropriate season. The SAVE button is active on this screen. When tapped, the current plant will be stored in the wheelbarrow to print or email to users upon checkout at the library.

The device will require a dock to recharge overnight. This will take place inside the Sheffield Library to protect the devices from weather. The device is checked out from the information desk at the main entrance from a cart that supplies a few at a time according to demand. Plant Trackers are returned to the library at the end of a visit when items in the wheelbarrow can be printed or emailed. The devices have a USB type A plug to connect to the librarian-operated server that can download the latest system versions. The Plant Trackers have flash memory that hold around 6GB max of memory; all the plant information is stored locally on the device. The device shows no on/off switch, it simply goes into standby when it is recharging.

The icons on the interface will be based on a gardener’s journal metaphor (shovel, wheelbarrow…). We feel that the information the Plant Tracker provides is what could be found in the log of an enthusiastic gardener. The audio will be recorded by an actual gardener and integrate horticultural vocabulary into the stories of plants.

We decided not to include handwriting recognition because it forces the user to conform more to the system than vice-versa. We took feedback from the part two design prototypes of a pager-sized textual/audio system, PDA like information device, and tablet computer ideas utilizing GPS technology, and have come up with this design.

A storyboard of our prototype was developed, consisting of five frames of sketched user interaction in the garden.

The storyboard method of prototyping was used for several reasons. First, it affords an opportunity to view the device within the context of the larger system. In addition to illustrating how a user might come in possession of the Plant Tracker, it also shows how they conclude their visit, and have an opportunity to take home information. Secondly, it illustrates how the device can be used to enhance, or at the very least not diminish, a group experience. Earbuds give an additional channel of retrieving information when eyestrain might set in, or when users prefer to view the plant instead of the screen. The earbud form factor is much less obtrusive than headphones. And the volume control allows the user to have even more control over the group experience. The screen’s size and quality could also be assessed in terms of group usability. Thirdly, the illustrative qualities of storyboarding help to visualize how a user might accomplish different tasks with the device, as well as where possible slips and errors might occur.

Frame 1 shows how the user would enter ABG and check out the Plant Tracker. While all visitors must stop by the ticket booth to be admitted the garden, only members have access to the device. They go to the information desk just inside the main entrance, in the courtyard, show their membership card, which indicates that they have paid a deposit, and receive a device. First time users are given a brief of instruction on how to use the device. A "Help" (later changed to USAGE GUIDE) button is pointed out, in the event that they need to refresh their memory on how to use the device. The user then puts the earbud around her neck (until needed) and begins touring the garden.

Frame 2 shows one way of using the "map mode." The user can see what plants are in a specific area within the garden. For example, Storza Woodlands is at the far north end of the garden, and the user, before walking all the way there, would like to know if there are plants there that might interest her. She taps that area on the map until she zooms in to the level of showing individual plants. She sees that there are ferns located in that area, and decides to go there. She gets lost in one of her searches and must return to the HOME map to begin her search again.

Frame 3 indicates a user finding information about a plant he’s viewing. There are approximately 7,000 plants at ABG. His plant of interest does not show a marker with the botanical name of the plant, the user first selects the "botanical name" search criteria since he thinks he remembers the name of it from another garden he begins typing the botanical name. A FastFind feature (to help narrow the huge list of plant names) allows for all-inclusive plant lists to progressively narrow down as each letter is typed in, until the entry being searched is viewable on the screen. The user selects the entry, and a textual display of information is shown. He was wrong about the plant, he tries again using the zoom in on the map and his search returned the plant he was looking for.

Frame 4 shows the user taking advantage of the audio feature available, and how the audio feature is designed to limit disruption of a group experience. The volume is adjustable, and use of a single earbud instead of dual or full-coverage headphones allow the user to hear others. Pleasing ambient sounds are still noticeable as well, such as water fountains. In addition, the earbud can be removed and comfortably placed around the user’s neck while they tour the garden.

Frame 5 shows how users can use the Plant Tracker to see if a specific plant is located in the garden, and where. Again, the user can use the same actions steps as was in Frame 3 to see if the plant is listed in the database. If it is, the user can select the "Garden Location" button on the text page to show the user on the map where the plant is located. In addition, the user can save any of the plants she is viewing. A list on the right-hand side of the screen shows the plants that are collected. At the conclusion of her visit, she can take the device to the on-site Sheffield Library to have her saved information printed out or sent to her e-mail address.

Assessments of this prototype address the system in general in the ABG environment. Potential users gave feedback on the design decisions of the Plant Tracker and how it should integrate into the ABG’s larger system.

The system should use a scanning device (similar to those you find in Wal-Mart ® or Target ® for scanning the price of an item) to scan items of interest instead of GPS. That person had concerns that GPS had not yet advanced enough to accommodate the precision we require. This feedback requires some things about the ABG to change however, the labeling system and the proximity of the plants to the pathway. ABG currently does not have accurate signage and having barcoded plants would probably lead to the switching or absence of barcodes as well. Furthermore, getting to the plant to make a scan can be difficult when plants are far from the walkway, our GPS technology will be able to provide information about this plant without destroying others to walk to it. GPS Technologies available to the public are often accurate to within feet, GPS technologies exist and more are being made available daily that have more pinpoint accuracy.

Another user suggested that instead of GPS location finding, we might opt for sensors placed throughout the garden that the device could use to triangulate the user’s exact position; proposition being that sensors are cheaper and more reliable than scanners. Technologies like this were taken into account by our team during phase 2 of the project and we feel that GPS offers more utility when it comes to selecting plants so it will also be used to locate the user.

The device should incorporate an "emergency locator", that is a button to indicate where the restrooms and exits, etc are located in reference to the user’s position. We will not focus on these features in this release of Plant Tracker, but the device stores it software in Flashable memory, should an update for this function become available, the Plant Trackers can be flashed to include it.

Users who were not very technically savvy felt that it would be difficult to remember the details of the system if they visit infrequently. We feel that its important that we address learnability and we plan to change our HELP button to a USAGE GUIDE button that will include a tutorial to refresh such visitors’ memory quickly. When the device is getting checked out, brief but concise instructions will be given.

Users pointed out that they are unaware of any map the ABG has that features the low level detail we describe. This is valid and will have to be included in the software of our system. We have chosen to have flashable memory to be able to update maps if any permanent exhibits are added, removed or relocated. When creating maps with low levels of granularity down to a plant, Fitts’ law could be used when deciding how close hot spots should be on the screen and how large should they be given stylus-based capture. We also plan on incorporating some of Alice Woodruff’s research. The concept of tap tips would be useful on our map to help users identify the location of plants, or clusters of plants, that have stored information.

Some mentioned that the keyboard lacked a spacebar, then found it but in an place they weren’t used to. This kind of description slip may occur frequently as some users are used to using their PDA simulated keyboards that have the space below the keys in a qwerty style. We will adapt our keyboard to a qwerty layout but will not include all of the keys such as Tab etc… The spacebar will also be placed beneath the keys and backspace will be moved in this change to decrease the description slips that will likely take place.

We prototyped the interface for a number of reasons. The prototype user interface design is a composite from all the group members’ ideas. It is important to find out if the interface can be operated by users of diverse computing ability. The interface must take into account many users needs, many of which we (as designers) would be unaware of if we did not prototype this way.

There were issues to be explored regarding Fitt’s Law and selectability. We presented the potential user with a task and encouraged them to explain to us how they would go about achieving the task and assessing their experience afterwards.

The user interface was sketched out by group members in pencil, pen, and computer tools. The features that we saw most useful were gleaned from these sketches and a composite graphic was generated reflecting what we thought was an appropriate user interface. The interface as we took it to the ABG looked like this:

The user interface that was prototyped has the following flow available:

4. Determine the plant name

5. Determine the type desired display result

Jim is standing in front of a plant of interest to him. He is considering planting this flower in his yard, but would like to know if the flower is available in other colors. He checked out a Plant Tracker from the courtyard entrance to help him find alternative colors.

The first thing that Jim does is tap the Search button with the stylus. Once the next screen is loaded, the second thing that he does is to taps the Botanical Name radio button. Afterwards, using the stylus he types in the botanical name of the plant. The first letter he taps appears in the text box above the simulated keyboard and a list of all the plants that start with that letter are listed in the text area below. As he continues to correctly tap in the name of the plant letter by letter, the number of plant names in the list shrink. Once Jim recognizes, the name of the plant of interest to him in the list box, he stops tapping in the name with the stylus and taps the name in the list box. Once the name of the plant has been tapped with the stylus, Jim taps the Text Display button to find out more information about the plant.

Once the next screen is loaded, it takes Jim a while to figure out that the shovel icon left of the word can be used to dig deeper since there is no instruction visible to him about that feature outside of the tutorial. He taps the shovel next to Flower color in the text area. The shovel button is then transformed into a downward pointing arrow and a list of flower colors is listed under the main heading, Flower color. After observing the flower color information, Jim decided that he would like to take a printout of the plant datasheet home with him. In order to retain the plant information, he taps the save button. After saving the datasheet, Jim takes the device to the garden library to obtain his printout.

Once he enters the library, he hands the Plant Tracker to the librarian and informs her that he would like to print his stored plants’ data. The librarian connects the Plant Tracker to her computer via a USB connection and uses the software on the ABG Server to print. Once the datasheet has finished printing, the librarian hands Jim the datasheet. Jim thanks her and leaves the garden. He leaves the garden with more knowledge than he ever had before.

Our user interface prototype was found to have the following flaws according to the user. In this section we determine if and how reported flaws are to be addressed and attempt to categorize some of the errors users were making so that we have a better understanding of our users’ expectations of the interface.

Most found the interface easy enough to tap the "SEARCH" button with the stylus to go to the search function. On the search display only a few found it simple enough to determine which search method (i.e. common name, botanical name, garden area or plant attribute) to use and where to input the search criteria they had. We believe that this is due to a visibility problem with our prototype not graying out the disabled form fields on the screen enough to inform the potential users cannot input data in them. Our final product will take into account that visibility issue.

Most users entered the plant botanical name using the keyboard correctly and found understood the concept of FastFind placing similar plant names in the text area beneath the keyboard. When they attempted to use it in some cases, users expressed a Freudian slip (associative activation) occurring since they expected tapping the name in the list to bring them automatically to the plant detail screen. The association was explained to be with Web interfaces having the functionality of some drop down/scrollable menus resulting in a link to other pages. We feel that this is a low priority error since our system offers two options of displaying plant information. Incorporating this would only provide one option for showing the plant information and we feel that if/when the error occurs the user will then proceed to the buttons beneath the list to submit the information.

Many potential users felt helpless without the familiar "enter" button and found the "TEXT DISPLAY" and "Map Locale" alternatives did not relate to sending a request for information. Many requested that we provide one button that is more suggestive to entering the entered data. As the objective of this device is to provide detailed information, we view this as a system breakdown and give it a high priority. To handle this we will change the interface to have a radio button asking the user to select map location results or text results and they will be entered by pressing the "Find it" button.

There were also a considerable number of users who explored the search interface tapping on things to see what happens. The way users used the "plant attribute" search method was interesting. Users had one of the two common occurrences:

This brought to our attention that some users had description slips when looking for variations of a plant or all plants with a common variable due to our current interface. We feel that more feedback and instruction to the user would decrease the frequency of those two occurrences so we intend to incorporate more feedback into our system.

The users demonstrated an overall desire to find all the information within few screens. We will take this into account when adding features to our system based on assessment and feedback. It is our intention to retain the levels of the interface as they currently stand and creatively modify their layouts if necessary.

An unexpected assessment was made when it was clear that users did not begin scanning the search screen at the upper left-hand corner, but rather went directly to the keyboard to tap-type in the plant name.

Users were left confused regarding when and how they can get their printouts and how to know if save worked. This is considered by our group to be a system breakdown and therefore will be addressed. We plan to change the interface to leave printing and emailing to the librarian who runs the server-side of the Plant Tracker software on the computer in the Sheffield Library. Those function are only to be available when the device is connected to the library computer via a USB cable before it is checked in (equipment number is logged as returned my <member name> at <time>) then docked for recharging.

Going back through previously browsed plants was a concern for many. We feel that if we added some more feedback near the save button like a list of saved plants in the "wheelbarrow" then the user will have the ability to browse through them by tapping the desired plant. Other concerns were the keyboard lacking numbers to input plant heights. We noticed that our user interface prototype did not accurately display that the lists were drop down style and not keyboard input. That shows a mode error because the keyboard is only available while searching by common/botanical names so users seem to believe that it is available for all search criteria.

Users also felt the interface’s digging metaphor was confusing without explicit instruction or indication on how to use the shovel icon. We plan on adding such information to our interface.

A wood based mock-up was created to match the form factor of the Plant Tracker given in the design summary. This mock-up was made of particle wood, used an earbud, a rubber band connected to a pen (stylus), and a mesh adjustable shoulder strap secured in by screws. This form factor prototype was not intended to actually function, but simulate the events that would occur if a user were handling a finished model.

The form factor mock-up gave users an opportunity to wear the device with other accessories. The mock-up was durable enough to withstand being dropped. The wooden prototype also included a user interface screen on paper taped to the front side of it in order to show users where the screen was to allow them to tell us if they could comfortable hold and operate the device without covering too much of the screen.

Larry, a new 3-month member of the Atlanta Botanical Garden has requested the device to aid in plant information searches while he peruses the garden. He is interested in finding plants to place in his yard and would like to find plants that are likely to look good together and will grow nicely in the soil in his yard. After receiving a brief description of how to use the device, Larry sets out to choose a few plants to beautify his yard.

As he wanders through the rose garden, Larry spots a Chinese pepper plant that has red, orange and purple peppers amongst the green leaves. He really likes the plant’s appearance and thinks it will present nicely with his azaleas. Larry has a Plant Tracker draped over his shoulder as he looks at this plant so he decides to use it. Larry’s first maneuver with the device is to extract the stylus from its nook to tap the SEARCH box on the screen. Larry is right-handed so he holds the device cradled on his left arm as he continues to search for this plant. When the search screen appears Larry elects to search by Botanical name by tapping that option. Larry then sees a keyboard but is not tempted to type on it with his fingers since he watched the device’s tutorial and remembers that it supports stylus-based capture only. Larry taps the simulated keyboard to enter the Botanical name of the plant. After Larry enters the plant name he looks for the "ENTER" button to place his request. At this point Larry realizes that the device wasn’t designed conforming to paradigmatic designs that most people associate with computer usage and instead of an "ENTER" button, the designers of this device have opted for a "TEXT DISPLAY" and "MAP LOCALE" button. Larry doesn’t think that this is a very convenient design because he is expecting textual and audio feedback, but he clicks on the "TEXT DISPLAY" button as he was shown in the tutorial after he gives up looking for "enter." Larry is happy to have reached the information he requested yet is aggravated that the system doesn’t conform to his expectations. His aggravation causes him to tap the screen harder than he normally would and squeeze it harder as well while digging deeper into the Chinese Pepper Plant information. While being rough with the Plant Tracker as a result of his aggravation, Larry realized that the device was built sturdy and he quickly returned to treating it with care.

As he is viewing the text, he taps the audio off with the stylus, because he wants to look at plants while he reads and doesn’t want any audio input to impose on his audio input from one of the nearby garden water fountains. Larry then removes the earbud and and drapes it over the device. Larry taps the stylus to several of the shovel icons to get more information regarding the best soil type, lighting requirements and water requirements for the Chinese pepper plant. It is presently Summer, and a photo of the plant in summer is presented on the display so he also clicks on the Fall, Winter and Spring options to see what the plant will look like throughout the year. Larry is pleased with the aesthetic match the Chinese Pepper plant will make with his azaleas and wants to save the information. Because Larry is interested in horticulture he doesn’t want to use any more paper than absolutely necessary, so instead of printing the information at the garden library, he opts to send it to have the librarian send it to his e-mail address.

We brought the wooden mock-up to the ABG and wanted to see if the users felt the prototype had dimension and carrying features that they would be willing to work with in their future visits. Many potential users really showed an active interest in the idea and discussed it giving their opinions (to which we are grateful) and others expressed a complete desire to remain removed from technology and all that it entails/covers.

The potential users that were kind enough to give us feedback had the following to say:

Many users felt that 1.3 lbs was too heavy. This feedback requires serious consideration. We can decide to make the product require less computational strength by limiting some features, decreasing internal memory etc… reach a lighter weight. We can also anticipate Moore’s law working for us and plan a release of the device when technology is small enough to reach a desirable weight for the users.

About half of the users felt that size of our mock up was appropriate. Grabbing the tablet was a problem for a few, they explained that grabbing tablet with their left hand made their left thumb overlap the screen. The screen size will be decreased slightly, enough to afford fingers resting on the edges of the Plant Tracker.

A common issue was also that adding another device to the other accessories that some people bring to the garden would be burdensome. It was suggested that the device be a digital camera as well so that users can bring one less device. Users also suggested the device be very small. We feel that the functionality of our device should not be sacrificed too much and that its utility will deem it desirable to visitors with or without accessories. Making the device and the screen any smaller would not be feasible if it is to display such a large map.

We revised our system design to hopefully increase the learnability. As our group members are actively involved in the design of the device, we also "know too much," biasing our assessments of each proposed function of the device. We need to ensure that our design reflects neutral, potential user, feedback. Potential user feedback allows us to discern desirable features. We plan to evaluate our revised system according to the evaluation plans we discuss to measure how much we meet our key usability criteria.

The user interface of the system that will be evaluated in phase 4 will have the modified look, feel, and functionality.

The MAIN MAP PAGE display will have a ZOOM function, a SEARCH button, The content of the wheelbarrow (save list), and a HELP button. This will allow for more options of holding the device if the risk of obstructing the view of buttons along the right side of the screen is decreased.

The TEXT SEARCH PAGE only requires that the SEARCH method be selected, A home button for recovery will be included and the HELP button will also remain. The save list will remain as well in case at any time the user wishes to refer to past searched plants.

The SEARCH PAGE in common name or botanical name searches requires the keyboard to enter text, so the keyboard and text window above it should be visible as well as the list for the FastFind feature and FIND IT! button. For garden area searches, only a text area with a list of garden areas and the FIND IT! button need to be displayed. While searching for plant attributes, only the drop downs that contain plant attributes need to be displayed along with the FIND IT! button. Drop-down menus with prescribed categories (such as ranges of plant heights under plant attributes height category) would eliminate typos during data input while searching by plant attributes. Also, any subjectivity could be addressed by these drop-down menus: flower colors can be confined to a list of about 12. These drop-down menus could be considered forcing functions, keeping users input within the parameters of the database.

The PLANT DETAIL page should have the photos that show the plant at varying seasons, but the control to change season should not mimic a compass, rather a circle. The Audio control on this page will display as a variable slider with mute at the bottom and loud at the top. The audio control will stand vertical to reflect raising the level of something. This screen will have instructions about what to do with the shovels and audio. The SAVE button above the past searched items list will be enabled to give the user a way to add the current plant to the list.

The software on the server (librarian’s computer) will be a simple text based interface allowing for input of an email address and a display of the items in the wheelbarrow to be printed/sent.

Customizability ­ Customizability refers to the "modifiability of the user interface by the user or the system." (DFAB) Plant Tracker will be considered customizable (while still being usable) if it allows the user to access different levels of detailed plan information.

Task conformity ­ Task conformity refers to "the degree to which the system services support all of the tasks the user wishes to perform and in a way that the user understands them." (DFAB) Plant Tracker will be task conformant (while still being usable) if it allows users to achieve the task of obtaining detailed plant information in a way that they find comfortable.

Learnability ­ Learnability refers to the "ease with which new users can begin effective interaction and achieve maximal performance." (DFAB) Plant Tracker will be considered Learnable if it can be learned to be used effectively (detailed plant information can be found by new user) during the first visit with it.

Our plans of evaluation for our proposed project include a cognitive walkthrough. We will have three or four HCI "experts" perform a plant information search using the mock-up device. We will use these walkthrough evaluations to determine the learnability of our proposed device. We will give the experts brief instructions, allow them to watch the tutorial and then the cognative walkthrough will be administered. The selected actions will be as follows:

1. Type in the botanical name by using the keypad with the stylus
2. Select the correct plant listed by tapping on it with the stylus

We specifically chose this task sequence based on our user interface prototype assessment results. In making our design conform to user requests we are affording learnability for users of the device (trusting that they are aware of how they learn). The HCI "experts" are asked to perform the five actions delineated above, and answer the following four questions for each step. Answering the four questions will embody a believability story.

Our Cognitive Walkthrough Assessment will allow us as designers to evaluate the learnability of our proposed system before actually implementing it. Doing such evaluations before building products aims to prevent a market failure if our users do not want to learn how to use our complicated Plant Tracker. With HCI "experts" performing the same task and then answering the same questions, we can find possible difficulties in our design from an unbiased viewpoint. Learnability incorporates the principle of predictability; if a device is not predictable then the user cannot count on affecting a desired result based on a completed action.

We will be determining if the Gardener’s Journal metaphor works for our system. The users must be able assess that the shovels dig for deeper levels of detail. Since the objective of the system is to present customizable levels of detailed information, if the user does not understand that more information is available to them then our design is not as usable as it could be.

The we can base customizability of our device on whether or not the user is able to operate the audio feature, and get another channel of information to them. They should be able to learn how to turn the audio on and off. The ability of the user to walkthrough our system and prepare information to be taken home is also an aspect that will influence our usability rating. Users felt it was important to know how to turn off the audio as many members prefer to hear natural sounds but still want to use the device while viewing the garden.

We use heuristic evaluation for evaluating the interface in terms of three usability criteria, customizability, task conformity, and learnability. Above all, this evaluation is especially efficient for customizability and task conformity because these might be difficult to be assessed by user testing. We plan to take advantage of heuristic evaluation to find obvious interface problems that need to be addressed in our project according to priority. According to Nielsen, evaluation by different 5 to 7 HCI experts covers around 75% of the whole usability problems found for large systems yet we believe the samll size of our academic project justifies the use of three.

Our heuristic evaluation will focus on the following heuristics:

We will make a request for 3 or 4 HCI experts (students who have taken or are enrolled in CS 6750 at GA Tech). We will have them look through the interface at least twice, evaluate it independently, and make a written report if possible. We will just observe them and will not interpret the evaluator's actions. Our system has a domain-specific aspect (for members of gardens), so that evaluators might have less domain knowledge; for example, they might not be familiar with the garden terms. We support evaluators by answering to their questions and offering hints if they need. The interface will be evaluated in terms of the three usability criteria, considering the selected heuristics proposed by Neilsen:

1. Match between system and the real world

An environment like the ABG attracts people who speak the language of horticulture. Our system should present the information that they would expect to find out about a plant and be accessible through a logical sequence of actions. We feel that the ABG is integrated into the system well especially since a major part of the interface is an actual map of the garden. It must me tested to see if the user can use that representation of the real world ABG to get to the information they desire.

2. User Control and Freedom

The Plant Tracker should allow a user who makes a mistake an easy way out. We provide a home button on pages other than the home screen (bird’s eye view of the map) to give users who inadvertently ended up where they are, an emergency exit. We suspect some users will accidentally zoom on the map and wish to return to the zoomed out view. It is necessary to evaluate whether or not the user knows how to return to where they’ve been. Our usability depends on whether the user is comfortable with moving around in the interface, this comfort cannot be achieved if they feel they don’t have the freedom to explore areas knowing they can always come back. This is a sensitive subject for our design as a person may want to abort an action and search for the plant in the other mode.

3. Consistency and standards

We have made efforts in our system to reduce the amount of guessing a user has to do while using Plant Tracker. The scientific name of a plant is unique only to that plant so users have a way to consistently receive correct results when they request data. When scientific names aren’t available, we attempt to make it clear to the user where they are on the map using GPS and a "you are here" indicator so that they don’t have to wonder where they are and can find where to zoom down to ultimately find the plant they are looking at. We will evaluate if there are any ambiguous signals or times we may not have uncovered when the user feels confused or that we have an inconsistent interface.

4. Error prevention

Measures have been taken by accruing user assessments and we have iterated our design multiple times to ensure that we prevent errors from occurring. Errors have a way of surfacing so we will seek experts who may bring to our attention that our error messages for the errors they find are adequate and informative.

5. Help and documentation

A system that stands to be used infrequently needs to have help functions available.

We then will get together evaluators and observers (designers) and discuss about the evaluation and possible modification. After gathering all evaluations, make a problem list and have the evaluators rate 0 to 4 scale in each 4 aspects. In terms of frequency, the scale enumerates 0 to infrequent and 4 to very frequent. In terms of impact the scale enumerates 0 to insignificant and 4 to severe. In terms of persistence, the scale enumerates 0 to appearing infrequently during one user experience and 4 to persistently appearing during that experience. In terms of market impact, the scale enumerates 0 to no real impact and 4 to major impact. Although the values are enumerated the severity will be discussed qualitatively. We can use the feedback from the heuristic evaluation to revise our interface design and fix the problems that can be easily fixed.

The HCI evaluators will be asked to use the think-aloud method of analysis. This analysis is especially useful when the designers are interested in what prior knowledge a user brings when encountering your system. After a quick debriefing, the user will be expected to perform a task with the system while verbalizing their thoughts and what their gut feeling (mental model) is telling them to do. The evaluators will be given the following scenario:

The prototype will then be handed to them with the instructions to verbalize any thoughts that they might have as they are navigating through the interface. Lapses of action will be used to prompt the evaluator for what they might be thinking at the time and encourage them to continue thinking aloud.

We can use this method to observe:

- What slips were made and how persistent and frequent they were.

- What optional action steps were taken, and how persistent they were taken.

- How often the evaluator asked for clarification.

- Where their eyes traveled.