- Start weekly project meetings
- Start a collaborative doc to take project notes before the tutorial
- Decide on an overall project direction (user profile, value proposition) before the tutorial
1 Start weekly project meetings
- We recommend you start weekly project meetings now. You can use the meeting to do tP tasks, but also help each other do iP tasks. On a related note, it is also acceptable to discuss weekly Canvas quiz (if any) together with team members as you do the quiz i.e., discuss and decide the answer collectively, but you should not give away your answers to someone who was not part of that discussion.
2 Start a collaborative doc to take project notes before the tutorial
- Keep project notes in an easy-to-use collaborative doc (Recommended: use a GoogleDoc). This document will be checked by the instructors at various points.
Remember to choose a tool that allow public view access e.g., GoogleDoc can be shared via a public link so that the document can be viewed by others. You'll be asked to submit this link to us in the next week.
Make sure all your current and future project notes (if split into in multiple documents) are reachable via links given in this document and are viewable by the public.
3 Decide on an overall project direction (user profile, value proposition) before the tutorial
- Decide the target user profile, and value proposition, as described in the panels below (tip: you can use your first project meeting for this):
As we are still at the early stages of identifying a problem to solve, do not think of the product (i.e., the solution) yet. That is, do not discuss the product features, UI, command format, and implementation details, etc. unless they are pertinent to the user profile or the problem addressed.
Pick a CLI-friendly product domain: Given Recommendation-CLI-First and Constraint-Typing-Preferred mentioned in the panels above, it makes sense to pick a product domain that is more suitable for CLI interactions i.e., a product that deals with easy-to-type textual data, needs a small number of data fields, and each data field is short. For example, a blog editor is an unsuitable product domain because it also deals with non-text data (e.g., images, videos) and some data fields are quite long (i.e., paragraphs of text). Similarly, keeping track of extensive employee records may be an unsuitable domain if there are many data fields per employee.
- Submission: Submit via TEAMMATES.
- Details to submit:
- Product name (plain text only) e.g., ClientContactsPro
- Target user profile (plain text only) e.g., freelance event photographers
This is a general description of the target user, not the 'persona' you defined (the latter serves as a concrete representation of the target user, for your internal use only). - Value proposition i.e., what problem does the product solve? (plain text paragraph, no more than 50 words) e.g., provide fast access to client contact details, optimized for users who prefer a CLI
This is not a list of features -- you should not think about exact features yet. - Link to the project notes document: This should be an online document/page (not a folder) -- e.g., a GoogleDoc (not a Google Drive location) -- that is publicly accessible. If your project notes are in multiple locations/files, this one document should contain the link to the other documents with guidance on which link is for what.
- You'll receive an email from TEAMMATES with the submission link. Only one member needs to submit on behalf of the team. All members can view/update the submission.
- Details to submit: