Overview

This phase we will finish our project to develop an online system for the Creamery. This phase will constitute 14 percent of your final course grade and is broken down into the following components:

1. Implementation of Site Design: An appropriate visual design for the site using CSS and appropriate images should be created. Even though you have been given a basic CSS as a starter, do NOT feel in any way that you have to use these settings and designs; much of this is just for the sake of people who need help from phase 3 to get up to speed. (Indeed, to get top marks on visual design, you will need to improve upon the default CSS.)

When users log into the application, they should go to a home page that provides all the key information a user would immediately want access to (or have access to it with just one click). Some thoughts on information architecture appear below, but the design of information for employees, managers and administrators is up to the discretion of you, the designer. An appropriate way for each type of user to navigate throughout the site must be clearly evident and allow easy transitions to other parts of the application.

A lot of the grade this phase will be on the quality of the interactions you design for each of the users and how well you implement the design concepts discussed in class. Below is a list of high-level use cases to guide you, but if you feel a need to deviate from this list, you may do so as long as it is documented in the README file and you have discussed it in advance with Prof. H.

As last time, semi-static pages for about, contact, privacy and the like must be in place. No 'lorem ipsum' style text is accepted on any page; text should be appropriate for the page. The student's name must appear on the bottom of every page in the footer (name should be listed as webmaster or designer).

2. Authorization: You have been given a set of ability tests that can guide you in creating your own authorization system and these tests must pass. Authorization should be implemented at both the controller and the view level. Do not show options to a user that the user does not have the authorization to act on. What you specifically do to minimize the gulfs of execution and evaluation will play a roll in the final assessment of the application.

3. Testing: All unit tests (given in the starter code) must be fully working. Since you were given a solution, expect a penalty if this solution is not implemented and any unit tests fail. As for cucumber tests, there are no tests provided in this phase in order to maximize your freedom to design. As a result, the weight of this phase is considerably less for tests and much more on designing appropriate interactions.

4. Coding Style: All code must be appropriately organized. What that means at this stage is the following: Indentation should be used consistently to make code readable. Comments showing organization should be present and explaining difficult code should be used when/if necessary. All business logic should be in models, not views or controllers.

---

Starting the project

Starter code is available for you on darkknight. It is recommended that you begin with this code for two reasons. First, it has a complete set of models that are fully-tested and known to work for the task at hand. The second is that the code contains a set of services that will prove useful in completing key tasks for this phase.

It is also strongly encouraged that you read the README file with this repo as it has directions for running tests and populating the database with realistic data for you to experiment with. Likewise, reading through some of the new model code, especially key models like Employee and Shift would be advised as there are methods and scopes there that you were not assigned to complete in the previous phase.

---

A Few Thoughts on Information Architecture

As you think through your information architecture, here are a couple of things to keep in mind:

• Employees need to quickly find upcoming shifts they are scheduled to work.
• Employees need to be able to see their most recent pay statement (or payroll).
• If an employee logs in and has a shift scheduled that day that is pending, some type of large button to "clock in" should appear; if the shift has started, but not over, then a similar "clock out" button should appear.
• A manager's most important task is to add upcoming shifts to employees assigned to the store over the next seven days. (That is, today and the next seven days)
• Consequently, seeing a list of upcoming shifts already scheduled for the particular store for today and the next seven days would also be very helpful to managers.
• Managers also need to easily fill out reports on the various jobs performed after each employee's shift is finished. This is often seen by managers as a nuisance, so if you can make the process easy, it would be greatly appreciated by the managers.
• Administrators need a way to easily calculate the payrolls for a particular store over a particular time period (e.g, past two weeks, past month, etc.)
• Administrators have other needs that you should reflect on further.

---

Services

The starter code you have been given has several services that may prove useful. Chief among these are the PayrollCalculator and the TimeClock services. The good news is that these services are tested and reading the tests may give you a good idea of how these services might be implemented in your application.

---

Filtered parameters

When editing an employee record, the employee him/herself must not be able to set the role parameter and the controller should filter out any attempts to do so. (In fact, no one but the administrator should be able to set role.) In a similar fashion, because we don't want anyone to manipulate dates for pay rates, so these should be set internally and the controller should filter out any attempts to change them.

---

Other notes

A few other notes students should be aware of:

• If a table has no content, then give an appropriate message rather than displaying an empty table.
• No 'geek dates' – format dates in a user-friendly fashion and do so for an American (rather than European) audience.
• If the computer should know the date (because it is today or tomorrow, for instance) then users typically don't have to enter the date. When a date is needed for scheduling shifts, use a datepicker for dates rather than three date dropdown lists that Rails defaults to.
• All tables, lists, and select options must be appropriately ordered.
• Appropriate and clear feedback for the user needs to be given to reduce misunderstanding.
• Navigation options appropriate for each type of user should be provided.

---

Finishing the project

Your project will be turned in via git no later than the last day of classes -- 4:59pm on May 1, 2020. We will transfer a copy of your files from your remote git repository on darkknight-cmuis.net to the grading system on May 5th at 4:00pm. We know that everyone will turn in their applications on time, so we will not bother to check timestamps in this last phase. We will keep access open to the remote repositories and answer questions regarding the project after the due date since those things may prove helpful to students studying for the final exam. Once we start transferring files on May 5th, we will have to cut off student access to the server, so any applications missing or largely defective at that time will get a zero grade.

Again, if you have questions regarding the turn-in of this project or problems downloading any of the materials provided, please ask Prof. H or a Head TA well in advance of the turn-in date. Do not wait until 48 hours or less before it is due to get help as we may not be able to respond in a timely fashion that close to the deadline.

Additional Information. Below are links to additional files references above.

High Level Use Cases