...
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. Providing the distance with the restaurant name is good feedback, and helps in terms of both efficiency and learnability.
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 backend implementation was done via Ruby on Rails. We chose Ruby on Rails because RoR is fairly easy to setup and run. However, perhaps choosing a more light-weight framework such as Flask might have decreased loading time and made the app more efficient. Furthermore, the menu loading is highly dependent on database queries. Currently our caching mechanism via Ruby on Rails is not as efficient as it could be. The filter queries partly use Redis (an open-source, networked, in-memory, key-value data store); however, they also make heavy use of the SQLite database - which slows down loading time. Perhaps, shifting this entirely to Redis would decrease loading time, and bettered the filtering operation (thus again making the app more efficient).
...
We chose the 18-24 demographic because it is generally reflective of the early adopters of our app in the user population. Most menu apps in the ordering and viewing food category often gain the 18-24 category as their first user base because college students/youth tend to be both the most volatile and trendy population to easily transition open to new technologies and follow trends, thus easily adopting and transitioning to new norms, eg: ordering online, checking Yelp reviews before going to a restaurant, etc and . They also generally tend to eat outside a fair amount. In fact, startups such as GrubHub in the food and menu space gained critical mass by first launching to college students, and then scaling. Thus, we felt the 18-24 population was our initial best bet in terms of accurately testing our app and receiving the most valuable feedback.
...
If this was a no and the smartphone was not compatible, we asked another individual to partake in the test. We felt that only natural users of that particular smartphone should be able to participate in the test because not having a compatible smartphone introduce introduces unaccounted for variables in terms of learnability, safety and efficiency that are based on the intersection between smartphone compatibility and the HTML web HTML5 mobile app.
Test design and choices
...
Task 2: You are a vegetarian and realize you are allergic to nuts. Apply filters to the menu so that you only see vegetarian and nut-free items.
Task 3: Go to the individual menu and browse through the items.
...
Applying filters provides no feedback on which filters are on or off. Users also want to know if filters were applied successfully after they are applied.
Severity: Catastrophic
Fix: This can be fixed by assigning relevant icons to each type of filter in the headbar that perhaps have the first letter of the filter applied and in some small frame. Furthermore, anytime a filter is applied, some animation such as a progress bar stating filters are being applied with a progress bar might help show that filters have been appliedprovide further feedback.
Adding items to cart requires different feedback. Though users suspected sliding to the next item meant the item was added to cart, they weren’t 100% sure.
Severity: Major
Fix: A better feedback that many users both suggested, and that we came up with was adding some bubble showing the number of items in the cart at any point in time, and also highlighting the cart button anytime an item is added.
Remove the ‘+” sign from an item after it has been added to cart. Adding items the same item additional times to the cart really does not make a difference because only one instance of the item can be added.
Severity: Minor
Fix: This is simply a Javascript code issue which can be quickly fixed with an if statement that removes the + sign from the upper right corner once that item has been added once.
Remove swiping when only one item is present.
Severity: Cosmetic
Fix: Easily do-able. Again this is a simple Javascript issue that enables swipe. swipeview.js . This is an edge-case that can be easily handled.disabled for this edgecase.
Too many page changes/reloads required to go back to the filter if a filter needs to be added or removed.
Severity: Minor
Fix: This requires finding a place to put the filters tag button and editing the code to allow changes to happen to the menu dynamically while browsing . However, (once a filter is applied). One way is that the home icon can perhaps be shifted to the right and the Filters dialog button can be added to the menu insteadtop menu on the left during viewing/swiping.
Reflection
We learned a lot over the course of the design process. Most of our general intuitions were right. In the beginning, we predicted that it was best to make more risky design bets - because the cost for testing was slow. This proved to be true. We were able to quickly determine what worked and what did not, and for a low-cost. Also, this allowed us to move to a consensus pretty quickly. We also learned an obvious, yet important truth out of this: “keep it simple.” Though we tried a lot of design risks, in the beginning - we almost ended up using none of them past the paper prototype stage, resorting to a simpler step at each stage.
...