Platform and Software Requirements
Our design specifies that our User Interface is for a mobile application. Therefore, we chose to use the Android operating system for our first computer prototype. Android makes it reasonably easy to distribute and debug a prototype of an application.
Our prototype should work on Android 2.3 ("Gingerbread"), but it also has backwards-compatibility enough to work on phones as far back as Android 2.1 ("Eclair"). We also expect that it will be able to run up to Android 4.0 ("Ice Cream Sandwich"), but we haven't tested it much for that Android platform version. You should not need a large amount of free space to run our app's first test; having a few megabytes free should be far more than enough.
Instructions on using our Prototype
First, download the software at the provided link (see last section) onto your phone. You should be able to run it after you have downloaded it. Follow instructions related to GR3, linked from our home page on the wiki. If you have questions, you can ask our group via email (jcfox412@gmail.com, cperera90@gmail.com, or meganr@mit.edu). In general, testing such Android applications is quite intuitive.
Important: do not rotate the phone while using our prototype. Rotating the phone will cause our app demonstration to refresh, losing conversations and notes that the system ought to preserve. This issue should be fixed by the next prototype iteration.
Shallow components of our User Interface?
Some of the components of our UI are not fully implemented, and will have to wait for later design iterations. These components include storage of previous notes, and user information handling. All of the system state as far as current notes consists of "canned" state for now, because we don't have multiple users or effective preservation of the state they put on the laundry machines. Another shallow component is the inter-user messaging (we don't actually send any messages, just display entered text for now).
In general the shallow areas can be divided into several categories: first, inter-user interactions are shallow in our prototype. We currently only use canned interactions. Second, we do not provide actual information about the laundry machines. This step will only be fixed once we have hardware to interact with; in our exploration of the user interface, this component can reasonably remain shallow forever. A final shallow area, and one that also would require some hardware functionality to truly work, is that of planned actions or timed actions. For example, our app says that it can provide a notification "when the next machine is free". Knowing this information - determining when a machine becomes free - is a hardware problem. There is also a software problem; right now, we don't actually send a notification. This is an aspect we could test by setting the notifications to send after a fixed, short timer instead of when an actual timer expires, and this is an aspect which we will want to make some progress on for our next iteration.
Link to our first Computer Prototype
Download at web.mit.edu/jcfox/Public/LaundryQuandary.apk
Simply visit this link from the browser in your phone, and the rest of the process should be very intuitive.