Our mobile-web application can be accessed at http://aidsorc.org/final_813/
|
GPS detection
Before our paper prototype, we had three ideas for restaurant selection: GPS detection, QR code reader, or using a search bar. We decided to go with the GPS detector for several reasons. First of all, we felt it would be the most efficient for users. With a QR code reader the user has to exactly line up their camera with the code, and with a search bar the user has to manually enter the name of their restaurant. But since we use GPS, the user simply has to load our page on their browser and a list of restaurants is immediately pulled up, with the closest one listed at the top. The advantage to the search bar, though, was that you could search a restaurant’s menu from home. But we ultimately decided that the purpose of our application was not to serve as an online menu, removed from the restaurant, but rather to replace the paper menu in the restaurant. So, the user would only be using the app when they are actually at the restaurant, so GPS fit perfectly with our goals.
List of nearby restaurants
The reason we give multiple restaurant options rather than just one is in case multiple restaurants are close together and the GPS is glitchy--we didn’t want the app to accidentally load the wrong menu and confuse the user. |
|
|
Checkbox filters
For our final iteration, we opted for the simple checkbox filters. Checkboxes are a familiar interface used for selecting a few things out of a larger list (i.e. filtering). This filtering technique is much more intuitive than our design for the heuristic evaluation, which consisted of a scrollbar at the bottom of the page where you would highlight the filters you wished to select. We had originally taken this risk because we felt it would be more interesting and innovative, but it ended up being difficult to implement and so it didn’t look very nice. Users didn’t realize they were supposed to click on the names of the filters (such as “vegetarian”), while when there are checkboxes users know exactly what to do.
Location of checkbox filters
We moved the filters from inside the gallery to outside the gallery. We believe that a user visiting a restaurant isn’t going to choose “vegetarian” for one dish and not for all of them. Before a user even decides whether they want a sandwich or a pizza, they decide that they want vegetarian. So, we moved the filters to the outside of the gallery, where this mental decision actually takes place. We justified this decision by knowing that the app is for the individual user, not a group, and the average individual user will be consistent in their dietary restrictions for all types of entrees.
Checkbox filters as an alert
We made the checkbox filters an alert message. Because we are using mobile, we quickly realized that screen space economizing is critical. So, we have a button “Filters” in the header which doesn’t take up any extra room, and when clicked it opens up the filter menu as a pop-up box. We decided that it wouldn’t matter that the filters pop-up would cover up the other menu items, because the filtering task and the entree selection task are independent. In other words, the user doesn’t need to know that a given restaurant has “Sandwiches”, “Pizza”, and “Pasta” to know that he wants “Nut-free”. We also discussed putting the checkboxes on a separate page entirely, which would be located between the restaurant selection page and the category selection page. But because mobile web pages are slow to load to begin with, we didn’t want to have the user to have to navigate through one extra page. An alert box would be much faster.
Apply button
We added an apply button to the bottom of our filters alert to make it explicit to the user how to apply filters. We also added an “x” at the top for safety reasons--a user who accidentally clicked something could just close the filters menu without having to undo all of their changes manually. |
 |
|
List of names
We simply listed the names of the categories (“Sandwiches”, “Desserts”, etc.) in our final iteration. We felt this was much cleaner than any other option. In our iteration for the heuristic evaluation, we included example pictures of a sandwich or dessert. This was a poor use of screen space. The user was unable to see all of the categories at the same time because the pictures were so large, so he would have to scroll down. Also, the combination of pictures and category names in this original iteration was too hectic--it was difficult to visually group pictures with their corresponding name. We knew that we could add more white space between category names, but this would just take up more screen space. We decided to nix it and go with the simplest option. |
 |
|
Swipe gallery
We opted for a menu-viewing tool which would have the look and feel of a gallery. We wanted large pictures so the user wouldn’t have to squint, so we quickly threw away the idea of smaller icons. Swiping would allow the user to see all of the pictures full screen without having to reload a new page every time. This would allow the user to quickly scan the whole menu and stop when he saw something that interested him.
Item details at the bottom page
We provided entree details (name, price, and description) at the bottom of the screen so the user wouldn’t have to search for more information about the item. In one of our paper prototypes, we had a full screen picture, and would only open an alert-box containing the item details when the user clicked on the picture. We realized that users wouldn’t realize how to access these details, or even that we provided them at all. We also realized that we could it wasn’t necessary to make the picture that large. So we combined the two tools and put the item details right beneath the picture.
Navigation
We used a navigation bar at the top with dots signifying how many entree items were in a given category, and which item the user was currently viewing. This gave the user a better sense of how many options they had for a given category. We originally had “+” and “-” buttons which the user could click to go to the next page, but we removed these. They didn’t add anything to the user’s experience, and served the same functionality as swiping (but ended up being much slower), so they were unnecessary.
Icons in header
We added icons in the header of the gallery pages to allow the user to move to different parts of the application without needing to use the browser buttons. These icons are all familiar, and were added to increase the user’s efficiency. |
 |
|
Reasons for adding
We added this functionality for our final iteration. A shopping cart would allow a user to select a few items from a variety of different categories, look at them all at once, and narrow down his options to a final order. We had discussed having a shopping cart in our very first sketches, but had originally left it out. We had felt that it was a separate task from filtering and we wanted to focus on that because we had believed that a user’s ability to filter for “vegetarian” was most important. After repeated requests for a shopping cart feature, in both the paper prototype and the heuristic evaluation, we finally realized that a cart would be an equally important filtering tool. Our feature allows users to add to the shopping cart by pressing the “+” in the upper right-hand corner of the picture in the gallery. They can remove items from the shopping cart by pressing the “” in the upper right-hand corner. Users are familiar with this method of adding and removing items. This feature allows for side-by-side comparisons, which makes the menu experience much more efficient. Even paper menus do not offer this type of direct side-by-side comparison-you need to keep one finger on one choice and another finger on another choice when deciding what to order. The shopping cart effectually memorizes the user’s choices for him.
Feedback upon clicking “X” or “+”
When you add an item to the cart, the gallery automatically moves to the next page. We deliberated on this action for some time. We wanted to give the user feedback that they had successfully pressed the “+” icon. First, we used an alert, but we believed that having an alert pop up every time you added to the cart would be inefficient. We opted for moving to the next page because we felt this would both alert the user that they had successfully added to the cart, and save them the extra stroke of swiping to the next item. We realized that this is not typical feedback and so we were curious how users would react. When removing an item from inside the cart, the application moves to the previous item and updates the number of dots in the navigation. This is a more familiar response.
Extensibility
The shopping cart is an optional feature. It enhances the user experience by allowing him to compare multiple selections side-by-side, but in no way limits any other part of the experience or obligates the customer to use it. This was a critical design decision because we wanted to keep the app simple and didn’t want to confuse any users that might not be as tech-savvy, or otherwise might not want to use the cart. |
 |
After deciding to use GPS to fuel the technology behind selecting a restaurant, the implementation was simple. JQuery mobile and most mobile browsers included for stellar location-based functionality. A few lines of code allowed the site to retrieve its viewer’s location, either through network on the desktop, or full-on GPS on mobile browsers. After retrieving the latitude and longitude of the user, the site used the ‘haversine’ formula to calculate the distance from the user to each restaurant, and displayed them as options to users.
Originally we had planned for the task to have an additional search bar, as a failsafe in case the GPS functionality failed. Instead of a search/filter option, we had the app display all of the restaurants in alphabetical order instead of in order of closest to user location. Implementing a filter bar with our dynamic placement of restaurants seemed excessive and nonessential to the scope of the project, despite its blow to the apps efficiency.
The first iteration of our filtering system was to be just like our designs: a scrollable bar at the bottom of each menu screen with draggable and tappable filters. Implementing this proved difficult, however. We first learned that the draggable elements would be near impossible with the app living on a mobile browser, as dragging on mobile web is reserved for scrolling on the page. We moved towards having the filters each be a simple toggle button. This implementation proved tedious and ill-suited to the rest of the app design-wise. While the rest of the menu pages proved to move smoothly, the filters overlay was slow and didn’t lend itself to the app’s efficiency.
Following a reevaluation of our design usability, we decided to redesign the filter overlay as a dialog box optionally opened while viewing each restaurant’s menu. The reasoning behind this change was that those users with dietary restrictions (such as Vegetarian or Nut-allergenic) would want to apply those filters regardless of any transient factors like taste or time of day. Our filters were based on more permanent restrictions and so we saved these on a per-session basis, which make the menu-viewing experience more seamless.
We had a lot of difficulty getting the swiping gallery of images to work. We first used the javascript library “swipeview.js”, which advertised as being lightweight and quick. One issue we ran into immediately was that swipeview wasn’t compatible with jquerymobile, which we were using on other pages of our app. We were concerned that this would affect our app’s consistent presentation, but we just made a header using css which had the same coloring as that created by jquerymobile.
We ran into a bigger problem with swipeview when we worked on adapting our app to a change in the phone’s orientation. After spending many days trying to modify our css file to adapt the app to an orientation change, we decided to check out the swipeview demo. It turned out that even the demo of swipeview was buggy when the phone switched from portrait to landscape view. So we began to explore new swiping libraries, and found swipejs, whose demo worked with a changing orientation. After rewriting the entire page in swipejs, we then realized why swipeview had advertised its lightweight structure: swipejs was extremely slow and our pictures did not load. Ultimately, we chose to go with our swipeview version. Even though it limits usability in that the user can’t switch the phone’s orientation without refreshing the page, it was far better than the other option of the images not loading. Even swipeview is not perfect though--it still can take time to load images. But from a feedback standpoint, it is preferable to swipejs, because while swipejs freezes, swipeview appears to be loading.
The contents of the shopping cart are stored in the backend, but we added some feedback features in the front-end to avoid some safety problems we discovered with edge cases (such as no items or only 1 item in the shopping cart). Essentially, swipeview is not compatible with fewer than 2 items (which was part of their specs). But since a shopping cart necessarily has to be functional with 0 or 1 items, we needed a way to combat this. We wrote a separate javascript that would handle only 1 item in the cart, attempting to simply pin it down and not allow swiping at all. Unfortunately, swipeview did not like this so it ended up being buggy. To handle 0 items in the cart, we originally emptied the gallery and simply printed “No items to display.” But after we emptied the gallery, swipeview did not allow us to re-add items to the cart. We ultimately decided that if the user clicked on the cart and it was empty, we would just link him back to the gallery page. We realize this is not the appropriate feedback, and was definitely a usability sacrifice for our implementation.