Skip to main content

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.

The Alex Pizza Assistant began as a Python console program — a simple chatbot that asked one question at a time, collected pizza order details, and calculated a final cost. Bringing that project to the browser meant more than swapping input() calls for HTML form fields. It was an opportunity to expand the order flow, redesign the validation strategy, and present the same beginner programming concepts through an interface that is easier to interact with and easier to share.
This article was written by the project author, Alysha Pursley, as part of the original project documentation. It explains the key decisions made when translating the Python console version into a static browser application.

From Python Console to Browser Chat

The original Python chatbot walked through a single pizza order: one size, one set of toppings, one quantity. The terminal handled all the input and output, and the flow was strictly linear. The browser version preserves that conversational, question-by-question structure, but replaces the terminal session with a persistent chat interface where Alex’s messages and the user’s replies build up as a scrollable conversation. The project is intentionally static — no backend, no build step, no external libraries. It runs entirely in the browser using plain HTML, CSS, and vanilla JavaScript, which means it can be hosted on GitHub Pages without any server-side infrastructure.

What Changed in the Order Flow

The biggest logical change is that the app no longer limits the customer to a single pizza. After the first pizza’s details are collected — size, toppings, crust type, and quantity — Alex asks whether the user would like to order a different pizza or add another one. If the answer is yes, the pizza fields reset and the same questions repeat for the new pizza. If the answer is no, the app proceeds to checkout. This loop continues until the customer is done, so a single order can include any combination of sizes, toppings, and quantities. Every pizza that gets added is attached to the same receipt under the same delivery or carry-out method. The order method is only asked once, after the first pizza is confirmed. The updated steps collected per pizza are:
  • Customer name (collected once at the start)
  • Pizza size (small, medium, or large)
  • Toppings
  • Crust type
  • Quantity
  • Add another pizza? (yes / no)
  • Order method — carry out or delivery (collected once after the pizza loop)

Validation in the Browser

Input validation was one of the most important parts of the original Python program. The console version used while loops to keep prompting the user until a valid response was entered. The browser version translates that same idea into client-side validation: if an answer is blank, unrecognized, or otherwise unusable, the app shows an error message inline and does not advance to the next step. The validated fields in the app are:
FieldRule
NameCannot be blank
Pizza sizeMust be small, medium, or large
ToppingsCannot be blank (enter cheese for plain)
Crust typeCannot be blank
QuantityMust be a whole number greater than zero
Add anotherMust be yes or no
Order methodMust be carry out or delivery
Payment methodMust be cash or card
Card numberMust be 13–19 digits
Expiration dateMust match MM/YY format
Security codeMust be 3 or 4 digits
Tip amountMust be a valid dollar amount (e.g., 3, 3.50, or 0)
This keeps the calculation logic from ever receiving missing or unusable data.

Checkout and Payment Updates

The checkout flow branches based on payment method and order type: Cash payments The app shows a message appropriate to the order type. For delivery, Alex informs the customer that the driver will collect cash payment upon arrival. For carry out, the customer is told to pay when picking up the order. Card payments A simulated card checkout collects a card number, an expiration date in MM/YY format, and a 3 or 4 digit security code. Once all three fields pass validation, the app displays a simulated approval message referencing the last four digits of the card number.
The card checkout is a front-end demo only. No payment data is transmitted, processed, or stored anywhere. This flow exists to make the order feel more complete and to demonstrate conditional input branching.
Driver tip For delivery orders paid by card, Alex asks whether the customer would like to add a driver tip. The prompt includes the note that 100% of tips go directly to the driver. The entered tip is added to the final order total. The tip step is skipped entirely for carry-out orders and for cash delivery orders.

Pricing and Totals

The pricing logic is the same as in the original Python version. Pizza prices are fixed:
SizePrice
Small$8.99
Medium$14.99
Large$17.99
Delivery adds a flat $5.00 fee. Sales tax is 10% applied to the pizza subtotal only. The full formula is:
total = subtotal + tax + deliveryFee + tip
subtotal = sum(pizzaPrice × quantity for each pizza)
After the total is calculated, the app checks whether the order reaches 50.Ordersthatdoreceiveacongratulatorycouponmessagefor50. Orders that do receive a congratulatory coupon message for 10 off a future order. Orders below $50 are shown a message noting that the coupon is available for orders over that threshold.

Interface and Presentation

Instead of a terminal window, the browser version uses three visual areas working together:
  • Chat feed — Alex’s prompts and the user’s replies appear as styled message bubbles, building up as the conversation progresses.
  • Live receipt panel — a sidebar panel that updates after each confirmed answer, showing the customer name, order method, payment method, and running cost totals.
  • Itemized pizza list — each completed pizza is added to the receipt as its own line item, showing size, toppings, crust, unit price, and item total. This makes the multi-pizza logic immediately visible: the customer can see their full order building up before they reach checkout.
This presentation replaces the terminal print statements from the Python version while keeping the same output information. The chat structure also makes the step-by-step validation flow feel natural — the user is answering questions in a conversation rather than filling out a form.

Programming Concepts Demonstrated

The app is designed to be readable as a learning project. The original Python concepts are all present in the JavaScript translation:
The following concepts from the original Python program are all demonstrated in the browser version of the app.
  • Variables — the order object stores every collected value, from the customer name to the card’s last four digits
  • Loops — the multi-pizza addAnother branch repeats the pizza questions until the user says no
  • Validation — every input is checked against a rule before the app advances, mirroring Python’s while-loop validation pattern
  • Conditionals — payment method branching, tip logic, delivery vs. carry-out messages, and the coupon check are all controlled by if/else logic
  • Arrays — completed pizza objects are pushed into the order.pizzas array and iterated to build the receipt and calculate the subtotal
  • Calculations — subtotal, tax, delivery fee, tip, and total are all computed from the collected values
  • Type conversion — quantity is converted from a string input to a number for arithmetic; tip input is parsed and stripped of any $ prefix
  • Formatted output — prices and totals are formatted as currency strings using toLocaleString for consistent $0.00 display throughout the receipt

Build docs developers (and LLMs) love