User Interface for a survey api
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
assets
curl-scripts
grunt
lib
public
.editorconfig
.eslintrc.json
.gitignore
.remarkrc
.sass-lint.yml
CONTRIBUTING.md
Gruntfile.js
LICENSE
README.md
STYLE.md
favicon.ico
get-form-fields.md
index.html
index.js
notes.md
package-lock.json
package.json

README.md

_Fist 2 5

An SPA that allows users to create and respond to custom-made surveys. Surveys are limited to one question with responses ranging from 0-5. Users can view all surveys that have been created. Owners of surveys can view individual survey results, and delete surveys.

API

Technologies Used

  • HTML5
  • CSS3
  • jQuery
  • Bootstrap
  • Handlebars
  • AJAX requests

Unsolved Problems

Future iterations would include more variety in terms of the types and numbers of questions users can create.

We'd also like to make the app more user-friendly by adding search functionality, better visual representation of survey results, and a feature that would host each survey at its own unique URL.

Development Stories

This was our first project working as a team, which presented plenty of growth opportunities throughout the entire development process.

Planning

We spent the evening before the project creating wireframes, ERDs, and user stories. The first morning of the project we discussed the all three planning elements, confirmed they were good, and went to work.

Process & Problem-Solving

We started out with two of us building the back end API while the other half of the team built the front end framework. We quickly hit our first bump in the road after we decided to change the relationship between the survey and response resources. We were only able to solve this problem after all four of us programmed off of one screen.

Seeing that we could get over problems more effectively as a full team, we spent much of the first two days working as a team to meet our technical requirements. We frequently referred back to the requirements and user stories in order to stay on track.

By the start of Day 3, the final day of the project, we were ready to add more visual design and make minor tweaks to improve a user's experience. During this process we worked in pairs or alone. By this point we'd developed a comfort for the team development workflow.

Working as a team was probably the biggest challenge we'd faced throughout the project. We may have been able to write more code if all of us worked independently of in pairs, but putting all of the code together into a cohesive unit would have been difficult.