...
GUI Section | ScreenShot | Design | Implementation |
|---|---|---|---|
Home Page | | Users are first greeted by our home page, which is a simple layout of buttons. Relative button size corresponds with frequency of use -- that is, the larger buttons are more frequently used than the smaller ones. This data was found from user polling and testing. |
|
| | We opted to make collection view laid out with images and with names of the item underneath it. Initially we toyed around with text or image only, but we found during our testing that users responded best when both were available. Clicking the menu button brought up a bottom menu. Long-pressing on an item in the collection would bring up a more detailed menu; however, we found this to be among the most difficult menu for users to find (more detailed in evaluation). | Collections are a model of their own, which contain links to other images. |
|
|
|
|
...
| A simple, non-obtrusive item adding layout was most effective for our purposes. We feared, initially, that users would find it not revealing enough and would have understanding problems; however, users seemed to pick up fairly quickly on how to add items to their collections. |
...
| ||
| | Adding a new collection has a similar unobstructive interface. This also adds for consistency across our application. |
...
| |||
| | To share a collection, we enter the sharing menu and input the name and editing privileges. This sharing menu was one of our most difficult design decisions, and the current iteration of it is thanks to input from paper and computer prototyping. Our previous design decisions were too complicated, and we found this current one simple and easy for users to use. |
|
|
...
| Searching for items in our application is as simple as clicking on filter and typing. |
...
|
Implementation
- We chose to implement this software on Android because the picture taking functionality translated best on a mobile application. We utilized the Android SDK, coding primarily in Java. The frontend was handled with Android's own XML view layer. The backend was handled with SQLite databases.
- In general, we followed a Model-View-Controller pattern, where the ContentProvider and SQLite abstracted the database information into data models, the XML layer contained the View, and the bulk of the Java code was the controller.
- One major implementation problem we encountered was simply lack of familiarity with the platform. None of our team members had ever programmed in Android before, and found the learning curve sufficiently steep enough to be problematic.
- Each item was represented as its own model. Collections contained an expanding list of items. Items could have as many tags as necessary.
...