summary | time | deliverables |
---|---|---|
Create a seemingly fully function, coded prototype of your web application. |
18 hours |
A web app prototype |
Throughout the term you’ll be working on teams to make a small web app prototype. This—the second, larger—part of the project is to design a pattern library and code a seemingly fully functional web application prototype.
- One team member is the dev lead, they will be the guide, but everybody must contribute.
- Team contributions should be logged on GitHub for assessment purposes.
- Follow the standardized Agile Sprint framework.
- It does not have to actually work, just appear to work.
The ultimate goal is to create a pattern library & functional prototype that could be handed off to a developer who will hook all the pieces together. A prototype that could be reliably user tested with out confusing “it’s not working” looks.
You’ve already completed the UX component of the project so you already know every screen and component necessary & how they’ll look responsively on all different screen sizes.
Start with a pattern library to design & code each component—this works very well on teams because each person can code different components.
It’s up to you & your team to code every necessary piece of functionality.
- A user should be able to click everything and the expected thing should occur.
- If a user adds a book, they should be able to enter all the details & save, but a new book doesn’t need to show up.
- If a user rates a book, there should be some kind of visual feedback.
- Each navigation item & each button should pretend to perform the expected behavior.
- Each form field should function adequately.
- Use trickery like hidden checkboxes/radios or CSS
:target
to make things functional. - Apply necessary transitions & animations.
- The teacher can help you write some simple JavaScript if you think that will enhance the experience.
- It absolutely must work on every screen size—but it doesn’t necessary have to work or look the same.
Since this is a team project it will be coded by everybody. We’ve already set up a process that protects the master
branch for incomplete & incorrect code.
- Each piece of code will need to be reviewed by another team member.
- Use Jekyll to its full potential:
- Break the code into the smallest possible pieces
- Use lots of CSS files
- Consider using something like a pattern library
- Consider scoped classes, classes that are prefixed to their pattern
- The smaller the chunks of code the easier it is to manage—thinking and working as a pattern library helps
- Try to avoid editing the same files at the same time as a team member—though it shouldn’t be a major problem, it does remind you to break everything into small pieces
- Every small chunk of code that needs to be completed should have the following things:
- A correctly labeled Issue assigned the a single person, sprint & milestone
- A new feature branch in the person’s local repository solely for that small chunk of code
- Eventually a pull-request for that small chunk of code
- Each pull-request should be reviewed and, if necessary, improved by the person who originally coded it
- Feature branches should never be re-used: after the pull-request is closed, a new Issue & branch should be created to make additions.
As the team responsible for making this application it’s up to you to determine if the web app you created is successful and up to Thomas’s standards.
- We’ll be setting up a marking rubric to define your success criteria.
- Determine what grade you deserve for the time and effort you put into the code.
- Consider how well your team worked together and how that should be reflected in your grade.
- Comment on the rubric Issue, as team, to determine your deserved grade—essentially fill out the rubric for yourselves.
- Is the final result something you’re proud of? Would you show it in your portfolio? Would you give it to a paying client?
You’ll be assigned the grade you deem necessary after discussion with the teacher. Be honest—I’ll know.
During the class that this is due your team will show the teacher and discuss with them what you’ve created. The teacher will wish to usability test your website and play with the features.
You’ll will be assigned the grade you chose on the spot—unless the teacher deems your self assessment to be incorrect, in which case you’ll have to refine what you think you deserve.