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.

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

Towards the end of September, amidst a chaotic time, the Octobox team was divided over the Sustain-A-Stack idea. One of the main concerns was that this whole system would turn out to be overly difficult to implement because of the scope of the project. Let’s face it, we weren’t building a website or some handheld device; we pretty much agreed to stay away from products like those because, first of all, we’ve been building websites all our lives. And secondly, the logistics of handheld devices can easily become an application for cellphones. In other words, we had already established our design values.

Over the past few weeks, we’ve been considering the importance of physical sketches in better conveying our project and its integrity. These sketches have become a significant component to our design process and given that it is time to finally display our progress in the form of a presentation, it is only fitting to post the sketches that have been created thus far.Furthermore, it is very likely that we will not have time to present these sketches during our presentation. This is because much of our presentation will describe the many other elements we’ve worked on. As it is now, we already plan to integrate an extra slide on design/aethetics values and integrity; thus, we’ll likely be short on time as it is.

Over the past week, our team has focused on better organizing the structure, direction, and scope of our project.