The Pizza Ordering Chatbot is a static browser application built as a direct translation of a Python console ordering program. The original project used terminal prompts to walk a user through a pizza order and calculate the final cost. The browser version keeps that same step-by-step conversational structure, expands it to support multi-pizza orders, and presents the logic through a chat-style interface that works on GitHub Pages with no backend required.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/apursley2012/alex-pizza-assistant/llms.txt
Use this file to discover all available pages before exploring further.
This case study was written by the project author, Alysha Pursley, as part of the original project documentation. It covers the key design decisions, logic structure, and areas identified for future improvement.
Project Overview
The app introduces a virtual assistant named Alex who guides the customer through a complete pizza order. Alex collects all required details one question at a time, validates every response before advancing, calculates the order total using fixed pricing values, and displays a live receipt panel that updates throughout the conversation. The entire app runs in the browser using plain HTML, CSS, and vanilla JavaScript — no frameworks, no build tools, no server. The project was designed to demonstrate beginner programming concepts in a context that feels more interactive than a terminal window, while remaining simple enough to read and understand as a learning example.What the Chatbot Collects
Alex gathers the following information during an order session:Toppings
Free-text entry. Multiple toppings can be separated by spaces. Entering
cheese is the expected input for a plain pizza.Carry out or delivery
Determines whether a delivery fee applies and affects the cash payment message. Collected once after the pizza loop.
Add another pizza?
A yes/no prompt after each pizza is confirmed. If yes, the pizza questions repeat and the new pizza is added to the order.
Card details (card orders only)
Card number, expiration date in
MM/YY format, and a 3 or 4 digit security code. All three are validated before showing the simulated approval.Input Validation Strategy
The original Python version usedwhile loops to keep asking for a value until the user entered something the program could use. The browser version applies the same idea through client-side validation: each step has a validate function, and if the response does not pass, an error message is shown inline and the app does not advance.
Every validated field, its rule, and the error shown on failure:
| Field | Validation Rule | Error Message |
|---|---|---|
| Name | Cannot be blank | Name cannot be blank. |
| Pizza size | Must be small, medium, or large | Please enter small, medium, or large. |
| Toppings | Cannot be blank | Toppings cannot be blank. If you do not want any toppings, simply enter cheese. |
| Crust type | Cannot be blank | Crust type cannot be blank. |
| Quantity | Whole number greater than zero | Please enter a numeric value greater than 0. |
| Add another | yes, y, no, or n | Please enter yes or no. |
| Order method | carry out, carryout, pickup, or delivery | Please enter carry out or delivery. |
| Payment method | cash, card, credit, or debit | Please enter cash or card. |
| Card number | 13–19 digits (spaces and dashes stripped) | Please enter a card number using 13 to 19 digits. |
| Expiration date | MM/YY format | Please enter the expiration date as MM/YY. |
| Security code | 3 or 4 digits | Please enter a 3 or 4 digit security code. |
| Tip amount | Valid dollar amount such as 3, 3.50, or 0 | Please enter a valid tip amount, like 3, 3.50, or 0. |
carryout, pick up, and pickup are all mapped to carry out. credit, debit, credit card, and debit card are all mapped to card. y and yes are both treated as yes.
Order Flow Logic
The central logic change from the original Python version is the multi-pizza loop. Rather than ending after one pizza, the app keeps collecting pizzas until the customer says no to theaddAnother prompt.
The flow for each pizza is:
- Collect size, toppings, crust type, and quantity
- Push the completed pizza object into the
order.pizzasarray - Ask whether the customer wants to add another pizza
- If yes — reset the temporary pizza fields and return to step 1
- If no — advance to the order method question
order.method value.
Payment Logic
After the order method is confirmed, Alex asks for a payment method. The checkout flow branches from that point: Cash — delivery Alex tells the customer that the driver will collect payment upon delivery. The checkout is complete after this message. Cash — carry out Alex tells the customer to pay when picking up the order. The checkout is complete after this message. Card — any order type Alex collects three fields in sequence:- Card number (13–19 digits)
- Expiration date (
MM/YY) - Security code (3 or 4 digits)
Pricing Logic
All pricing is calculated from fixed values defined in the app. The full formula is:| Item | Value |
|---|---|
| Small pizza | $8.99 |
| Medium pizza | $14.99 |
| Large pizza | $17.99 |
| Delivery fee | $5.00 |
| Sales tax | 10% (applied to pizza subtotal only) |
| Coupon threshold | $50.00 |
subtotal × 0.1. The delivery fee is only added when order.method is "delivery". The tip is only collected for delivery orders paid by card, and is added directly to the total.
After the final total is calculated, the app checks whether it meets the coupon threshold. Orders at or above 10 off coupon for the next order. Orders below that amount are shown a message noting that the coupon is available for orders over $50.
Static App Design
The interface is split into two main areas that update together as the conversation progresses:- Chat feed — Alex’s prompts and the customer’s replies appear as styled message bubbles. The conversation builds up in the feed so the full context of the order session is always visible.
- Receipt panel — a live sidebar that updates after each confirmed answer. It shows the customer name, order method, payment method, and a running breakdown of subtotal, tax, delivery fee, tip, and total. Each completed pizza is listed as a separate line item with its own size, toppings, crust, unit price, and item total.
Future Improvements
Several improvements were identified after completing the current version:- Menu buttons for common toppings — instead of a free-text field, the toppings step could offer clickable options for the most common choices, reducing blank or unusable entries.
- Order review screen — a confirmation step before checkout that shows the full pizza list and lets the customer make changes before entering payment details.
- Clearer total breakdown — the receipt panel currently shows subtotal, tax, delivery fee, tip, and total as separate lines, but a dedicated summary section that labels the calculation steps more explicitly would make the pricing logic easier to follow.
- Single shared data source — pricing values are currently defined in
app.jsand mirrored indata/menu.json. Moving to a single source of truth would mean price updates only need to be made in one place, reducing the risk of the two files falling out of sync.