Iris Application Vision
Admin Backend for Profile Management
Admin Backend for Profile Management -- Filtering profiles
Implemented Prototype: New User and Iris interaction
Youth need relevant, curated, timely resources from social services in order to achieve key milestones and feel empowered to take action as a decision maker in planning their future. We decided on a text-based program to deliver resources for a number of reasons:
- Foster youth need a resource interface that’s easily accessible from basic mobile devices that may not have wifi
- Often youth are using burner phones and their number may change frequently, this makes it hard for social workers to get in touch
- Texting is a native experience for teens, conversational interfaces are a key enabler of the internet of things
- Text response based conversation provides progressive engagement so that the user isnt overwhelmed by the amount of information and resources out there
- A Text-based program is a flexible and scalable solution that could grow into many applications and uses within this space.
This inspired us to scaffold out a solution that integrates a rich profile system with a SMS-based resource manager. We chose SMS since it is the most supported mechanism for communication.
What it does
The current iteration integrates a rich profile system with a SMS-based task manager. We chose SMS since it is the most supported mechanism for communication.
There is a backend interface for the profile system which shows a list of profiles that have been created. Each profile represents a youth in foster care. Typing in a phone number filters the list.
Profiles are keyed not only to a unique id, but their phone number as well. Also shown on the profile screen are the current active tasks as well as any interests a user has subscribed to.
The second part of this solution is the Task Manager. Admins can define tasks that can be triggered based on keyword matching. One of our teammates, Michael also worked on a separate "fuzzy text matching" service to expand the user friendliness and responsiveness of the system. What this means is that a user can enter in a misspelled keyword and still receive an appropriate response back from the system.
When triggered the task will initiate a call/response sequence that can potentially branch off based on the input. Ultimately we want to develop the UI for configuring the task decision tree.
The attached video demonstrates a sample task sequence.
Our chat bot recognizes the phone number we are texting from and uses the appropriate profile for the interaction. For the sake of this iteration, we have assumed that the user has already registered with the system.
How We built it
The prototype is a NodeJS Express application using MongoDB hosted in mlabs as the data store. We leveraged several open source libraries including Bootstrap and datatables.js to build a responsive UI that is fast and easy to work with. The application also has a lightweight Twilio API integration for SMS support.
As part of our prototyping and implementation exploration we also worked with Losant (https://www.losant.com/). This tool supported fast and easy workflow diagramming, and offered numerous integrations for services like Twilio, Redis, MongoDB etc.
Our solution offers a number of endpoints for other systems to support interoperability. Data can be exchanged in JSON format. And example endpoint is retrieving profile data by phone number.
Challenges We ran into
This was our first large application built using NodeJS and MongoDB. While we were fairly familiar with the theory behind developing “API First” we ran into a few snags early on in testing data. We built out the CRUD Operations for each of our data types by hand.
Testing the SMS part was also tricky, we got an early prototype working through Twilio, but decided to instead mockup a basic HTML UI that interacted with our stateful web service.
Fighting feature sprawl versus defining a goal that was obtainable given the time and skill constraints. Everyone we talked to had so many great ideas and suggestions, it was hard to choose one focus and stay on track.
We originally were using a vagrant VM to host our node apps, but the Twilio API required accessible endpoints that couldn’t be routed through vagrant.
Accomplishments that We're proud of
While we are far from complete. I think we built a great MVP. We leveraged our teams unique skillsets really well and pulled together to really come up with a great pitch with “real” substance behind it. Everyone had something to contribute that they can be proud of.
What We learned
Losant is a very interesting and powerful tool as it is flexible and offers numerous integrations. It also has a dashboard and various logging capabilities. At minimum, Losant can serve as a powerful prototyping tool to quickly test out assumptions and work through scenarios with minimum upfront development cost.
What's next for Iris
- Customizable commands
- Calendar integration
- Aspirational content
- Localized opportunity feeds
- Contact direct channel
- Community forum
- In-app form entry assistance