Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
DESIGN PowerPoint Presentation

DESIGN

118 Vues Download Presentation
Télécharger la présentation

DESIGN

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Group 8 James Won, Chris Lo, Jennifer Hong, Kevin Shang, Tony Wong EMPLIFY PROBLEM STATEMENT DESIGN CHALLENGES • Account verification through text • Integrating the webapp UX to SMS • - Created interesting decision problems, • such as when to actually create the • account and start allowing the user to fully • interact with the application. • Intelligent parsing of texts • Difficult implementation • Required most flexibility with the least learning required for the user. • Dependencies between user stories • Some user stories could not be started until others were finished. • Some user stories broke old user stories. • We had to learn how to take ownership of all affected code through our user story. • Inconsistencies in coding styles • Problem due to coding in different styles, using hacks, and accidentally duplicating code. • Learning to fix other’s problems, code consistently with the rest of the codebase. Future Scientist is a non-profit organization which empowers communities to improve their quality of life through science, ADMIN PATH health and engineering education. Particularly in Panama, they needed a way to connect people who have problems and issues to people who have the skills needed to help them. Since most people in Panama don’t have access to internet, our client requested that our application also be entirely accessible through text. Admin dashboard Create admin account SOLUTION LESSONS PROVIDER PATH • 2 Types of Users: • “Requesters”: Users who need a problem solved. • “Providers”: Users who are qualified to solve problems. • Learned a lot about agile development • Consistent meetings with each other and our client kept us unblocked and allowed us to be flexible in our implementation of the application as we figured out better solutions together. • Always DRY out code. • Not only does that make it better legacy code, it makes it a LOT easier for us to debug. • How it works: • Providers must create an account and request to add skills to their accounts, which admins must approve. • Requesters can optionally create an account, which enables features like problem tracking. Problem details page Create provider account REQUESTER PATH No Internet? No problem! • Extending the webapp through the Twilio API for SMS support: • Requesters, through texting, can: • - Post new problems • - Edit their problems • Providers, through texting, can: • - Receive a filtered list of available problems • - Get more information on a specific • problem • - Accept a problem FUTURE PLANS • Berkeley Big Ideas 2012 • Gathering funds for Panama expansion • Expand the prototype • Figure out how to incorporate it SMS in Panama (Twilio currently does not support Panama numbers) • Spanish language support Problem submission through text Notification of problem acceptance through text Problem submission form