Pelico: A Technical Look at Project Dashboard
This week, @hen_dubz & I have been cooking up a storm on a project for Pelico - the lovely chaps who've been coming to see us for a while now to talk about their startup business delivering fresh and wholesome food to the people of Bristol. Based out of UWE, Pelico take next- and same-day orders for lunch and dinner, delivering awesome food straight to your desk.
The task was to create a suite of dashboards to help Alex & Leyth manage the frenetic pace of preparing and shipping food orders. This post will take a look at the solution we built from a purely technical point of view, but you can expect a fuller analysis and story from us in the coming weeks.
Concept / Brief
We go the impression that the kitchens were a bit like this during service:
Whereas we wanted to help them be a bit more like this:
Pelico are using Shopify for their order fulfillment, online store and general order tracking. They’re also using whiteboards and handwritten labels to manage the orders after they arrive in Shopify. All in all, a bit frenetic, by their own admission. How could we use our technical prowess get them from sad Damon to happy Damon?
Simon & Jack suggested that we create dedicated dashboards for each facet of the operation:
- Ops manager
These dashboards would take the order information stored in Pelico’s Shopify account, parse it and display in the most appropriate way for dashboard type. We would store ‘meta’ information about each order on the new platform itself to avoid changing the information on Shopify itself where possible. This approach would let us be quite fluid with our handling of the orders themselves.
- Have an order status (received / prepared / packed / assigned / dispatched)
- Be assigned to couriers for delivery
- Be marked as ‘dispatched’
- Be updated as ‘fulfilled’ on Shopify
- Be archived after delivery
With this brief and some quick wireframes, Henry & I were put to work, with a tight deadline of only 4 working days to get a prototype shipped.
Our key goals were:
- Build & provision the platform and hosting environment
- Link the dashboards to Shopify
- Define business logic for progressing orders
- Enhance UI to execute business logic
- Deploy & Demo
And of course iterate through steps 3-5 after feedback from Pelico.
1. The Stack
To build the app we used Meteor 188.8.131.52 with our usual suite of packages for accounts and roles handing, plus Bootstrap for the UI and grid system. The app is hosted using Meteor Galaxy and MongoDB Atlas.
Galaxy was chosen for ease of deployment - for most projects we’d use our own awesome Opsworks stack (crafted in-house), but unless the Pelico Dash needs to scale up dramatically a Galaxy container will suffice. MongoDB Atlas’s recently announced free tier is currently providing us with an enterprise-grade replica set and a ton of monitoring options and metrics to boot.
In the first build (that we would show to Pelico before iterating on feedback) we concentrated on demonstrating the connection between orders generated on the Shopify shop and the feed coming into the app. We used Datatables to display order data, which gave us a quick win on sorting & searching the feed.
2. Shopify Integration
First, we created a dummy shopify shop for testing and copied the live Pelico shop’s theme. We also extracted all their order and product data for analysis. From this information we were able to get a pretty good picture of where (& how) relevant data was being stored.
As for pulling out order information from the dummy shop, Shopify has a dope API which meant we could extract and manipulate the data reasonably easily.
Setting this up though, is maddening for the unwary:
- Create a shopify account & a shop (naturally)
- Go to https://<YOURSHOP>.myshopify.com/admin/apps/private
- Generate API credentials, use in your app
Step 2 nearly caused Chris to retire and move to Nepal; Shopify have done their best to hide the API key generation options away in the basement of your account section - make sure you copy the link above and sub in your shop name!
With order data flowing in from our dummy Shopify account we could now start working on the logic for managing these orders on the platform.
- New orders should be displayed immediately on the kitchen dashboard, ranked by delivery window
- Orders marked as ‘cooked’ should be removed from the kitchen dashboard
- Orders can be assigned to couriers at any point
- Orders can not be dispatched until cooked
And so on. Using Meteor makes this stage of the build process an absolute joy, not least because the framework gives you all the tools you need (isomorphic ES6, websockets, npm packages) and then crucially, gets out of the way (hot code push, ease of testing with Chimp.js).
By now we’d started to work out the peculiarities of pulling data from Shopify and how to cache the data appropriately to avoid swamping Shopify’s API with requests.
The schema above broadly demonstrates our thinking here. Every 10 seconds or so our application would poll the Shopify APIs for order updates. We wanted to do something clever with Shopify’s webhooks, but didn’t have the time to investigate this.
We added a little bit of secret sauce to the project - we’ve worked a lot with Twilio in the past, a service we can leverage to send text messages. We had the perfect opportunity to use this experience here, adding a simple function to the platform to text the customer when their order is marked as dispatched. Rather than bring in Twilio’s (admittedly good) npm package, we opted to use their awesome RESTful API instead.
Using Bootstrap for the UI meant we could rapidly develop the dashboards into living, breathing screens. Being able to lean on battle-test, responsive components makes a world of difference when you’re rapidly prototyping to a tight clock. We used a light sprinkling of icons and modals to add a little visual seasoning.
5. First demo, iteration & refinement
We demoed our initial burrito to the guys from Pelico to get some early feedback, and they were very impressed with how far we’d got in such little time. Demonstrating an end-to-end order flowing from the demo shop, to the kitchen, being assigned to a courier and a text message arriving on Chris’s phone was pretty cool.
The next task was to layer on some basic authentication, user accounts and roles to manage access to the system, as well as polish the UI and develop the business logic a little further.
In the last day before our time on the project was up, Henry took the Couriers dashboard by the horns and wrestled it into submission - we knew that the couriers would be primarily viewing their assigned orders on their mobile devices. Defining user journeys and assertions like these were invaluable in letting us craft the UX for the platform. Meanwhile Chris finished off the user roles logic and finalised the correct configuration of ‘fulfilling’ orders via an API call back to Shopify.
That’s a wrap
What’s next? Pelico have just started up their operations after a short break to rebrand and review, and are clamouring to get the dashboards served up to the operations staff. All we need to do is point the dashboards at Pelico’s live shop and watch the orders fly in!
There’s no doubt that we can push the functionality and complexity of this project further, but for a first course we’re pretty happy with the progress we’ve made.
Until next time,
Chris & Henry