Fire-Bae

Project Introduction

Welcome to Tier Two projects. By now, you should be feeling more comfortable in the basic development tools, as well as gaining confidence in writing more code, which incidentally is exactly what we want you to do now. Write more code. Additionally, we have higher expectations for the planning, design, and overall user experience of your projects.

Great software developers are always refining their craft—others just stick to their original assumptions, regardless of how much friction those decisions cause down the road. A second goal of this project is to push and test your ability to adapt your project as you learn new skills and topics over the next two weeks. Is your code tied to your initial ideas of how to approach the problem or are you able to pivot and try out different ideas as you go along? Did you stick with what you knew at the very beginning of the project or were you able to integrate concepts and ideas from React (or mocking and stubbing or some advanced Firebase techniques) as you learned them?

Tier Two Projects: Choose wisely. You are in charge of your own fun.

  • A Fancy List
  • A Smart Budget
  • A Nimble Networker

Regardless of which project you choose, your project must:

  • Be test-driven (where applicable)
  • Use build tools
  • Be designed by the student
  • Use a mobile-first approach
  • Be accessible

Project Option Descriptions:

A Fancy List

Lists are handy resources to keep you from forgetting the most important things. Be it a grocery list, a ‘to-do’ list, or a ‘things-I-don’t-need-but-really-want’ list—they are a critical part of most people’s day-to-day. And while I’m sure we can all appreciate the good ole pen and paper list, we want something a little more dynamic. As a user, I want a list that:

  • Allows for quick entry of my list items, along with the ability to delete and/or “check-off” list items
  • Allows me to assign list items to a category that I define
  • Enables sort, search, filter functionality so that I may quickly locate list items of interest
  • Allows me to enter optional sub-tasks on any individual list item
  • Shows me a preview of the most frequently used list items, which I can quickly add to my list with one click

A Smart Budget

Money doesn’t grow on trees, and it sure can burn a hole in many a person’s pocket. Let’s build an app that helps people manage their day-to-day spending by providing insight into their projected cash flow. And let’s make it personable, smart, and most importantly - funny. As a user, I want a budget app that:

  • Let’s me view my financial outlook daily, weekly, monthly, annually.
  • Allows for easy input of recurring transactions (credits & debits) that I can set by day/date. Examples include monthly car payment, paychecks, gym membership, etc.
  • Allows for custom entry of budgeted expenditures that are not necessarily on a set recurring schedule/amount. Examples include grocery, eating out, movies, mom’s birthday gift, etc.
  • Allows for a starting balance on the day of my choosing, and from there, calculates how much $$ I will have available in the future by day/date, based upon all my recurring and budgeted expenditures.
  • Every time I open the app, I am greeted with a random “money quote”. For Example

A Nimble Network

Networking is a critical skill, and it can get hard to keep track of everyone you meet when you’re getting established in a new industry. Build an app to help you organize all your contacts and, hey, maybe even do a little job stalking while you’re at it. As a user, I want a networking app that:

  • At a minimum, allows me to record name, company, email, social media, and phone number of new contacts.
  • Ideally, I can also add an image (like logo, avatar, biz card snap)
  • Includes a toggle on/off “followup” indicator on each contact, which will save those contacts in a “followup” list for my quick reference
  • Permits multiple options for email, phone, and social media, and allows me to specify “primary” where applicable.
  • Includes an option note field for each contact, so that I can write myself little reminders about how we met, and what we discussed.

Project Timeline

This projects spans a full fourteen (14) days. Your group will have the opportunity to check-in with instructors for guidance and assistance.

Things to keep in mind as you are planning your time for the next two weeks:

  • DTR: clarify roles, scheduling restraints, personal learning goals at the start of the project
  • Take the time to wireframe your app. Think through the user flow, have a solid plan and direction for you project. Don’t start coding without a roadmap.
    • Pro-tip: Bring early wireframes and ideas to Module 1 students, friends, and family. Are your assumptions about how a user would interact with the application accurate?
  • Your app must be visually correct and consistent in Chrome, Safari, Firefox, and Microsoft Edge.
  • Test-driven development: This is essential unless you want your application to fall under the weight of itself.

Evaluation Criteria

You will have two evaluations for this project. The first is the good, old-fashioned technical evaluation. You’ll also have an evaluation on the UI. Nota bene: you will be on your own to wireframe and design this project.

You’re application should:

  • Work on all screen devices
  • Take a mobile-first approach
  • Be thoughtfully designed

Instructor Evaluation Points

Specification Adherence

  • 4 - The application meets all of the requirements listed above and implements one or more features not included in the specification. The application is an exemplar and is considered a production-level MVP (minimum viable product). The application is ready to be distributed to users.
  • 3 - No approach was taken that is counter to the spirit of the project and its learning goals. There are no features missing from above that make the application feel incomplete or hard to use.
  • 2 - The application is in a usable state, but is missing 1 or more of the features outline in the specification above.
  • 1 - The application is missing 3 or more smaller features or 1 major feature essential to having a complete application.
  • 0 - The application is unusable.

Risk Taking and Creativity

  • 4 - Developers pushed themselves and their team by taking risks which is demonstrated by a delivered feature. The application shows evidence that the developers explored concepts and technologies outside the scope of the curriculum.
  • 3 - The project shows that the developers carefully considered their approach and were able to implement concepts taught over the last two weeks. The application shows evidence that developers dug deep into documentation for the technologies they used and experimented with different approaches.
  • 2 - The application shows some effort to incorporate ideas and concepts from the last two weeks of instruction, but is structured in a way that makes it hard to adapt and change approaches. There is some evidence that the developers considered what additional features and functionality the user might need.
  • 1 - The application does the bare minimum it needs to and shows little or no influence by topics and approaches covered in the two weeks of instruction from when the project started. The project shows no evidence that the developers considered the user in implementing the features in the application.

