Retrospective: FoodBasket

1. Project Overview

As anyone already knew, at the end of the program for Bachelor’s, there would be a graduation project. FoodBasket is my, or our project. Amidst the AI spamming, with chatbots, simple integrations, we wanted to stand alone as something different, something that aims to solve a problem, other than creating a bunch of softwares that are considered “slop”, such as “studying English with the help of AI”.

My stance on AI

I believe that AI is a vital part of knowledge and development for now, as it could help aggregate information to study in one single message, other than having to get through many websites and sources. But I don’t believe that putting AI into everything would make it better, conversely, there have been a lot of criticisms and boycotts for products that “shove” AI unncessarily, as that goes against a lot of ethics and UX goals just to ride on the hype.

For example, here is the list of all 7 projects presented at the Software Engineering committee:

• IELTS Learning with AI grading
• Maths Learning App for kids with AI grading
• AI as a Service
• SAT learning with AI
• Money Managing App with AI
• Student Forums with connections recommended by AI
• Multi-tenant Restaurant Platform

There is a certain bias towards AI from the committee members, since they don’t have most practical experience anyway, but don’t you think it’s a tad bit ridiculous? Guess which project got the lowest score.

2. Results

We overall got a 90 across the board, which I considered it unfair. Many could say that it was fair that the group should get the same scores for all, but would it be fair to penalize a hard-worker unluckily paired with other lower efficient workers?

Accomplishments

Group-based accomplishments:

• We were able, as a team of students, to trudge through the software development life cycle of around 6 months to deliver a rather somewhat-finished product.
• We were able to deliver proper modules for an actual restaurant chain to adopt as starting rounds (menus creator, simple analytics, roles and permissions, orders collecting and KDS).

Team Contribution

Usually, I would pay my respects, and give proper credits to all members for all of their contributions, but this project was entirely lopsided that I could only give my highest praise to one member, where as other members would have gotten criticisms. This is the reason why I thought lazily making the team score as each member’s own would be greatly unfair.

• T. N.: Arguably the most vital member of the team. He was the only one capable of pulling off certain features and behaviors that are very important and difficult to implement, but only sounded like “fluff” and “unncessary features” to the narrow-minded committee.
  • Drag-n-drop menu builders with hierarchies and ordering.
  • Master-local architecture for records to allow broad-phase generalized changes at the operation level, but also allow tiny customizations at each branch level.
  • Synchronization with Masters to allow a method for managers to handle data-drifts. Such as in the case that the operators changed the price of some items, the branch manager had the say to whether “sync” or “keep desync” fitting their local culture and pricing.
  • 2D Floor Plan map that shows tables and its orders status, and the ability to swap between tables and orders in one click. The floor map is flexible, similar to canvas on draw.io.
• Me: I hate to boast about myself, but I took on the role that decide most of the user flows, data flows, and UI/UX designs. I also wrote design constraints, requirements and glossary of terminologies used in all design documents.
  • As expected, others didn’t read, except for T. N. which led to him creating very solid flows that needed the least testing.
  • Anything the team made had been through my hands. My contributions were not git commits, but comments on Figma files, and arguments during meetings. I might have look like a hard-head, but it was to stop the project from going down idiotic lanes that would be difficult to defend.
  • They might not have noticed it, but I have planned about what to do and what to defend from the start of the project, constantly rejecting “developer-first” approaches that put the difficulty on the users, or the “simplicity-first” mindset that has a user-experience trade-off. Every single method I said on any meetings have been criticized by myself to collect properly into one point, that I didn’t even propose the other methods which have already been rejected in my head.

By these, I think both of us deserve a 100, although I really hate putting myself on a pedestal.

Other members also contributed:

• N. L.: The backend developer. He dealt with permissions-based authorization, setting up infrastructure and managed the hosting, even though it’s simplified greatly by Railway. He also helped in part with other features, such as Restaurant’s Storefront Page, POS-level Settings, KDS, etc.
• V. K.: A fullstack developer. He dealt with single and siloed features, and owned them. Such as payment integrations, orders checking out flow, as well as orders lookup. He also helped in part with other features, similar to N.L.
• G. L.: A fullstack developer. He also dealt with single and siloed features, such as analytics, QR code generations, ordering menu displays, etc.

I could see these three getting a 90 for their work. But what I did not like that much was the last person, who should receive at most an 80 only.

