INV-04 Receive Invitation
Use Case: Receive Invitation
An invitation is generally an HTML email containing information from a Guide to either an existing Member or a prospective New Member regarding an upcoming Outing.
NOTE: There are some design considerations:
- User may or may not be on a browser.
- User may or may not be on a device that supports a browser.
Actors
- Member - if they have installed the Play app already
- New Member - if they have not yet installed the Play app
Pre-Conditions
- Not Tested: User's email app needs to be able to understand HTML links sufficiently to allow bringing up links in the browser from an HTML email body.
- Guide has sent the invitation email (INV-03 Send Invitations), the email is sitting in the Member's inbox, and the Member has opened the email in their favorite email client.
Steps
Likely Scenario #1: Reading the email on the device
- Read through the email (Invite Contents).
- Decide to visit link for more information regarding the course.
- Browser opens to Course page.
- User enters app and chooses INV-06 Accept Invitation.
Could go into a number of work flows here. They're really a menu of items that could each be chosen. The value in doing this is thinking about:
- Whether any flow emerges?
- Whether any flow might work better than other flows?
- What can be done to help the new member stay on track?
NOTE: In the diagram, I'm leaning toward the user accepting the invitation from within the application. Once the app is registered, invitations would be available to the app via the API.
Ideal Scenario for New Member
- User clicks a link that installs the app (avoiding reading the instructions for install-application)
- User is lead directly into the step for registration-design.
Alternative Paths
- There was consideration given to placing the data within a QR code, but that would require two devices. Doesn't mean this isn't an option, however.
Post-Conditions
These are up to the menu choices and sub-UCs.
References
page revision: 11, last edited: 22 May 2019 01:05