...
Our project is an HTML5 mobile-web app that loads on a browser. It can render on any smartphone browser. We checked it on the Android; however, the iPhone (from what we tested) renders a better design experience. Our website also works better on newer smartphones - since they are better suited and faster for HTML5, CSS3 and Javascript.
Other specifications
...
Do not turn the phone sideways---the app does not resize well.
...
We have not implemented searching for restaurants yet because that too will require an extensive back-end.
How to start the prototype
...
Load the internet on your smartphone and visit: http://aidsorc.org/compprot
When it loads, choose Flour Cafe to explore their menu. Because only the lunch options would be affected by the vegetarian tag, the feedback for filtering for vegetarian only appears on the lunch page (so don't be alarmed if you don't see any feedback on the dessert page, for example).
Tasks (from GR2)
- Share location, and find Flour Cafe (Selecting a restaurant)
- Apply the vegetarian filter to Flour Cafe (Filtering a restaurant)
- Explore the Lunch menu at Flour cafe and find the details on the Portabello Mushroom burger (Viewing the menu)
Reflections
...
This project imposed a whole new set of constraints on our original paper prototype. We did an additional round of testing on our paper prototype and found that people were open to several layouts. We had concluded after our second iteration of paper prototyping that people would want multiple food icons on the top of the screen and entree details in the center. But in a third iteration of paper prototyping, we just had one huge picture which would take up the entire screen, and people liked that as well. They especially liked the idea of having big pictures so they could see the details of the menu itemsdish. We ultimately decided to go with a combination of the second option two because we felt it would be the best use of our screen real estate. The original icons would have clouded up the screen, and one of the main purposes of our app is to give customers a realistic view of what they are eating. We want this picture to be as large as possible, and because mobile screens are so small, we decide to make this picture the main stage. However, we also wanted to include ingredients/price.
In terms of the filtering, we also found that our tag option limited people somewhat. People often need a larger tag or area to press in order to interact with the phone. Given that screen real-estate is restricted, and that filters might crowd out the viewing of the menu, we shifted the filters to the main menu page. Furthermore, we had to significant work to customize a different scrolling approach to HTML5 mobile-based web. Given that smaller drag and drop filters might not work (on small screens mainly), and that the checklist approach involved additional dialogs with little feedback, we felt that a scroll bar with the filters bolded was a good way to prototype the filter.
We are very excited and are anticipating crucial feedback to help us take our design to the next level, and critically evaluate our assumptions. It was a learning experience to prototype on mobile because we were dealing with a smaller screen and libraries we were not particularly familiar with. Though it was uncharted territory at first, we felt like we gained a lot from just being able to manipulate various hand motions, and try out various approaches. We tried prototype builders such as Codiqa and proto.io; however, we felt they were too limited. From our rounds of further prototyping and building, we finally created our computer prototype.