• D. N.: The “project manager”.
  • Did not handle full features set at all. Over half of the commits count are merge commits.
  • All “PM” work is putting the name of the task in a Jira card, with absolutely nothing about it such as PRD, SRS, acceptance criteria, etc.
  • Wrote extremely vague SRS with AI generations, but could not lock down on constraints on what can and can not be implemented. That’s why I had to include those in all design documents.
  • Mostly did not do anything during the entire project. Only notable work is writing reports.

I don’t think I was harsh here. But there are more problems that I would go over in the next section.

3. Problems along the way

The Bumps

• Timeline Delays:

  • We missed out on the Campaigns / Coupons system, because there was not enough time to do, as well as not agreeing on how best to implement it. There were still ongoing debates between Hard-coded Coupon Types (D.N.) and Flexible Scratch-like Coupon Building (me).
  • We entirely wasted a bit over a month to implement a table-based approach for managing entities and records after debating, which then were reverted back to my Master-Layout approach at the end of month 2 of 6. Details about this here.
  • As some other members have part-time work and could only deal with the tasks allocated by the week’s end, having meetings scheduled at Monday and Thursday yielded almost no benefits for the Thursday meeting.

• Scope Creep (or what my online friends joked as featuritis):

  • More features and features are stacked on and on, without finishing one full flow, well-tested first, that it became a loop of waiting for someone to finish this, and the other to finish this so they both can be connected.
  • Features are thought of and written about in vague SRSes, before Requirements Analysis.
  • Scenarios imposed by the supervising professor were unclear, unrealistic and unfitting for such a project. Such as wanting to sacrifice efficiency for ease of adoption, which would only work for B2C situations, not B2B situations where workers are tasked to deal with such a system for hours at a time.

Risk Analysis

Also, stated in this blog post back in January, there were a lot of debates and conflicts on what to choose and go forward with.

Issue	Root Cause	Impact Level
oRPC Issues	oRPC was a somewhat new implementation that broke along the way, and could only be resolved upstream by making an issue to the maintainers and requesting a fix.	High
BetterAuth limits	BetterAuth was a generic authentication helper library, but it should work well only on generic apps. For an app that required granular permissions and role changes based on context of the POS worker, workarounds for this have to be done constantly.	High
No progress on weekdays	Only T.N, G.L, and N.L were available full-time as others had other work. So the Thursday meeting was somewhat useless at times and only served as a playup.	Medium
No CI/CD	CI/CD, automated testing and QA, hosting were not available until the last month of the project. As a product designer, I could not test the system until when push comes to shore.	High
Terrible System Design	Database and System designs were done from the point of view of normalization and deduplication first, only thinking about how to shape data flows and user flows to fit the designed structure, which constantly got rebuilt.	High
Over-reliance on AI	AI again is a great tool, but its capabilities lie with the user. T.N had constantly lamented about the level of slop that he had to fix weekly, just to keep the app running.	High
Subpar Communication	Only T.N. and G.L. really commented on the designs to ask questions about edge cases and situations that I had missed. N.L. and V.K. assumed, and D.N. didn’t do anything so no questions there.	Low
Ego	D.N. had a rather large ego and a terrible listener. He seemed to tune out any other arguments that didn’t match his method, and always seemed to feel hurt when challenged.	Low

This might have just been bias from such a nightmarish stack, but I just no longer felt any hope or any visions of me possibly integrating oRPC or BetterAuth in the future.

Debates

A compiled list of all debates throughout the project, you could skip down to the following section if it would be too long.

Split Applications vs Unified Application

	Split	Unified
Backers	Me, Prof	DN, NL
Details	One application for POS workers, one application for platform administrators, and one application for users, separated but under the same branding.	One application for everything, but separated by paths and routing.
Reasoning	Split stack, best optimized for the use cases, allow parallel development. Easier to deploy natively.	Simpler and easier to work with.

Result: Unified.

Tables vs Master-Detail

	Tables	Master-Detail
Backers	DN, Prof	Me, TN, GL
Details	Use tables with big rows, and edit/delete buttons for all entities management, from menus, items to modifiers.	Anchored master list on the left, with the middle pane changing based on context, with the right pane being the method to change data and properties.
Reasoning	Easy to use, easy to implement right.	Fast to use, but difficult to implement right. Sacrifices a low floor for a medium floor and a high ceiling.

Result: Tables at first, then pivoted to Master-Detail by month 2.

Menu Hierarchy

	Categories in Items	Categories in Menus
Backers	DN	Me, TN
Details	Items have predefined categories in items-edit page. Adding it to a menu automatically adds the category.	Items are isolated. Menus have categories as groups, and items reside in those groups freely.
Reasoning	Easy to categorize and analyze later, which category did best.	“Not everything needs to be analyzed”, and categories as grouping in menus felt natural to anyone who had used a menu before. This also allowed drag-n-drop builders to be usable.

Result: Categories in Items at first, but due to the efficiency being so terrible that it was pivoted to Categories in Menus the next week.

Modifier Grouping Structure

	An Item has Modifiers	An Item has Modifier Groups
Backers	DN, NL	Me
Details	An item has many modifiers. Each modifier belongs to a group. When displayed, the modifiers are grouped back into their group.	An item has many modifier groups. A modifier group has many modifiers.
Reasoning	The item can add or remove modifiers selectively for customization.	Easier to query, faster to structure and could also remove selectively at item-level but sacrifice adding.

Result: An Item has Modifiers at first, but due to it being too complicated and odd that others didn’t understand, pivoted to An Item has Modifier Groups.

Modifiers as Entity vs Record

	A Modifer is an Entity	A Modifier is a Record
Backers	DN, NL	Me
Details	A modifier can be, “0%” for example. And many groups can refer to this “0%” such as Salty, Spicy, or Sweetness.	A modifier is a mere tag that belongs to a group. Duplication between groups is expected.
Reasoning	De-duplication and efficiency.	Easier to reason about, and transfer that knowledge through UIs.

Result: A Modifier is an Entity at first, but again, due to it being too complicated that others didn’t fully understand, pivoted to A Modifier is a Record.

Database dictates UI or UI dictates Database

This debate, when looking back, it was wrong for both sides. The thing that dictated it should be requirements and user flows, then UI, then database.

	Database dictates UI	UI dictates Database
Backers	DN, Prof	Me
Details	The database must be designed first, then the UI must follow the outlines by the database.	The UI must be designed first, then the database must follow the outlines by the UI.
Reasoning	A UI can have anything. A database must be optimized.	A UI is the gateway for the user. The database can be anything to fit the correct case.

Result: Database dictates UI at first, but throughout the project, it started to become UI dictates Database unknowingly.

Real-time Structures

	SSE/REST	Short Polling
Backers	Me	NL
Details	Use SSE for all pub/sub-related systems and notifications. Use REST for updates.	Use short polling and REST.
Reasoning	WS may be too difficult to keep for a capstone. SSE and REST serve as a great middleground.	Easier to implement and fix.

Result: Short Polling.

Campaigns System

	Templates / Coupons / Campaigns	Campaigns
Backers	Me	DN
Details	Templates dictate the “What” to send. Coupons dictate the “When” the campaigns apply. Campaigns are the engine that tie templates and coupons together.	Campaigns contain coupons and templates, coupons have enumerated types and campaigns send templates as email to customers.
Reasoning	Provides a way to allow automated order coupons at the restaurant level, but keep printing and marketing to the marketing department and out of scope.	Includes printing and everything needed to make a campaign easy.

Result: Undecided, marked as out of scope by me at Month 5/6 and closed all PRs related.

4. Product Design Decisions

Debates aside, I will now move on to discuss what decisions I have gone through to build the following high-fidelity UIs that get implemented by the team’s engineers.

The Main Idea

The project as a whole, meant to serve the idea that in F&B managements, entities are very closely related to each other, usually including or referencing each other no fewer than dozens of times, and not isolated entities to be managed. I envisioned a native-app system that allows managers and workers to see an entity and its relationships, and immediately see that same relationship from the other entity’s view, making up the feeling that everything is an interconnective web that feels smooth to move around.

The Target Demographic

When you usually start doing certain things at university for your Computer Science courses, I’m sure you have heard your professors talk about ease of use, and ease of adoptability, or some standard layouts to make it easy to onboard. My supervising professor was the exact same.

But is that the correct way to do this?

Unlike an app or a website on a user’s phone, where you only have mere seconds to capture their interest before they leave (also called Bounce Rate). For a business app, that would not be the case as the managers and the employees would be expected to learn the system. And sometimes, people forget that these types of people, either expectedly or unexpectedly, WANT their system to be complicated IF it could make their job more efficient. That’s what I bet on, such as all jobs having a trial phase for their newcomers.

I wanted to design a system that would be extremely fast under a high-level user, but still approachable by someone who just started. The design also went with certain ideas such as Progressive Disclosure, and expected Mental Models to help guide the newcomers around the system without having to add obnoxiously intrusive interactive guides that end up irritating veteran users.

For this reason, I didn’t go full on dashboard and panels, but separated them into layouts (also more commonly knowned as Master-Detail) with panes. People may think that it’s a novel layout not everyone does, but it’s more likely that you just never noticed it. Apple apps, Gmail, Outlook, Power BI, etc. all employ variations of the layout, if you noticed.

Settings: White-label for Brand Identity

Funnily enough, I mentioned a lot that this was non-negotiable, and must not be cheaped out as it was comparatively easy to implement when compared to other features.

D.N did not understand that this was not just a simple CSS change, but vital to any B2B platforms. A tenant renting from us, should be able to customize their restaurant chains to match their brand identity. That gives us a selling point over centralized discovery systems like DoorDash or Grab, but also gives the tenants a good feeling of seeing something that felt like it was theirs.

Dine-in: Menu Displays for Diners

As you can see in the two screenshots above of the conceptual UI. I went with a very mobile-native approach, such as swipe to delete, with sheets, popups and layers on the Z axis just like any mobile native application.

A few things I thought was funny, since this is a “dine-in” system, I got a few comments from the committee, that once you heard, you could tell they were not acting in good faith, or they did not have enough knowledge to ask questions, but still thought they did which resulted in a lower-than-expected final grade:

1. Why are carts only act as local buffers? Why can’t I see what others have in their cart, what if I order duplicated? - You are sitting at the same table. You have a mouth. - Tracking guests that got in the system just by scanning a QR code, is frankly a technical hurdle that we were not willing to hoop into without proper reasoning for. As most other current systems as you experienced in real restaurants, they did not have that level of synchronization either, but only synchronized at what was confirmed and the dish entry statuses, which was implemented.
2. Why did it not have a restaurant name and description?
   • Did you forget to read the sign before you walk into the establishment?
   • I feel like this doesn’t need my reasoning.
3. Why does it only have these fish and egg icons? How would we know its allergens?
   • By that you’re eating?
   • Someone who is allergic will instantly realize what those icons are, and when tapped to view the dish’s details, each icon would be explained according to FDA Big 9.
4. Why can’t I check out from this same screen?
   • Because checking out is a money-related thing that can not be automated like that?
   • Did you honestly expect a group of students to implement something that integrate with banks, or card readers that instantly swipe away your money without confirming with restaurant staff? You would be in jail asking that, sir.

I might have been harsh, and they might not have been serious in questioning but only as some questions to see how we thought. But the others were not comfortable with me rebutting the questions, so we didn’t.

Menus Builder: Drag-n-drop Festival

I believe that GloriaFood did this part extremely well, that a menu building process is not a management process, but a creative process. Similar to a musician on a score, items and structures change extremely frequently, and that’s why I wanted to provide a canvas for managers to build menus on without friction from saving and clicking edits back and forth.

Menus also still adhered to our slogan, “Centralized Discovery, Broad-phase Controls, but Granular Customizations”. Each item added to a menu could be selectively enabled or disabled, or had its price overwritten for that specific menu.

Items and Modifiers Architecture: Master goes, where do Followers go?

Among the Details and the Properties pane, you could see labels that are normally displayed, but there are also labels that have a dashed underline, printed in italics and sometimes have an orange dot next to it. This is the markings for our (or my) best design decision so far, the Master-Local Architecture.

Before, D.N. and N.L. made a system that each item must have a “template” created at the “template” team (very weird wording for “tenant-level”, as that’s the workaround for BetterAuth). Each branch must “shadow clone” it (empty record but has a ref field) before using it in a menu for a branch. If a branch does not override a property, it would be NULL and automatically retrieved from the ref. Certain problems arise immediately: What happens if a ref was deleted? What happens to all the clones? They said they have fixed this with deep cloning (I still don’t know at this point what deep-cloning means for them)

After a while, it somehow got to that my design was followed instead of theirs, and T.N. made a huge refactor of over 10k+ lines changed pull requests over multiple weeks. Which is now:

After, I made a system that each item has a scope it belongs to. An item that belongs to the tenant as a whole is a master record, and an item that was cloned from a master record is a local record. An item that was created for a branch scope is also called a local record, just without a ‘reference’ back.

• This created very powerful isolation. A master item must use master modifiers, and never a branch modifier. A branch can use master items and master modifiers, along with its own local modifiers, but local modifiers to another branch would be impossible.
• A branch-scoped manager can never change a master record. But a tenant-scoped manager can change any record.
• Changes to a master record automatically cascade everywhere, if the branch chose to use the master record as it is without cloning.
• Changes to a master record do not cascade to referencing local records. But, these records show the aforementioned markings, such as:
  • Underlined and italics, would mean that that specific property had diverged from master record, and allow a tap to show what the master had it as, and a simple button to ‘re-sync’.
  • An orange dot would mean that the change was recent, and the branch-scoped manager had not signed off on it to whether ignore or accept the change yet.

Onto here, we can see what happens when a diff view was enabled to compare a local modifier group to its referenced master record. Changes, removals and additions are color-coded differently, and there is a way to accept one change in isolation, without having to accept other changes.

This replaced D.N.’s original idea that when there was any change, a popup would appear on the branch-scoped manager’s screen, asking for an accept or a reject for every single change. You can probably already imagine how badly this would scale without me having to spell it out.

Kitchen-Display System: Specialized for the Job

This part, however, is something I had a lot of issues with. There were certain things that were not as simple as professors and others think they were. The method I went with was not optimized by any means, but it was the best I could come up with, which showed I had a lot more to learn.

I went with a Trello-like, Jira-like approach for this section, where dishes are cards that you swipe to the right column, step by step to simulate the cooking process (New to Processing, then to either Dead or In Pass). There are more states to the dish entry, but I reckon that a kitchen should only care about these four, so I omitted the rest from this specific screen.

One thing I did not really like about this design is that, each dish, if ordered 4 copies of one dish, would create 4 cards. This was requested by me, to also cover the edge case that a family ordered 6 for example, but wanted to cancel 2 only, a bundled card would not be able to. I had ideas, such as separated at backend-level, but when at frontend-level it must be combined in some ways, such as hashing an item and its notes, etc. but ended up not implementing these fix ideas.

Now here are the usual bad-faith-looking questions from the professors:

1. Why is there so much data on one card, name, modifiers and notes? Just show the name, and only show the others when making it or something.
   • I don’t think I have to defend myself against this because the argument broke down before it even reached me. Let’s make it so chefs can’t see that the customer requested not putting shrimp in a seafood dish, as they were only allergic to shrimps and nothing else.
2. Too many cards, what if I wanted to cook 6 at once? Just batch in a count, and have the chefs click a button to decrease a count if you wanted that cancelling few use case.
   • The obvious answer would be dragging all 6 into processing. But sure, let’s add a tiny amount change button to a screen that’s used by greasy or gloved fingers.
3. Dragging seems like a hassle. Is there a better way?
   • Ironically, I can’t think of any. Both dragging and tapping are supported, but gestures are favored in limited cases like this, as you don’t have a mouse to click precisely. If you did, you would be on Orders Management, not KDS.

Tables Floor Plan

One of the most different features we have implemented.

Usually if you have seen on POS tablets, tables are usually just square blocks at very rigid locations, that employees would have to remember what and where to tap. We took this further, based on TastyIgniter, that a free-form tables map, where it could be drawn and moved around by managers. But when it comes to the waiters, they could see at a glance using color-coding which table is open, which is unavailable and which is serving. By tapping the table, the view is centered onto that table, showing the current order and a view into its entries, while also allowing taps to move seamlessly to the management of that order, still keeping up the idea of an interconnective application.

RBAC: Granular Permissions at Scale

Before, we just used concrete roles provided by BetterAuth, but I suggested that we should take after TastyIgniter for this one also, and provided a way to customize roles and its permissions. It wasn’t as powerful as I wanted it to be, but we got it to somewhere good enough.