Design

  • 4 - The application is visually appealing and shows thoughtful and effective use of typography, color, and layout. The application looks professional, with visuals enhancing the user’s experience. The evaluator has very few recommended changes.
  • 3 - The application has a strong approach to layout and content hierarchy, but typography and color choices are lacking. The evaluator has several recommended changes to improvement.
  • 2 - Layout, content hierarchy, typography, and color choices show effort, but the result is not effective. The evaluator recommends significant changes.
  • 1 - Layout, content hierarchy, typography, and color choices actively detract from the user’s ability to use the application.

User Interface

  • 4 - The application is pleasant, logical, and easy to use. The application is fully responsive, and has clearly had special consideration around usability on devices. There are no holes in functionality and the application stands on its own to be used by the instructor without guidance from the developer.
  • 3 - The application has many strong pages/interactions, but a few holes in lesser-used functionality.
  • 2 - The application shows effort in the interface, but the result is not effective. The evaluator has some difficulty using the application when reviewing the features in the user stories.
  • 1 - The application is confusing or difficult to use.

HTML Style

  • 4: Developer is able to craft HTML that is semantically correct and clearly organized. There are zero instances where an instructor would recommend taking a different approach. Developer writes markup that is exceptionally clear and well-factored. Application is expertly organized and logically structured with with thoughtful use of tags and selectors.
  • 3: Developer solves structural problems with a balance between conciseness and clarity. Developer can speak to choices made in the code and knows what every line of code and every tag and selector is doing.
  • 2: Developer writes effective HTML, but does not write semantically correct and clearly organized code. Application shows some effort to use semantically correct HTML, but the divisions are inconsistent or unclear. There are many un-semantic tags and unnecessary selectors and it is not clear to the evaluator what a given section of code represents visually. Developer cannot speak to every line of code.
  • 1: Developer writes code with unnecessary tags, selectors, or nesting which do not increase clarity. Developer writes code that is difficult to understand. Application markup shows poor structure with no understanding of semantics.

CSS/Sass Style

  • 4: Application has exceptionally well-factored CSS/Sass with little or no duplication and all styles separated out into logical stylesheets. There are zero instances where an instructor would recommend taking a different approach.
  • 3: Application is thoughtfully put together with some duplication and no major bugs. Developer can speak to choices made in the code and knows what every line of CSS/Sass is doing.
  • 2: Your application has some duplication and minor bugs. Developer can speak to most choices made in the code and knows what every line is doing.
  • 1: Your application has a significant amount of duplication and one or more major bugs. Developer cannot speak to most choices and does not know what every line of CSS/Sass is doing. Developer writes code with unnecessary selectors or tags which do not increase clarity.

JavaScript Style

  • 4 - Application has exceptionally well-factored code with little or no duplication and all components separated out into logical components. There are zero instances where an instructor would recommend taking a different approach.
  • 3- Application is thoughtfully put together with some duplication and no major bugs. Developer can speak to choices made in the code and knows what every line of code is doing.
  • 2 - Your application has some duplication and minor bugs. Developer can speak to most choices made in the code and knows what every line is doing.
  • 1 - Your application has a significant amount of duplication and one or more major bugs. Developer cannot speak to most choices and does not know what every line of code is doing.
  • 0 - Your client-side application does not function or the application does not make use of localStorage for updating information on the client. Developer writes code with unnecessary variables, operations, or steps which do not increase clarity.

Testing

  • 4 - Project has a running test suite that exercises the application at multiple levels (feature and unit). The test suite covers almost all aspects of the application. The testing in this project shows that the students dedicated themselves to overcoming obstacles and figure out how to test parts of the application that were otherwise “hard to test.”
  • 3 - Project has a running test suite that tests and multiple levels but fails to cover some features. All functionality is covered by tests. The application has robust unit tests and makes some use of feature testing where appropriate and applicable.
  • 2 - Project has sporadic use of tests at multiple levels. The application contains numerous holes in testing and/or many features are untested.
  • 1 - There is little or no evidence of testing in this application.

Workflow

  • 4 - The developer effectively uses Git branches and many small, atomic commits that document the evolution of their application.
  • 3 - The developer makes a series of small, atomic commits that document the evolution of their application. There are no formatting issues in the code base.
  • 2 - The developer makes large commits covering multiple features that make it difficult for the evaluator to determine the evolution of the application.
  • 1 - The developer committed the code to version control in only a few commits. The evaluator cannot determine the evolution of the application.
  • 0 - The application was not checked into version control.

Accessibility

4 - The application demonstrates an exceptional knowledge of web accessibility. The application has no aXe-core violations, is fully functional without using a mouse, and the application uses HTML/CSS to ‘chunk’ content into more manageable pieces. The application utilizes semantic HTML.

3 - The application has a strong accessibility presence. The developer showed a strong effort to keep accessibility in mind from the beginning of the project. The application has 0-3 aXe-core violations.

2 - The application shows glimpses of good accessibility practices, but fails to deliver a truly accessible product. The application has 4-6 aXe-core violations

1- Developer did not keep accessibility in mind. The application has 6+ aXe-core violations.

Code Sanitation

The output from a code sanitizer (either JSHint or ESLint) shows…

  • 4 - Zero complaints
  • 3 - Five or fewer complaints
  • 2 - Six to ten complaints
  • 1 - More than ten complaints