Inspiration
When I was traveling in Taiwan two summers ago, I found that many restaurants did not use the typical 1:1 server to customer experience for dining in. Instead, they employed sheets of paper which customers would use to mark their orders, which would be picked up by any server, brought to the back for food preparation, and then served when it was ready. At any point, the customer could add to their sheet and then these additional items would be added to their order and subsequently served. When the customer was ready to pay the bill, they wouldn't need to wait for the server to come around with the check. They would head towards the exit, where a manager would be sitting next to a cash register, ready to help them complete their meal checkout flow.
After this dining experience, I had been intrigued by the possibility of integrating it with a POS system such as Square. However, with today's COVID-caused "new normal", I found additional pain points that needed to be addressed in a solution such as this one. These are:
- The wastefulness and environmental damage of paper menus.
- Waiters and waitresses are currently stretched thin as a result of additional sanitation tasks; they are also put at increased risk of COVID transmission as they interact with more and more customers.
- While many restaurants have adopted online pickup/delivery ordering flows with contactless payment options, most dine-in experiences still lack this feature, putting both the customer and restaurant employees at risk of COVID-transmission.
What it does
A mobile-optimized dine-in experience. Customers can view the menu in an accessible and optimized format for their mobile phones, order items with variations and modifiers as defined in the Square CatalogAPI (all information is drawn from there), call the waiter/waitress to the table when they need human support, check on the progress of their order throughout their meal, and checkout with either an in-person or contactless payment solution (via Square).
How I built it
When customers view the menu, it is blazingly fast as a result of Gatsby.js and Square's CatalogAPI - the catalog items are preloaded during the build stage so that no time is wasted in calling the Square CatalogAPI for each user to visit the page.
Challenges I ran into
Building the logic for any number of variations and modifiers on items was quite difficult. While Gatsby.js' GraphQL interface certainly helped with retrieving the data from Square's Catalog, being able to handle a variable number of item options (which combine together to form unique variations) as well as both single and multiple select modifiers was quite a challenge. However, I'm proud of the fact that I was able to finally solve these challenges with some (slightly messy) code which I hope to improve upon at a later date.
Accomplishments that I'm proud of
As previously mentioned, solving the algorithmic challenges associated with handling variations and modifiers on items, as that information was necessary for adding items (with their variations and modifiers) to an order. Another accomplishment was the look and feel of the application. In the past I've built web applications, but I've always targeted laptop and computer screens. This was a unique challenge in that my target audience would be on mobile devices, and so optimizing for that experience was interesting. I think in the end, I not only learned more about how to wield CSS but also how to really consider mobile applications from a user experience perspective. For example, there are no hover events (something which I love to use in typical web applications) and it is easy to misinterpret a scroll for a click on mobile. Both of these challenges are things that I had to overcome with my application.
What I learned
Three major things:
- How to navigate Square's API. At first it was very confusing due to its nested nature, but as I used it more and more, things started to make a lot of logical sense and as I accepted the patterns they employed, it became easier to enjoy using it. I will say, Square's API would be a great candidate for a GraphQL API - with GatsbyJS I was able to try this out a little with the excellent
gatsby-source-apiserverplugin. - I learned to love and understand the importance of the JAMstack. The performance and speed of this app was incredible, and is also very necessary given that its competition (a paper menu) would never have any loading time. With Gatsby.js, this app was able to give paper menus a run for its money. Additionally, I learned how to leverage both dynamic and static content in a JAMstack application, as some information (such as the order information) had to be dynamically populated from the server.
- Finally, I really enjoyed this project on a conceptual level. I had originally conceived this idea back in Taiwan during the summer of 2018, and while there I frequently ate out and experienced their unique ordering flow on a daily basis. Upon returning to the US, I wanted to build this out but didn't have enough technical knowhow to do so at the time, and the hypotheses behind adjusting the project weren't validated. However, as a result of COVID, new pain points in the dine-in experience emerged which I saw could be addressed with slight modifications to the ordering flow I had originally envisioned. Thus, building out this application was not just technical but also conceptual, as I had to put myself in the shoes of the customer and the small business owners to determine if the solution I was proposing would truly address the pain points they faced.
What's next for Dineline
There were three main things that I didn't get to address in this project, but will be important moving forward for Dineline:
- Currently, only a single customer at a table can order for everyone. This is because a new order would be created if someone else at the table tries to place an order. Clearly, this is not the best solution due to the potential for COVID-transmission, as well as the general user experience that most people are used to (typically in a restaurant you are given your own menu and don't need to pass one around). However, this limitation is a little tough to solve as it would require some real-time updates to be pushed to the applications of all members of the table in order to keep the data in sync.
- This application is currently only a customer-facing application. While information propagates to the Seller's actual Square account, I believe that a vendor-side application or extension to Square's POS would be necessary in order to handle adjusting the additional order states which the application utilizes (through the metadata field of the Order object). This is because Square's current order states only include "OPEN", "COMPLETED", and "CANCELED", which is too limited for this application.
- Finally, Square Checkout needs to be fully implemented to fulfill the third pain point previously mentioned, which was that of contactless payments for dine-in customers.
Log in or sign up for Devpost to join the conversation.