Implement loaner program

[lukesanantonio]

FirstByte’s loaner program lends out electronic boards to educators for use in their classroom. Teachers are usually lent a number of boards (approx. 10 to 25) for use over an agreed upon duration (usually a few weeks). The boards may often work / be compatible with at least one of our FirstByte curricula.

There’s a rough draft for database schema below. This is our reasoning: Each board is of some type (e.g. it’s either a Makey-Makey, a Bit:Booster, a Raspberry Pie, etc). Technology refers to this “board type.” Furthermore, we lend out a number of boards in the form of a Kit. All the boards in the kit are the same technology, and should be lent out as a single unit. In the diagram below and on our website mockup (look in this drive folder in the file called “loaner program main page design.pdf”, you will find a nicely formatted list of technologies - thank you Celine). In summary, each technology may have a number of Kits, each of which can be reserved separately by different people at overlapping or non-overlapping times.

Our current process to lend out boards is based on some documents and email templates (See Loaner Program Email Templates). We could potentially automate these emails, or provide a similar experience through a website UX. This is the reason behind having a distinction between a reservation and reservation request. The request can be received, a notification sent to the team (slack message, email, etc), and we should manually approve it. Once it’s confirmed, the system ought to keep it in mind so another educator can’t try to reserve the same kit at the same time.

Khalil has previously talked about this UX as similar to a library loaning system. A library may have multiple copies of the same book, and may lend out the book until it runs out of copies. With that in mind, we need not distinguish individual kits, if at least one is available at a certain time, that’s totally fine. The teachers need only see which technologies are available for their reservation time, not how many or which ones in particular (there is no effective difference for them, but we should definitely keep track for our inventory).

Again, see below for a rough draft of a design for a database schema. Furthermore, the Django models and some minimal templates for this schema have already been built (thank you Kevin and Khalil). Check out the loaner-program branch to work off previous efforts.

A small laundry list of nice-to-haves:

• Design database schema
• Create Django models
• HTML Templates / UI
• Integration with curricula (links to/from kits and specific lesson plans)

Initial Design: