We’ll be looking at a piece of software produced by past UCSB CMPSC 156 students (specifically, from F20, W21, S21).

This piece of software is intended as an “improved version” of

• https://my.sa.ucsb.edu/public/curriculum/coursesearch.aspx

There are four versions that you can look at:

First, there is the one implemented by the F20/W21/S21 CS156 students:

• Available here https://proj-ucsb-courses-search.herokuapp.com/
• Code: https://github.com/ucsb-cs156-s21/proj-ucsb-courses-search
• This one has quite a few features beyond the UCSB production app
• But not all of them have been fully realized, and some may contain bugs or parts that are incomplete.

A few things that the S22 version of the app offers:

• Basic course search (but for a wider range of quarters; it goes all the way back to 2009)
• Advanced course searches. Some examples:
  • When was a course offered over time, and who taught it?
  • For a given professor, what did they teach over time?
• Statistics of various kinds for various courses.

There was an intention to start offering the ability to put together “sample schedules” of courses (this feature requires login), though it was never fully implemented. Think about: if it were, what would you want it to look like?

Then there are three versions implemented by the W22 CS156 students. You’ll be assigned one of these code bases as your starting point. These are very much preliminary works in progress:

You’ll see that so far, these apps offer CRUD applications for schedules, but no ability to add or delete courses from those schedules.

Also for basic search, the applications offer the ability to search, but only the basic search, and you can only see the course heading, not information about particular sections. It turns out that one of the most difficult and fundamental problems in implementing a course search app is converting the structure of the JSON that is returned by the UCSB Courses Search API into a structure that can be used to populate a table like the ones you see on the Official UCSB Courses Search, or the S22 Courses Search.

As you think about what feature you could work on, you may also consider the features available to you on GOLD, and whether some of those features could be and/or should be added to these apps.

Step 1: As a group, organize the document into sections by user

• Please open the Google Document Folder that was shared in the announcement Slack channel. Navigate to your team’s document.
• Add a new document with the title Product Owner Activity, s22-xpm-y 05/10 (put in your team name in place of s22-xpm-y).
• Also put Product Owner Activity, s22-xpm-y 05/10 as a heading at the top of the text of the document (put in your team name in place of s22-xpm-y).

• Now, add six headers for each of the names of members of your team, so that you each have a section of the document to enter some notes, e.g.

  Alice

  Alice’s notes here

  Bob

  Bob’s notes here

  Chris

  Chris’ notes here

  etc.

Step 2: As an individual explore the application

Then, as individuals, spend 5-10 minutes doing this:

Next: Open up the application.

• Spend a few minutes exploring the https://proj-ucsb-courses-search.herokuapp.com application and it’s features.
• Compare/contrast with https://my.sa.ucsb.edu/public/curriculum/coursesearch.aspx and GOLD
• Think about what would be valuable to you as a student.

Finally, also open up the app you are inheriting from the W22 section, here:

Step 3: As an individual make some notes

Then, make some notes about what you see that is good, and what could be improved. Aim for 3 items.

As you make notes, consider including screenshots.

• What features do you find the most valuable?
• What changes would you make to the user interface?
• What features are missing that you think would be valuable?

If you’d like to see a certain feature, consider mocking up a design of what the forms would look like.

If you’d like to see changes to a User Interface, consider making a screen shot, and then marking it up with the changes you’d like to see.

Step 4: With a partner, share your ideas

With a partner, discuss some of the ideas you each came up with independently.

Take turns, half a minute each pitching each other your ideas.

Then, choose your favorite two to share with the team.

Step 5: As a group, discuss your lists (8 minutes)

Add a section at the top of the document with a header called “Group Discussion”

Group Discussion

Enter notes here

Alice

Alice’s notes here

Bob

Bob’s notes here etc.

Invite each pair of students on the team to share their two ideas for the application.

One member of the group should make some notes about what there is consensus about, and where there is disagreement.

Note all eight ideas.

Finally, choose two of the most important features that you’d like to prioritize in the new version of the application, and mark those in your document.

Also, choose someone that can present for your team.

Step 6: As a class, each team shares 1 or 2 of the ideas your team came up with

We’ll come around to allow each group to spend time sharing their idea(s).

One student (maybe two) from each team will have half a minute to share their idea with the class.

So, keep it short! This is a low presure exercise meant to be fun and not test your public speaking skills.

At most share 2 ideas that your team felt would be high priority with the class.

Step 1: Login to your team’s OG Happy Cows deployment.

You’ve been playing HappyCows at the production deployment available from the credentials in this Slack message and you can continue to play the game there, and learn about it.

But the deployment at the chem123 server does not give you admin access.

Your team has its own deployment of the original Happy Cows code (written in Express/Node), at one of the links below; for these deployments, you can give each team member admin access. This allows you to create new commons, as well as manipulate the parameters of each commons.

But to set up admin access, each team member first must login to the game at the link below (select the appropriate link for your team.)

So please login now, at the appropriate link below. Just logging in is all you need to do for now.

Once you’ve logged in, make a Slack post in your team’s channel indicating:

• I've logged in to the og HappyCows app for this team

Then go to the next step.

Step 2: Find your Heroku Deployment

You should also find a Heroku Dashboard link for these. Your team members should have access to these links; make sure that you do. If any member of your team is missing, add them.

Step 3: Giving each member of your team admin access to the app.

Once each team member has logged in to your Happy Cows og app, you can give everyone admin access. This involved a manual change to the SQL database.

For this, step, it is easiest to do this at the CSIL prompt, because the mysql client is already installed there; you won’t need it except for this one step, so it’s not worth it to install on your local machine.

Just login into CSIL, and then paste in this command:

   mysql -u xxxx --password=yyyy -h us-cdbr-east-05.cleardb.net -D zzzzz

Of course, the values xxxx, yyyy, and zzzz are not the real values. You’ll get the real values by visiting the Heroku dashboard for your app, and revealing the Config Vars, like this. Click the “Reveal Config Vars” button, and you should see values for: DB_NAME, DB_USERNAME and DB_PASSWORD. The xxxx is the username, the yyyy is the password and the zzzz is the database name. Fill those in, and hit return.

That should bring up a prompt like this one:

Where you can then use a command like this to list all of the users:

select * from users;

You should get output like this:

+----+-----------+-----------+---------------------+-------+--------------------------------------+---------------------+---------------------+
| id | firstName | lastName  | email               | type  | token                                | createdAt           | updatedAt           |
+----+-----------+-----------+---------------------+-------+--------------------------------------+---------------------+---------------------+
|  4 | Kev       | Heffernan | kheffernan@ucsb.edu | admin | e775aeb0-cb34-11ec-8d12-d5718fa24def | 2022-05-03 23:01:02 | 2022-05-03 23:01:02 |
| 14 | Phill     | Conrad    | phtcon@ucsb.edu     | admin | ffbfcaa0-cb34-11ec-8d12-d5718fa24def | 2022-05-03 23:01:43 | 2022-05-03 23:01:43 |
+----+-----------+-----------+---------------------+-------+--------------------------------------+---------------------+---------------------+
2 rows in set (0.071 sec)

If you see that all of the users listed should be made admins, you can use this command to set them all at once:

update users set type='admin' where 1;

Or, you can set them one at a time like this:

update users set type='admin' where id='4';

Once you are finished, you can type exit to leave the mysql prompt.

Step 4: Test the admin access

At this point, every member of your team should have admin access. You can test this by visiting the url /admin on your site, e.g.

From there, you can experiment with both the admin and user features of the app.

If you get this instead, then it means you were not successfully added as an admin. Try repeating Steps 1, 2, and 3.

Step 5: Learning about Happy Cows

There are four documents that you should read to learn about the HappyCows game. Please take 5-10 minutes for each team member to look over these documents.

1. Happy cows description: A text description of the game, by Prof. Mattanjah de Vries, the UCSB Chemistry professor that developed the game.
2. Happy cows intro: A set of slides about the game also by Prof. de Vries.
3. gamePlay.md: A high level description of the game by Seth VanBrocklin, who was an LA for CMPSC 156 during W22, and graduated after W22. (Seth may be available to consult with teams in class.)
4. newFeatures.md: A description of possible future designs for HappyCows A description of possible future designs for HappyCows, also written by Seth.

Step 6: As a group, organize the document into sections by user

• Please open the Google Document Folder that was shared in the announcement Slack channel. Navigate to your team’s document.
• Add a new document with the title Product Owner Activity, s22-xpm-y 05/10 (put in your team name in place of s22-xpm-y).
• Also put Product Owner Activity, s22-xpm-y 05/10 as a heading at the top of the text of the document (put in your team name in place of s22-xpm-y).

• Now, add six headers for each of the names of members of your team, so that you each have a section of the document to enter some notes, e.g.

  Alice

  Alice’s notes here

  Bob

  Bob’s notes here

  Chris

  Chris’ notes here

  etc.

Step 7: As an individual explore the original application

Then, as individuals, spend 5-10 minutes doing this:

Next: Open up the older HappyCows application using the Heroku deployment assigned to your team:

• Spend a few minutes exploring the current Happy Cows application and its features.
• Think about features that would make it easier for the instructor/admin to set up the game.
• Think about features that make game play more interesting

Step 8: As an individual explore the W22 application

Then open up the app you are inheriting from the W22 section, here:

See what features work, and what features are missing. You may also want to consult with the LAs or other staff.

It may also be useful to consult the Kanban boards:

Step 9: As an individual make some notes

Then, make some notes about what you see that is good, and what could be improved. Aim for 3 items.

As you make notes, consider including screenshots.

• What features do you find the most valuable?
• What changes would you make to the user interface?
• What features are missing that you think would be valuable?

If you’d like to see a certain feature, consider mocking up a design of what the forms would look like.

If you’d like to see changes to a User Interface, consider making a screen shot, and then marking it up with the changes you’d like to see.

Step 10: With a partner, share your ideas

With a partner from your team, discuss some of the ideas you each came up with independently.

Take turns, half a minute each pitching each other your ideas.

Then, choose your favorite two to share with the team.

Step 11: As a group, discuss your lists (8 minutes)

Add a section at the top of the document with a header called “Group Discussion”

Group Discussion

Enter notes here

Alice

Alice’s notes here

Bob

Bob’s notes here etc.

Invite each pair of students on the team to share their two ideas for the application.

One member of the group should make some notes about what there is consensus about, and where there is disagreement.

Note all eight ideas.

Finally, choose two of the most important features that you’d like to prioritize in the new version of the application, and mark those in your document.

Also, choose someone that can present for your team.

Step 12: As a class, each team shares 1 or 2 of the ideas your team came up with

We’ll come around to allow each group to spend time sharing their idea(s).

One student (maybe two) from each team will have half a minute to share their idea with the class.

So, keep it short! This is a low presure exercise meant to be fun and not test your public speaking skills.

At most share 2 ideas that your team felt would be high priority with the class.