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.

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.