With the upcoming presentation consistently on our minds and evident dissatisfaction with the state of our physical prototype, the team decided that a change was necessary.

While this inevitably brought about conflict amidst our team, it was unanimously decided that there were some issues in need of addressing and a new iteration was somewhat timely.

Of the most pressing issues, there were two rather significant problems that were most imminent: a target audience in need of updating and the issue of an increasingly similar project amidst our IAT 404/5 class.

Firstly, our original target audience (specifically, busy young professionals) was obviously derived from our team’s identification of a problem: people leading busy lives rarely have time for gardening or the environment, regardless of their interest. However, this specific target audience became more of a hindrance than anything else; in short, it prevented us from looking into other situations where this product might be utilized and alternate user groups that could potentially be interested. But more than anything else, there was still the question of whether busy professionals would have an interest in this product for long-term periods. In addressing these questions, we’ve decided to drop the use of a target audience and develop a target persona instead. In contrast to target audiences, the target persona allows for less narrow-mindedness and a more open approach to the potential market dynamics. The details of this persona will be released next week with our presentation slides.

Secondly, and perhaps most infuriatingly, our team was rather troubled by the overt similarities between our project and a fellow team. Rather than dwelling on this, however, we decided to further differentiate our product by developing a new visual style and by emphasizing the above shift in target users. This will also be further addressed in our upcoming presentation.

Exercise One: Evaluation Criteria

Mission statement:
Strengthening the relationship between people and the environment by merging urban and natural spaces.

Project overview:
Mini indoor greenhouse used for growing herbs, vegetables and other small plants.

High-level goals/Goals of the interaction:

•   To grow and monitor plants/herbs/vegetables in a convenient and effective way
•   To create a heightened sense of awareness regarding the importance of organic foods in one’s lifestyle

Point of Interface/Why it matters:

• Box: To allow the watering and lighting of the plants in a simple, intuitive manner (single button for each control)
• Widget: To allow the monitoring of the growth and health of the plants

5 Qualities of Experience: Interactive, satisfying, engaging, smooth, simple

5 Goals of Interaction:
1. Enable user to monitor status of plants digitally(?)
2. Allow user to control lighting and watering of plants
3. Simplify plant care indoors
4. Create a give and take relationship between users and their plants
5. Easy access to organically grown vegetables and herbs

Ways our interface enables those experiences and qualities to be created in a functional way directly related to the interface and interaction:
1. create direct access to the status of my plant
2. constant update of box temperature and humidity
3. alert the user when water or temperature levels are too low

Participant Assumption

• familiarity with using computers
• familiar with the concept and use of widgets

Exercise Two: Prototype Usability Concerns

Our interface is primarily about ease in monitoring the status
of your plant while the physical prototype will function as a mini greenhouse to house plants, herbs or vegetables within your home.

Questions:
[Widget]
// Is the widget fully functional?
// Is the use of widgets ideal for the task of monitoring?
// Are the icons and labeling used clear enough to understand?
// Is the interface visually appealing? Does it meet the user’s expectation?
[Physical]
// Is the user able to water the plant?
// is the user able to manipulate the lighting?
// Is the user’s experience with the interaction similar to that of typical gardening? Is the work required for maintenance simplified enough?
// Is the product visually appealing? (shape, size, material) Does it meet the user’s expectation?

Goals and Expectations: (Participants will be able to…)
[Widget]
// Understand the function of the widget
// Recognize what the labels and icons represent
// Immediately identify the status of the plant
// Will give high evaluating points to the aesthetics and experience of the interface
[Physical]
// Water the plant
// Manipulate the lighting inside the box
// Have an enjoyable and more simplified interaction with the plant
// Will give high evaluating points to the aesthetics and experience of the physical prototype

Exercise Three: Evaluation Method

We will be using a combination of methods for the evaluation of our physical and interface prototype. A realistic scenario will be introduced to set up the do-it-yourself walkthrough. The participants will be given a task to monitor the status of their plant using the widget for our prototype test. From the information gained from the widget, the user will be asked to manipulate the physical box prototype either by manipulating the lighting or by watering the plant. Group members who will be taking down notes will observe this process.
After the test, a one-on-one interview will be conducted. Participants will be asked questions regarding the functionality and experience of using the interface and physical prototype. Suggestions for improvements are welcome.

Exercise Four: Data Collection Methodology

