You’ve come a long way, and it's time to show it. This will be your most advanced project to date, and if you put creativity into it, it'll hopefully be the thing you want to show off most prominently in your portfolio.
You get to call the shots and invent your own idea, choosing frameworks & tools that are appropriate for what you want to build. Pull from everything you've learned so far, and tackle something that'll push you a little outside of your comfort zone.
For this project, you'll be working on your own and using product development strategies learned in unit 3 to come up with a project proposal that will be reviewed with your instructional team. This proposal is done to make sure you are building something that can be accomplish in the limited time we have while making sure it's something that will challenge you.
Your app must:
- Be a complete application that provides a thorough solution to the problem you choose to address
- Have an impressive design and user experience that follows Google's Material Design Guidelines and can impress future clients and employers
- Use at least one API or SDK
- Implement thoughtful user stories that are significant enough to help you know which features to build and which to scrap
- Be object oriented with organized, well-documented, DRY code
- Be robust: handle orientation changes without losing state, and handle of failure well (e.g., failed network calls) gracefully
- Be available on the Google Play store, so it is publicly available
As always, your app must adhere to General Assembly's student code of conduct guidelines.
If you have questions about whether or not your work adheres to these guidelines, please speak with a member of your instructional team.
-
Determine what problem(s) you'd like to address or niche you'd like to fill with your app
-
Write a Research Plan (use this format) and add it to a
research.mdmarkdown file to be handed in with your completed project -
Conduct at least 3 user interviews
-
Add the following to your
research.mdfile after your research plan:- Research Highlights (use this format)
- User Personas (use this format)
- Problem Statement(s) (use this format)
- Competitive Analysis (feature inventory or +/Δ model; embed in
research.mdas a screenshot or a markdown table)
-
Use a 2x2 Matrix to prioritize your possible features
-
Write a Project Proposal (either in a
proposal.mdfile or a Google Slides / PowerPoint deck) which includes:- Overall Objectives, including problems to be solved and user goals to facilitate - these should be very specific and based on your research!
- Research Synthesis - what trends, goals, motivations, and pain points did you identify?
- Target Audience - must be very specific and represent your interviewees - What do they need and why? How/when/where do they use similar apps? What do they value and what do they avoid? Etc.
- Prioritized list of features - What problem or user goal does each one address? How did you determine priority?
- Differentiators from competitors and pain points addressed
- Constraints you face - e.g. availability of data, need for permissions users may deny, unfamiliar technologies required, etc.
- Anything else you think we should know as we decide whether to approve your proposal
-
Present your proposal to Drew or Charlie starting at 3:30 pm on Monday, 12/12
- Sign up for a time slot here
- 7 minutes for presentation, 8 minutes for our questions
- You may need to present a revised proposal on Tuesday, 12/13 if we are concerned about your initial proposal
-
Once your proposal is approved:
- Create a Paper Prototype for all screens you plan to include in your app
- Write User Stories for your features and plan your testing
- Plan out the classes & interfaces you'll need
- Sketch out your app's architecture - do you need background services, scheduled jobs, local data storage, etc.? What 3rd party libraries will you use?
Begin building your app. Remember to...
- Commit often & push to GitHub to preserve your progress
- Do your work on separate feature branches and test thoroughly before merging into your master branch - make sure your master branch always works!
- Write tests for your features as you implement them (ideally, even before)
- Choose good, descriptive names for classes & variables and document your code with comments
Catch up on sleep! Take some time to review your progress, reevaluate priorities, and get ready to have a productive final week.
Finish implementing and testing your app, then publish it to the Google Play store.
Write a readme.md file that includes:
- A link to your app on the Google Play store
- What the app does & how it's useful
- Embedded screenshot(s) to show off your features
- Explanation of the technologies, techniques, libraries, etc. you used
- A couple paragraphs about the general approach you took in your design process that point to your
research.mdfile - If necessary, any special instructions on how to build the app in Android Studio
- Descriptions of any unsolved problems or major hurdles you had to overcome
Submit a pull request to this repo by 9:00 am. If you created a repo from scratch rather than fork this one, then make a fork, add a link to your other repo, and submit a pull request.
Final deliverables that must be in your repo:
- Source code for a completed, fully-functioning app
- Unit tests and Espresso tests as needed
- Frequent commits dating back to the beginning of the project with useful commit messages
- A
readme.mdfile meeting the requirements listed above, including a link to your app on the Google Play store - Photos of your paper prototypes (or a link to a [POP] prototype)
- Your
proposal.mdfile (or link to Google Slides document) meeting the requirements listed above - Your
research.mdfile meeting the requirements listed above
Everyone will present their app to the class starting at 9:00 am. You have a maximum of 10 minutes, with 7 minutes to demo the app and 3 minutes to discuss your process.
- Don’t get too caught up in too many awesome features – simple is always better. Build something impressive that does one thing well.
- Design first. Planning with user stories & wireframes before writing code means you won't get distracted changing your mind – you'll know what to build, and you can spend your time wisely by just building it.
- Don’t hesitate to write throwaway code to solve short term problems.
- Read the docs for whatever technologies / frameworks / API’s you use.
- Write DRY code.
- Be consistent with your code style.
- Commit early, commit often. Don’t be afraid to break something because you can always go back in time to a previous version.
- Keep user stories small and well-defined, and remember – user stories focus on what a user needs, not what development tasks need accomplishing.
- Write code another developer wouldn't have to ask you about. Do your naming conventions make sense? Would another developer be able to look at your app and understand what everything is?
- Make it all well-formatted. Are you indenting, consistently? Can we find the start and end of every div, curly brace, etc?
- Comment your code. Will someone understand what is going on in each block or function? Even if it's obvious, explaining the what & why means someone else can pick it up and get it.
- Write pseudocode before you write actual code. Thinking through the logic of something helps.
- Class resources list
- Android Developer Website
- Google Design Guidelines
- API Search and ProgrammableWeb - find APIs to get the data you need
- HackDesign and Visual Design Hacking - tips for producing great designs
- All content is licensed under a CCBYNCSA 4.0 license.
- All software code is licensed under GNU GPLv3. For commercial use or alternative licensing, please contact [email protected].