The app is titled TABLE — NYC Dining Guide, branded with the tagline
"Dine Remarkably." It presents itself as a curated directory of six iconic New York City
restaurants, allowing users to browse menus, compare pricing, and assemble a custom order across
multiple venues in a single session.
Observed Behavior
A loading screen with the app name and tagline appears on entry, suggesting an animated splash sequence before the main content renders.
The main view displays a grid or list of restaurant cards. A search field (⌕) and sorting/filtering controls are present: sort by Featured, Rating, Price (ascending/descending), and Name A→Z.
Users can open individual restaurant entries to browse menu items and add them to a persistent cart/order panel.
An "Your Order" sidebar or modal tracks selected items with a running item count shown in the header badge. It includes Place Order and Clear Order actions.
Placing an order triggers a confirmation screen ("Order Placed! 🍽️") with a Back to Guide button, resetting the flow.
A filter pill row allows toggling between "All" restaurants and (presumably) category or cuisine filters.
Issues & Unexpected Behavior
Loading state is stuck / slow: The page initially showed only "Loading NYC Dining Guide" — it is unclear whether the restaurant data loads from a static JSON payload or a live API call. If it relies on a fetch that fails silently, users would be stuck on the loading screen indefinitely.
No real backend: "Place Order" almost certainly does not send data anywhere — it simply resets UI state. This means the confirmation screen is cosmetic rather than functional.
No persistence: Cart state appears to be in-memory only. Refreshing the page would clear the order with no warning or recovery option.
Filter pills unclear: Only "All" was visible in the fetched markup; individual category or cuisine filter labels were not returned, suggesting they may be dynamically injected or the categories were not populated for all six restaurants.
No accessibility markup apparent: From the fetched markup, no ARIA roles, landmark regions, or keyboard-focus management were visible, which would be a concern for screen reader users.
No price totals: The order panel shows item counts but the fetched markup does not show a running price total — a core feature for a dining/ordering UX.
Single-page dead-end: After "Order Placed," the only path is back to the guide — there's no order history, email receipt, or copy-to-clipboard option.
What Works Well
The concept is well-scoped and appropriate — six curated restaurants is manageable for a classroom project.
Sort and filter controls show clear UX intent and cover the most common user needs (price, rating, name).
The order/cart pattern with a sidebar and confirmation state is a competent implementation of a full purchase flow skeleton.
Branding is cohesive: "TABLE" as the name and "Dine Remarkably" as a tagline give the app a real product feel.
Suggested Improvement Prompt
You are improving an existing NYC restaurant guide app called TABLE.
The app currently:
- Shows 6 hardcoded NYC restaurants with menus, filters, and an order cart
- Has a "Place Order" button that only shows a success screen (no real submission)
- Uses in-memory state (cart resets on refresh)
- Is missing a running price total in the cart
- Has no accessibility attributes (ARIA roles, focus management)
Please rebuild and improve the app with the following changes:
1. CART & ORDERING
- Show a running subtotal (item price × quantity) and grand total in the order panel
- Support quantity increment/decrement per item (not just add/remove)
- After "Place Order," generate a printable/copyable order summary with
restaurant name, items, quantities, and total
2. DATA & PERSISTENCE
- Store cart state in localStorage so it survives a page refresh
- Show a "Restore your previous order?" banner if saved cart data is found on load
3. FILTERS & SEARCH
- Make the search field live-filter restaurant cards and menu items simultaneously
- Add cuisine-type filter pills derived dynamically from the restaurant data
(e.g., Italian, Seafood, American, etc.)
4. ACCESSIBILITY
- Add proper ARIA roles: role="main", role="navigation", aria-label on buttons
- Trap focus inside the order modal when it is open
- Ensure all interactive elements are keyboard-navigable with visible focus rings
5. UX POLISH
- Add a subtle entrance animation for restaurant cards (staggered fade-in)
- Show an empty-state illustration/message when no restaurants match the search
- Add a "Favorite" (heart) toggle per restaurant that persists across sessions
via localStorage
Keep the existing visual branding (TABLE, dark/gold palette, serif typography).
The app should remain a single HTML file with no external build tools.