eatsa Technology Series

Anticipating unforeseen challenges. Engineering the solutions.

Contributed by Mark Fleschler, Software Engineer @ eatsa

Here at eatsa, we are working to revolutionize the restaurant industry. This is no small feat and brings with it a barrage of unique engineering challenges. As we work to solve a number of problems with the current process of ordering and serving food in the fast casual restaurant industry, we also are trying to create a magical experience that no other restaurant is currently delivering. If you are unfamiliar with our restaurant experience and how we solved the problem of efficient and lightning fast ordering and delivery of meals, check out this video.

One of the more visually engaging components of our restaurant ordering experience is our visual queue, the order Status Screen. The screen is located above the cubby wall in our partners’ and our restaurants. The Status Screen is a dynamic and constantly animating queue of customer names and their order status. It highlights when an order is ready and displays a cubby number guiding you to where you can pick up your meal.

The development of the Status Screen produced a number of fascinating and exceptional engineering challenges and was a hugely collaborative effort with our Design, TechOps, and DevOps teams. In order to create the most immersive and intuitive customer experience possible, initial requirements demanded the screen seamlessly animate vertical lists of names and display a rotating series of brand focused images behind it.

In addition, this would be displayed on a large video wall setup that could be comprised of at least three and up to nine displays. As you can see in the images above and below, the design went through a number of visual iterations on how our display would look, but the overall layout remains largely consistent with what you see in our restaurants.

Our Design team challenged the Software Engineering team to utilize animation as a mechanism to smoothly and seamlessly express transitions, which would help contribute to the magic experienced in our restaurants. We needed to support animation of the customer’s name when the order was marked ready, the expansion and contraction of the name area, smooth vertical movement of names across columns, and the fade transition of images in the background. This was a very daunting task for the Software Engineering team.

In addition to these design requirements, there were also the constraints relating to cost, maintenance, and scalability. After an initial trial and demo was created using a proprietary and expensive visual development platform, we chose to switch to web technologies as the platform to scale with. With web as the platform, it would be easier for different team members to work on it, give us flexibility in tooling, and make it easier to work across different hardware and operating systems. That’s right, our in-store displays are kiosk mode web pages displaying full screen.

To support animations, CSS transforms were utilized along with other technologies to handle instantaneous push updates (websockets) and simple state management and rendering of components (backbone.js and marionette.js).

Warning — I’m about to get a bit technical, but it’s hard to tell this story without doing so. What follows are a series of unique engineering challenges we faced during development of the Status Screen.

Challenge 1: Rendering the names

The first problem the final design presented was how we were going to display and animate customer names on the screen. It’s a subtle and seamless effect you may not pay attention to. You’ll notice how as a name moves up to the top of a column (as orders are fulfilled), it will seamlessly appear at the bottom of the column to the left while still present in the column to the right. Simply rendering the names singularly proved impossible to generate this effect in HTML, but was solved with redundant rendering of the entire name list for each column rendered (see illustration above). The trick was to set the vertical position via the unordered list element’s scrollTop value differently for each column, so that when a name disappears in one column it will begin to appear in another.

Challenge 2: Expanding and contracting columns

This challenge was a matter of visualizing what design wanted within the context of HTML structures. By simply rendering our list of columns all the time, we could wrap our horizontally laid out list with a viewport and a subtle border radius. This could then be made to expand and contract dynamically based on how many orders were present. In addition to this, we would also need to calculate and animate the appropriate width as the last column to display would need to be slightly thinner to leave a bit of distance between the list of names and the edge of the screen for visual effect. Thinking of the name lists as different viewports into the same list helped inform this approach.

Challenge 3: Screen layout of the display wall

This was probably the most difficult of the challenges we faced when building the Status Screen. I was under the impression that the display wall monitors were capable of 1x5 or 1x9 orientations, which would natively display odd aspect ratios. Our screen needed 6480x1280 pixels for the 1x9 setup we have at our 121 Spear restaurant location.

Unfortunately, this is not how wall displays work. They are configured to display an ultra high-def resolution (4k or 3840x2160 pixels) with the corresponding aspect ratio. As you can see in the image to the left, the displays are laid out in an unintuitive manner, with the leftmost row sitting at the bottom and the rightmost at the top. To allow for the seamless horizontal animation of the expansion and contraction of the column viewport, we would again utilize redundant rendering. We had two paths for this: render the components repeatedly on the same layout or simply render the previously built Status Screen URL redundantly over three iframes (see above illustration of iframe layout) utilizing the same viewport approach to focus only on a subset of the overall view (i.e. bottom row renders only the left third of the screen, etc). The latter solution was faster to implement, requiring no restructuring of the existing code and could be prototyped and executed in a day. After testing this out on a small UHD display we were able to validate its look on the video wall displays with success!

Challenge 4: Performance optimization

At this point we were ready to start installing the Status Screen in our stores and perform more active testing with the rest of our technology stack and finally process some orders. We were targeting very affordable hardware: an Intel NUC, to display the Status Screen. However, as we began testing on the targeted hardware, we noticed how slow and choppy the animations were, especially if dozens of orders were being added and fulfilled simultaneously. This was not surprising given how much redundant rendering was occurring, and some optimizations were made. Ultimately, that wasn’t the root of the issue — it was how we were animating, using CSS transforms. What surprised me was how much slower and less efficient they were when compared to using a dedicated javascript animation library, such as velocity.js.

After reimplementing all the animations using velocity.js, which had the added benefit of combining animation logic with the rest of the rendering logic, we were amazed to discover an order of magnitude performance improvement. Hundreds of names could now go nuts animating and fulfilling at the same time while maintaining close to the required 30fps necessary to ensure a smooth visual experience. A win win!

Challenge 5: Synchronizing background image transitions

One of the last challenges wasn’t discovered until our stores were open and using this technology. Over time, the background image transitions would slowly become out of sync. This was due to the fact that when each of the three iframes rendered, they would do so asynchronously, and the background images would only start to transition once loaded. Over time they would fall out of sync.

To solve this, we moved the logic to render and transition the background images out of each of the iframes and into the view that renders the iframes themselves. One thing that is nice when rendering a web page with iframes from the same origin is that you can descend into the iframe and manipulate its contents directly. This allowed us to detect when each iframe had finished loading, and initialize the rendering and transition logic of the background images across all the iframes simultaneously. Problem solved.

Lessons Learned

This project was a massive learning experience for myself and our whole team, and these lessons helped to streamline our processes moving forward. First and foremost, it’s important to know the limitations of your hardware setup, including how the chosen display hardware is configured and what its capabilities are. CSS transforms were much slower than previously thought and are now avoided when considering animating HTML dynamically. It’s remarkable how powerful velocity.js is as a tool in this regard. Javascript is much faster than we thought. We found that even on constrained hardware using it to handle animations felt counterintuitive, but ended up being the way to go.

Engineering at eatsa

This story is just one of many at eatsa. Across all of our products and projects, we tackle challenging and uncommon engineering problems you don’t normally encounter at traditional mobile or cloud based technology companies. We not only have to scale our mobile and cloud infrastructures, but also how we develop and maintain our restaurant technology. We also build our own hardware and need to be able to interface with it. Every day, we are faced with questions and entirely novel product ideas that require lateral thinking and creative solutions. Never a dull day here!