Widget
• Ease and speed of learning functionality
• Differentiating between the clickable and non-clickable buttons
• Understanding how to use the calendar
• Quality and number of responses regarding: visual aesthetics, navigation, form
• Number of errors they encountered

Box
• Ease of learning functionality
• Refilling/releasing water
• On/off lighting
• Inserting/removing plantlife (access/door)
• Quality and number of responses regarding: aesthetics, form, usability
• Average amount of time to complete each task (because, you know, our users are busy young professionals and they’d need to finish tasks quickly, for sure)
• Portability
• Ease of grabbing and carrying

Exercise Five: Deliverables

The results of the usability test will be presented through an in-depth evaluation report of the process in which we will be able to pinpoint our observations accompanied with photos. This will help us formulate recommendations to apply certain changes to the design and continue to develop our product a step further.

Team Name:
Team Octobox

Team URL:
http://www.octobox.org/final

Team Members:
Kurtis Beard
Derek Pante
Manuel Pineault
Andrew Thong
Katrina Chua
Sammy Jayetileke
Brian Quan

Prototype Plan Fall’07 Midterm Walkthrough:
1) Project Overview
2) Scenario One: Physical Prototype
3) Journey Framework: Physical Prototype
4) Demonstration: Physical Prototype
5) Scenario Two: Widget Prototype
6) Journey Framework: Widget Prototype
7) Demonstration: Widget Prototype

Prototype Plan Open House:
1) Built widget, no connection to physical prototype
2) Working physical prototype (water and light systems)
3) Brochure
4) Poster in the background

Equipment Requirements:
1) Table
2) Projector
3) Power bar & outlet
4) Arduino
5) Chairs [6]

Space Needs:
Enough space for our physical prototype, table, and projector screen.

Space Allocation:
We’d like to be outside!

Description of the Prototype

The Sustain-a-Stack is a mini indoor greenhouse used for growing herbs, vegetables and other small plants. Ideally to be located in a living room or a kitchen, this product is targeted for people with interests in the organic food market or in growing their own plants at home but don’t have the space or time to do so.

The physical prototype will include a watering system and LED lights in a box to sustain the plant. Other sensors that will pick up temperature, humidity and water levels will be added later on in the process. The levels that the sensor will detect will transmit to an interface widget on a computer through the Arduino microcomputer. The widget will allow the user to monitor the plant by checking up on its status, viewing the last watering date, water the plant and turn the lights on and off.

Although the widget provides efficient feedback to the user, it will only simulate the desired action since there is still no communication between the interface and the physical box as of now.

 

Representative Task

At home: The user would approach the Sustain-a-Stack physically and check on its status. Based on how often the plant needs to be watered, the user would push the watering button and the system would spray water on the plant. The lighting system will automatically turn on and off in a cycle but if the user wishes, the lights could also be controlled manually by pressing the light toggle button.

At work/elsewhere: The user would check on the status of the plant by accessing the Sustain-a-Stack widget on his computer. Then he can check the temperature, humidity and water levels. Also shown are the days since the plant has last been watered which then prompts the user to click on the water button on the widget interface. Lights can also be manipulated through this widget.

 

Actions Needed

Pre-planting -performed everytime user is to plant something new

• adding soil to fill the bottom of the Sustain-a-Stack
• planting seedlings within the soil
• filling water reserve to enable watering through the press of a button or through the widget

Everyday

• watering - box/widget
• turn lighting on and off - box/widget/automated
• monitor status of the plant in person or through the detected levels on the widget interface - box/widget

Once in a while

• trimming the plant
• reaping the harvest of the produce or herbs grown to be consumed

 

 

Users + Experience

Our target audience will be people who are interested in the organic food market specifically people who want to grow their own organic food. Typically, our users will be busy, having little time to take tend to their plant. They will have familiarity with using computers to be able the access the widget. They should also have an idea of basic plant care. The user will be able to take care their plants indoors ideally in their living room or kitchen. Having the Sustain-a-Stack is meant to motivate people to grow their own food, promote green living and display the progress they’ve made with their plant in their homes.

 

Recent Events

Pete, our original prototype plant, died over the Christmas break. RIP. So we got Petunia (Pete-2-nia)

We also had to design a poster for the Open House coming up. Andrew will make a better, digital version of it but this is what we have for now. We plan to include a description of the product, our target audience, mission statement and a bit of the processes we went through.

PROTOTYPE OPTION

