Project
Description / Proposal As a team we are building a decision tree tour guide/ event website. Our objective with this site is to help people who are just visiting Seattle find common places to go, either to have fun, get food, or enjoy different activities such as the art galleries, zoo, aquarium or other fun activities around Seattle. The idea came for those type of people that are either just visiting Seattle for a short time or a couple days and to be an event planner or for those that just feel antsy in their homes / apartments and want to go out and do something.
Our site will come complete with 3 pages, one to handle the landing page that will give instructions and abreviated about us, it will give instructions on how to play the selector tool, and one long About Me page where it goes over the team members and what we completed in the project. Our stretch goal is to have a trip planner, a 4th page where we will have directions to the places that a person can input their current address and get directions to the activites. We are also planning on having a pricing indicator so a person knows what to expect to need to have with them not only in their bags for the activites but also aproximation of how much they will need for either Bus / cab fair to get there, but also have bus routes and proximated parking fares depending on how they want to get there.
Domain Model
At a base we will have 3 pages, the Landing or home page, the activity selector, and the About Me page, and last our stretch goal the event planner.
Home / Landing Pages
Introduction
Selector tool use / Explaination
Quick About Me / Our Mission
A few Testimonies
Game / Selector tool
Person selects what activity they are feeling like doing
user will be asked what they are feeling like doing i.e. Food, Fun Activity, Out Doors
From there each user will be asked a series of 4-6 questions
once the questions are answered the output of the location near the user will be output on screen with
prices
yelp reviews
address
items needed
each item will have a link to the website of choice so a user can see more images or other items
About Me
Small bio of each of the team members
Photos of team members
Completed work on pages
Area of responsibilities
Small section where each member can do something funny/ whitty/ or give more detail about themselves
Trip Planner (Stretch)
Get address from user
get selected activity
directions to activity
Bus fare calculator
cab fare calculator
Items needed for activity
Requirements Roadmap
Wednesday/Thursday Evening: Plan, plan, plan...
Thursday Evening: Finalize your Project Plan and share it with the instructional staff. We'll give you tips and pointers.
Saturday Morning: Start building!
Monday-Wednesday: Focus on core functionality
Wednesday: Strive for MVP being 100% by end of the night.
Thursday: Stretch goals, UI/UX, code cleanup, documentation, and rehearse presentations
Saturday: Presentations
You've decided on your final projects. Here are the guidelines that will determine how you operate over the next 7 days.
Rules
Your team must adhere to the following requirements:
Each person must make meaningful contributions in HTML, CSS, and JavaScript.
Each person must speak for a seemingly equal amount of time during presentations.
Your website must have at least 3 interlinked pages and clear navigation.
Your website must accept and process user input.
Your website must be deployed live on the Internet at the time of project presentations on Friday.
You will have a daily individual project report to submit via Canvas.
Every project needs to have a well written and structured README for documentation.
Every day, each team needs to perform a daily standup to cover the following:
Where are we in the development process?
What is left to get to MVP(Minimum Viable Product) by Wednesday?
What do we need done by End Of Day.
based on the tasks left to complete, who will be taking on each task?
Process
Here's the process that we'll be using for project week:
During project week, your team must generally work on-campus so we can help whenever your team is stuck.
At the start of each day, each team will do a 5-10 minute standup meeting, with a member of the instructional staff.
Each team should engage in user testing by inviting people to sit down and interact with your site. This will help your UI/UX immensely.
On the last day of project week, your team must present your project, using the deployed version of the project. Presentation guidelines will be available in the class repo for each day of project week.
Project Proposal
On the Friday before project week your team must submit a project plan to an instructor with the following information:
This can be a simple google doc for simplicity.
Your team's name (if you want one besides what I set for you)
Your team's members
Your project's name and concept
A diagram of your project's domain model
An exhaustive explanation of how your team plans to address details in the problem domain
Sketches/wireframes of your project's pages
NOTE: You should not be writing any code prior to the submission of the project plan.
TIP: Use pencil and paper to diagram and sketch. Online tools look snazzy but take some time to learn.
Launch phase
Here are some suggestions on how to organize your team during the launch phase:
Elect a Launch Driver who will be responsible for the following:
Driving the coding of the initial scaffolding phase.
Hosting the code under their GitHub account.
The rest of the team will be Launch Navigators and responsible for the following:
Navigating the coding of the initial scaffolding phase.
Staying one-step ahead of the Launch Driver by researching unfamiliar technology.
Once everyone is in agreement, here's how to launch a new project. Build a basic scaffold, such as the following, from scratch as a team:
README.md
LICENSE
index.html
any other HTML files go at this level
css/
reset.css
style.css
style2.css, etc.
js/
app.js
app2.js
app-data.js
Once all these pieces are wired up together, move on to the following.
Initialize a new Git repository.
Push it to GitHub and add your team members as Collaborators.
Make a plan, and get to work!
Development phase
Now that your project is launched, here's how to organize the development efforts of your team. Your goal is to have the entire work plan for the project planned and organized, down to the finest details, before you begin any coding:
Use GitHub Issues or a tool like waffle.io or Trello to manage and divide up the work between your team members. This planning is essential.
Create new issues that'll take approximately 30 minutes to 2 hours (max!) to complete.
Use labels and milestones as your team sees fit, but leave all newly created issues unassigned.
Assign an issue to yourself when you commit to working on it.
Each feature should be built on its own branch. Think of each of the issues above as a feature.
Once assigned, create a branch using a naming scheme such as the following:
Imagine issue '#1' is titled "Add an about.html page".
The branch name would be 1_add_about_page.
Push the commits on your branch to GitHub regularly.
Create a Pull Request for your branch even if you're unsure if it'll be merged into master.
Ask someone else on your team to review the code in your Pull Request.
If changes are required, make them on your branch and push them to GitHub for another review.
Once satisfied, let the reviewer merge your Pull Request. Don't merge your own Pull Request.
Presentation
On the last day of project week, your team will have 15-20 minutes to present your project.
Explain your project's problem domain and your team's solution.
Explain the challenges that arose during project week and how your team overcame them.
Each person should handle part of the presentation. More details will be coming on this as we get closer to the day of presentations.
Grading
Your grade is based on your individual effort and your project's technical merit.
Individual effort is graded based on links to commits and Pull Requests that demonstrate your contributions.
Technical merit is graded based on the following criteria:
Good and proper use of HTML
Clear, readable, and efficient structure
Uses semantic markup whenever possible
Contains no unused or unnecessary code
Good and proper use of CSS
Clear, readable, and efficient styles
Layout on various screen sizes like desktop and mobile
Well organized file structure.
Contains no unused or unnecessary code
Good and proper use of JavaScript
Clear, readable, and efficient code
Passes the linter
Global variables and functions are kept to a minimum
Responds to user events
Contains no unused or unnecessary code
Generally useful and functional
Works as expected with no bugs
Uses domain models to encapsulate data and behavior
Has at least 3 interlinked pages with a clear navigation, including an "About" page that tells us about each team member.
Has at least one page that accepts and processes user input
State (i.e. data) persists between page reloads
Deployed live on the Internet