GR4 - Paper Prototyping

Platform and Software Specifications

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.

Other specifications:

Our website also works better on newer smartphones - since they are better suited and faster for HTML5, CSS3 and Javascript.

Deep Implementation

Swiping: Swiping should work safely.  The library we chose is lightweight and so it should load all pages and swiping should be fast and efficient.

Platform independence: Since this is a mobile-web application, it works on any browser on any smartphone.

Shallow Implementation

Window resizing: Do not turn the phone sideways---the app does not resize well.

Filtering: The filtering (for vegetarian, gluten-free, nut-free, etc) will be done by the backend.  Right now, if you click on a filter there will be feedback that you clicked it, but the actual menu items will not disappear.  That's why the chicken sandwich still appears when you filter for vegetarian.  The only filter that works right now is vegetarian, for the same reason as above.

Menu items: The pictures are hard-coded in; there is no database that loads pictures.  The only menu uploaded is that for Flour Cafe.

Interdependence of libraries: Due to a new release which is still someone buggy, but enables some of our features, JQueryMobile will from time to time incorrectly display the page.  If this happens, please reload the page. JQueryMobile is still partly in beta.

Auto-complete search bar: 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)

1. Share location, and find Flour Cafe (Selecting a restaurant)
2. Apply the vegetarian filter to Flour Cafe (Filtering a restaurant)
3. 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.

Essentially, we ended up with a two-tiered menu - with the main menu showing categories as originally planned, and the second showing a more in-depth view of the dishes. Interestingly enough, with our approach, we arrived to a similar conclusion that startups such as E La Carte which are disrupting the menu space (which might somewhat be a validation of our design), though we do rely on images a bit more.

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 restricted 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.

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. Therefore, we ended up custom-coding most of our website. From our rounds of further prototyping and building, we finally created our computer prototype. We also found the concepts from lecture such as animations and colors useful as we made our aesthetic choices.

We are very excited and are anticipating crucial feedback to critically evaluate our assumptions and to help us take our design to the next level.