After considering the range of options, we have decided to produce a partially operational appearance prototype of our Sustain-a-Stack. This best suits the feasibility of our proposed product because we feel confident that we can build a hardware prototype of our box, which will look very close to what we want as our final physical form, with some of the functionality partially working. For instance, we will attempt to have a partially working version of our watering system for this prototype, as well as our humidity sensor; but, we know that it will be a difficult process to get these functions working, so we will be content to have these moderately working.
FEASIBILITY STUDY

A. Software Issues
1. Software involved: Flash

2. Programming the Arduino board to sync with Flash is a technical issue that we will need to overcome, as only a few of our members have done this before. Also, programming the calendar and the humidity-sensing functions of the widget will be other programming issues that we’ll need to deal with.

3. We believe that we can deal with these issues as we have two members who have had prior experience working with Flash and Arduino together (Kiks and Brian), as well as an expert ActionScript programmer (Manuel); the other remaining members of the team also have working knowledge of Flash.

4. Our primary option is to use Flash and Arduino together. But, as a backup, we are willing to try other options, such as Max/MSP and Arduino, or Max/MSP and the Teleo kit (most of our members have experience with Teleo).

5. All the members of our team have access to both Flash and Arduino-related applications. Any “special” equipment, such as the Arduino board, can be borrowed from the library. Alternatively, Andrew is planning on purchasing an Arduino board himself, so we will most likely be using his, with the library’s as a backup (and/or for testing purposes).

B. Hardware Issues
Our main focus is to have the hardware detect information to send to the Arduino board which will take a bit of trial and error. Enough time is alloted for this task and if we have extra time, we can shift our focus to having the buttons and the watering work.

1. Hardware involved:

• Arduino - library (then later on, buy one for ourselves)
• sensors - potentiometer, temperature sensor, humidity sensor (?)
• LED’s
• wires
• wood
• housing (start of with cheap plastic for the prototype)
• buttons (to control the light and water distribution)
• soil
• plants - start off small (Pete II)

2. Getting multiple sensors to interact with the Arduino board will be one of the major technical issues that we will need to overcome. Making sure that the water and soil from the plant’s environment do not disrupt the electronic hardware components (and vice versa) will be another issue. Finally, getting the buttons to work correctly (e.g. releasing water whenever the water button is pushed) is another issue to deal with.

3. Though we’ve had prior experience with Arduino, we’ve never tried connecting more than one sensor at a time, which will require more research and experimenting in this aspect. Some of our members have dealt with electronics before so we’re fairly confident with solving most of our hardware component concerns.

4. In the case that a specific sensor does not function as we intend it to, there are other sensors out there that we can use as substitutes. Our options for the hardware will depend on the availability of supplies in the stores that we will be going to.

5. All the hardware that we will be needing are easily accessible at any hardware store. We will be doing most of our purchases at Lee’s on Main Street and the other electronics store on the same block. The whole group has agreed to pitch in to pay for the materials that we will be needing for this semester.

PLAN FOR CREATING THE PROTOTYPE
1. We have roughly 4 weeks to prototype before the presentation and user testing.

• First Cycle: Rough construction of the form of our box, and a low-fidelity interface of our widget;
• Testing: Running our tests with the same, or at least similar, types of people that we interviewed in the first semester, as they represent our actual user group.
• Second Cycle: We’ll take the feedback from the testing and put it towards our “Final” prototype, which will hopefully be working…

2. Most of the construction will be done on Saturdays and Monday nights. We will also want to bring whatever we have ready to class to get instructor feedback, ask questions and to continue working on it.

3. We will be taking care of the funds that we need for the project. Outside dependencies will just be help and advice from instructors. The amount of supplies and resources that we will be needing is undefined as it will continue to change through our trial and error prototyping process but we have already listed down what we need for the initial construction session this Saturday.

4. Roles of members:

• Hardware-wise, Andrew, Derek, Kiks and Kurtis will be dealing with wiring and attaching the sensors, buttons, etc. to the constructed physical prototype. Brian will be in charge of getting these components to transmit the necessary input to the software side of the product.
• Software-wise, we will be assigning Manuel to do the Flash ActionScript programming, working closely with Kiks, who will be handling the Flash-to-Arduino programming components. Derek and Brian will be assisting Kiks and Manuel wherever they can.Sammy will continue to manage the group, make sure we stick to the timeline and do the shopping for materials needed.

5. We have back-ups for most of the aspects of the prototyping phase. The alternatives for the technical software and hardware components are discussed in our feasibility study above.

Whew! That was a long post. We’ll try keep it short and sweet next time