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.

User Testing

Reflections

Return to Laundry Quandary homepage.