Design

Throughout our design, our team tried to maintain as much simplicity as possible.  Following this design decision, the implementation of our laundry app consists of an all-in-one home screen.  This screen presents the following information to he user:

1. A list of the available washers and dryers in the user's laundromat area
2. How much time is remaining for a machine that the user has put clothes in and started
3. A specific message should no washers/dryers be available at that particular time.  This functionality also allows the user to be notified when a machine becomes available.
4. The ability to leave notes on machines, read notes from previous users on machines, and indicate that you are about to use a machine.

One important design decision that we incorporated into our document was the removal of the "finished" machine state.  Previously, we had wanted to let the user know if there was some other user's clothes sitting in the washer/dryer that needed to be moved before that user could use the machine, but users found our implementation of this state confusing.  After much deliberation, we decided that the cons outweighed the pros of keeping this state, so we removed it.

In our heuristic evaluations, multiple evaluators were confused with what the checkboxes associated with each machine actually controlled.  To address this, we changed the text label next to the checkbox from "Notify me when this machine has finished" to "I've loaded this machine".  We feel that this message makes the checkboxes' functionality much more apparent.

Implementation

There are three main components to the implementation of our design:

1. The back end allows us to update and receive information about the current states of all the machines in the laundry room. It keeps track of things like the machine’s identity (washer vs. dryer), its name, its availability, minutes remaining until finished, and any notifications associated with it).
2. The xml layouts.  Besides the home page layout, our xml layouts include the individual displays for available machines, progress bar displays for any machines that the user is currently running, as well as the display that is used when no washers or dryers are available. These are inflated and added to the main view according to the state of the laundry facility. We have additional xml layouts for leaving notes and reading notes/conversations between users.
3. The main java code, which dynamically updates the interface by finding the current states of all machines in the laundry room from the back end, and inflating the appropriate xml layouts. This code is also responsible for changing the interface and the back end when the user interacts with the application.

There were several important implementation decisions we made. Firstly, we decided not to use a server in order to store user information and allow them to message each other with laundry instructions. Instead, we implemented as though we were only concerned with a single user. This user could interact with other hypothetical users, but the user would simply receive canned responses. We made this decision because we thought dealing with a server is outside the necessary scope of this class, and we wanted to focus more on the GUI.

In addition, we decided not to create an automatically updating laundry facility in our back end. Instead, we simply demonstrated our application with a set of static machines that we could add or remove. Unfortunately, this meant that our users could not receive updating time estimates for laundry machines. However, for the purposes of the GUI demonstration, we didn’t think this was too much of a hindrance.

Overall, we did not come across any insurmountable implementation problems that affected our final product. We managed to produce a GUI that was very much as we envisioned it.

Evaluation via User Testing

Choice of Users

We chose our four Testers from two main groups, one group being laundry room users at the fraternity two of us live at, and one group being laundry room users from Simmons Hall. We picked users from people that we know, but this should not significantly impact the user set selected. We also made the decision to use only people who already had compatible Android phones. We felt that this decision would ensure test results reflecting our design's internal consistency with the Android platform. If we had been designing for iPhone as well, then we would include iPhone users, but currently our service only has a prototype out for Android users. Our user set should consist of people already owning a compatible smartphone (since one would not buy a smartphone just to help with laundry in communal living places) - thus we chose a user set from known friends who are Android users. 

Representativeness of User Set

The users we chose are almost representative of our target population. Both genders and several different races are represented. All the users are in the age range of 18-22, but this makes sense because our target user population is college students in communal living situations who have Android phones. The way in which they are not representative is that all of them are from MIT, which might have specific laundry procedure habits as a school. It would have been more difficult to get users from other schools on a short schedule, but we would do this if we were to take the project forward at other schools.

Our task briefings were pretty similar to our briefings from GRX. One crucial difference is that we installed our prototype application on their phone, instead of using the prototypes we built We did not use a demo as part of our b

Reflections

Return to Laundry Quandary homepage.