A user can have many roles, with one role as the “main” one (just semantic, no logical meanings). A role can have many permissions. Permissions are calculated using unions (although I would have preferred them to be intersections), such as were role A not grant permission A, but role B did, the person with both roles would be able to do A. I would have wanted the opposite, that one No would cancel out millions of Yes. I thought it would provide a much safer way (better safe than sorry) for large chains managing many employees at the same time, so that it requires some level of concentration to not make a mistake for granting permissions.

Conceptual Monetization: Addons

A platform like this should at least have ways to monetize, such as GloriaFood selling additional features as addons to the tenants. We should think of the same things, whether we end up implementing them or not, as that show product ownership and future thinking, rather than just doing something for no reason.

D.N. and N.L. did not understand this, as they only considered this a project to get the degree. They also objected to any monetization ideas, and seemed to use the excuse that it was hosted on a $5 credited Railway server as a reason to not scale. But that’s the point, we have to plan for it to scale, or its forceful scaling would burst the bubble.

D.N. on the other hand was someone who believed that every service should be free. He did not want to pay for VPS hosting, domains, branding, etc. Even when the final reports and catalogues should be submitted, he didn’t want to choose any high-quality Caucher papers, but settled for Ford papers, almost diminishing 6 months of work by being petty. Luckily, the committee did not need to take hard copies, so printing was for naught, but if they did, we missed out entirely on a chance to stunt their questioning by simply paying a little bit more.

Saying it out loud might make you sigh, but when you calculate everything, from hosting, domains to printing everything, across 6 months and split between 6 members, each member only would have to pay an equivalence of 10 large milk tea cups ONE TIME (not even each month).

Coupons and Campaigns: Unimplemented Coupon-building Engine

A scraped feature. Coupons seem very simple on first look, but when you analyze them just for a second, you start to see why a lot of platforms choose to restrict coupons a lot (such as Shopee only allowing you to create coupons that discount over a total price, and nothing more). D.N. did not understand this, and only started writing coupons as having only Buy One Get One, Discount Percent and Discount Fixed.

Certain questions would instantly stump that system, and any requests from tenants for other types of coupons would start to crack that system instantly:

1. Can I make it so it’s buy two get one?
2. Can I make it so it’s discount % if it’s this but maximum only this fixed amount?
3. Can I make it so coupons can only be used on weekdays?
4. Can I make it so coupons can only be used by this set of customers?
5. Can I make it so these are employee discounts and only for those added by employees?

These are nowhere near far-fetched situations, yet the system already couldn’t handle it. This is why as a service provider for business, we would have to be able to cover any cases that a business needs, and if we couldn’t, we must have a system that is capable of extending there easily. This is what made me come to the idea that a drag-and-drop Scratch-like rule-building interface, while using AST under the hood would be the way to do it, as any new requests could be added as a block.

Due to the lack of talent (only T.N. would be able to implement this, realistically), and lack of time on fully analyzing every case, we agreed to drop this feature.

5. Lessons Learned

1. Keep QAs during the process.
   • Problem: Various bugs during the entire process that should have been caught with a pair of eyes slipped by until the last month.
   • Possible Solution: Always have a dedicated tester, for example, I could have filled such a role, for all PRs to main.
2. Do not use bleeding-edge technology for enterprises.
   • Problem: oRPC and BetterAuth kept hitting limits and problems, leading to having to create tickets and PRs upstream to fix the libraries.
   • Possible Solution: Use boring technology, that is for sure battle-tested and won’t undergo breaking changes in the next 6 months.
3. Audit Log at first.
   • Problem: Issues that arise without being able to easily trace back, due to not having audit logs and gates at the start, and implementing them later was too much work.
   • Possible Solution: Implement logging from the very first thing, even the simplest logging to file solution.

6. Ending Note

There were a lot of road bumps, slopes and hills along the way, but like the feeling of finishing an exam, whether you did well or not, you felt much more comfortable and easier.

I was not happy with a lot of decisions made, but a lot of my decisions stayed, which contributed to me as a decent designer, and that TN was able to pull all the big guns to make something that should be boasted about in later interviews. If we stayed with tables, TN might have never discovered he could build such systems, that product companies like Canvas would headhunt for. I might not be able to go far in the field, but by pushing myself to the limits, I also pushed TN past his limits, and that might be his ticket to climb much further than I ever may.

Kinomoto Sakura