A college, to attract more students, has decided to offer free pizza in the dormitory. You have been selected to implement the needed automated ordering system.
The pizzas will be available in two sizes, small and large. Toppings beyond the basic tomato sauce and cheese can be selected from an expandable set of options:That is, a student can order any subset of these toppings, or none at
all. Students are users of this system but do not explicitly
register with the app, for simplicity. Instead, each student has a
username and room number set up in by the admin. When the student orders
a pizza, the user and current day is saved with the order. The students
should be able to ask (by username) if their pizza is done, and its size
and toppings, i.e., all information on pizzas ordered so far today for
this user. When a student acknowledges receipt of the pizza(s),
those pizza orders are marked completed.
The pizza shop admin tells the system when the next pizza is done (they
are cooked and come out of the oven in order), and when a day is done.
When a day is done, all the orders are complete for that day.
The pizza shop admin can add and delete toppings and users, and set up
shop from scratch. Also, the admin should be able to ask for information
on all the pizzas ordered so far today that are not yet complete, the
“in progress” orders.
Pizzas are tracked in the system by their status: PREPARING just after order is placed, BAKED a while later, FINISHED after receipt by student or end of day. Days are tracked by simple day number that is incremented by the admin’s finish-day action.
Actions for Students
This is all about the pizzas ordered by one user. We could ask the user “up front” for his/her username, but websites normally allow users to proceed without identifying themselves until an actual order is in the works, so we first display info that doesn’t require knowing the room number on the student-welcome page, that is, the choice of toppings and sizes, with a link to order a pizza. The student can choose their username from a select list at the point if they want to. On the order form, the user needs to identify themselves, along with the choice of toppings and size. When the order is submitted, control returns to the student-welcome page, where now the newly submitted order is displayed as an order for this room, along with all the other elements previously listed for the student-welcome page.
When the order is new, it has status PREPARING. At some point, the admin uses a command (see below) that changes its status to BAKED, that is, ready for delivery. When the pizza is delivered to the user's room, the student is expected to acknowledge its receipt, and then its status changes to FINISHED. The student can see the current status of the ordered pizza by refreshing the student-welcome page, since it displays the status of all of today’s pizza orders for this user. If there are any BAKED pizzas in this list, a button should appear to acknowledge receipt of such pizza(s).
Note the correspondence between the student pages here and the product pages in the product_manager of ch05_guitar_shop. Both use just two pages, one to list the objects of interest to the user and another to help add/delete another object to/from the list. Nowhere is the user presented with the raw list of actions.
Actions for Admins
When designing modern user interfaces, think objects, then actions. Looking at the admin actions, we see they can be grouped as involving objects that are toppings, users, orders, and days. Of course the most important orders are the ones in progress, which are affected by the Mark and Finish-day commands. Thus we propose the top-level topics:
This is something like the categories in the product_catalog UI of ch05_guitar_shop. Note how the categories are handled by a sidebar. However, such sidebars waste valuable horizontal space, crowding smartphone screens. So we will use a nav bar across the top, like Yoko's Kitchen from Duckett pp. 444-448 (but those links don't actually work). Our nav bar is supplied in pizza1_setup.
From the home page, if the admin selects Toppings, the list of current toppings is displayed, plus a link to a page to add a topping. Similarly, if the admin selects Users, the list of current users is shown.
If the admin selects Orders on the home page, the list of PREPARING and BAKED orders are shown, and a button is provided for marking the oldest PREPARING one baked. In either case, the modified lists of in-progress orders are shown. If the admin selects Days, today’s day number is shown, with a button to advance it to the next day. Also a button to reinitialize the system. Today’s orders are shown, of all status values.
Architecture and Organization: for Project 1, we will follow the patterns implemented in ch05_guitar_shop: