- Can we combine the Manage Trips and This Week page into one? Perhap show in one column all unsignued up for upcoming trips, and in another column all trips that the user is leading/heeling/signed up for in chronological order, with some sort of color / other indication as to trip status. Or just have one long list, with non-signed up for trips collapsed. This simplifies the general flow of the site. I'm thinking fewer pags == better user flow.
- Build a separate Past Trips page? This makes good sense - it could be in the navbar.
- Regarding models - it might be nice to save the signup type on the signup, but maybe not necessary. It might make atomic saves/updates more difficult (eg, promoting to heeler requires updating the trip model, and the associated signup, and then rolling that back on an error.) OR: We do away with the approved/waitlist/leader/heeler signup fields on the trip, and just save the signup type on the signup model. Then it's easy to move signups around, and still easy to get all signups of a certain type for a trip, and do sorting for the all upcoming signups for a user. Would any queries be made more difficult? (Perhaps if we have a trip, and need to see if we have aleder for it? This would require a second database hit.) Something to think about though...
NOTE: Because there is no fundamental difference between heelers and the general public (other than self-identification), the terms "heelers" and "others" are used synonomously throughout.
Everyone should always have a nav menu with:
- Sign up for trips
- Lead a trip
- Manage my trips
Leaders and heelers see the same thing.
This lists all trips which meet all of the below conditions...
- In the future
- Has a leader
- The user has not signed up for
The leader's name should be a mailto email link.
Signing up puts you on a waitlist (via the WaitlistTrippeeSignup association) as a trippee.
- Add trip section
- Claim a trip section
- Shows all proposed trips in the future without leaders. Signing up will automatically make you the leader.
- Propose trip section
- Claim a trip section
- Shows all created trips in the future without heelers. Signing up will set the "wantsToHeel" field of a signup instance to true. If the user has already signed up for the trip, signing up again here will replace the the entries in their old signup instance, but not replace the acutal instance. This ensures that the instance's
createdAtfield will be unchanged, maintaining an FCFS ordering for trip signups.
- Shows all created trips in the future without heelers. Signing up will set the "wantsToHeel" field of a signup instance to true. If the user has already signed up for the trip, signing up again here will replace the the entries in their old signup instance, but not replace the acutal instance. This ensures that the instance's
The "add trip" and "propose trip" sections should look identical, but the backend should behave appropriately.
The "claim a trip" sections should have signup forms for each trip and behave appropriately.
###Leaders see:
- A link to the "My past trips" page
- A "Trips I'm leading" section.
- If empty, say "You are not currently leading any trips."
- Link to each trip's "Trip Control" page.
- An "Other Trips I'm on" section.
- A "Trips I've requested to be on" section.
###Others see:
- A link to the "My past trips" page
- A "Trips I'm heeling" section.
- This should not appear if no trips are being heeled.
- Link to each trip's "Trip Control" page.
- A "Trips I'm on" section.
- A "Trips I've requested to be on" section.
Both "Trips I'm on" and "Trips I've requested to be on" should look like the "Sign up for trips" listing, with additions...
- Have a "Drop trip" button (Question: What should this button's behavior be? Should we ask for an optional reason? Send email to leader and/or heeler? Just drop and require that leader/heeler check the site to be informed?)
- Instead of the standard "Signup" form, display the user's current signup info, and allow them to change it by editing the contents of text fields and hitting "Update comments" or "Update dietary rescritions".
- If the user has requested to heel a trip, but has not been approved as a heeler, this should be indicated in that trip's listing.
Sort from most recent to least recent.
EXTRA: Have a "show trippees" expandable menu for each trip. At the bottom of the trippee listing should be a "blitz trip" button.
- List all trip info
- All of the trip's information fields should be updateable, ala the "Manage my trips" signup-editing.
- List all trippees. The trippee list...
- Should be sorted into a "Waitlist" and an "Accepted" list. Obviously it should be possible to move trippees between these lists.
- Moving somebody from "Waitlist" to "Accepted" should send that trippee an email notification.
- Should display each trippee's signup info, including desire to heel.
- The leader should be able to promote ANY trippee to heeler, regardless of indicated desire to heel.
- Conversely, the leader should be able to demote a heeler to trippee.
- Should be sorted into a "Waitlist" and an "Accepted" list. Obviously it should be possible to move trippees between these lists.
- There should be a "blitz trip" button that adds the trip information to the email body.
- QUESTION: Should we offer a text field into which the message can be typed, or should we try to use the user's default mail program. Attachments are tricky via the site, but what will happen if somebody's using a Robo lobby computer and we use a
mailto? - EXTRA: It would be nice to allow the user to automatically attach the OPO medform or waiver.
- QUESTION: Should we offer a text field into which the message can be typed, or should we try to use the user's default mail program. Attachments are tricky via the site, but what will happen if somebody's using a Robo lobby computer and we use a
- An in-app utility to collect each of a number of selected trip statistics during a given time period.
- We need to spec out how to incorporate OPO. Julie needs to be able to check trips, for instance.
- We need to spec out how to incorporate the CnT chairs.
- We need to figure out how the leader database should work.
- We're going to want a utility to compile the "THIS WEEK" blitz.
- Work out how trips should be transferred between leaders/heelers
- Figure out protection for various parts of the site. The "Trip control" page, for instance, needs to be inaccessible by everyone except the trip's leader and heeler.
- Will problems arise if a heeler is promoted to leader?
attaches the user object (pulled from the database) to the requests. Also exposes the user object in all templates; no need to pass {user: req.user} to res.render.