Inspiration
facebook started as 'people I like', and has become 'people like me', especially around healthcare. fb is a source of health information and discussion, and has the potential to be the daily hub of coordinated health care. fb is part of the fabric of life and can be an important organizing platform for personal health management.
What it does
LIGHTHOUSE helps seniors navigate chronic conditions in pursuit of specific health goals. We help our members build core habits in diet, physical activity, taking their meds and writing stuff down. v1 of LIGHTHOUSE messenger focuses on education and data logging and building health care circles. Members receive individualized care plans and health care journey support.
How I built it
Serverless on AWS Lambda. AWS RDS for member data storage.
Challenges I ran into
Some of the async/promise processes used to manage member data, session information and content delivery occasionally go out-of-sync with how the fb service calls my API -- every now and then a misplaced "await" would generate 50 fb platform replies to a simple request. You just have to wait for them to finish.
Some of the wit.ai data structures forced me to do some inelegant workarounds -- if I had an entity for measurement it showed up in the wit.ai payload as "measurement:measurement", which breaks JSON.parse if I was hoping to use dot-notation to access data.
Sometimes I wanted to send two messages to a person, however, the sequence I sent them was not always the sequence in which they arrived. It was mostly cool (I could adjust the language so the order didn't matter), but if I needed to send a text message followed by a quick-reply, if they went out of order, the quick-reply would get wiped.
Accomplishments that I'm proud of
We did a good job matching up the experiences (free type, templates, quick-responses) to the interactions to maximize accuracy and flexibility. It's natural for a health service to want to load up on reminders and fire up that "One Time Reminder", but without compelling member context, it's something WE want, not them. We waited until the member expressed some additional level of commitment, e.g., adding a content program before we asked "The 'My First Year with Diabetes' program suggests a Monday reminder to set your weekly goals. Can we contact you on Monday?".
Also, navigating some of the unpredictable comms patterns between fb and my API ended up creating a great experience.
What I learned
You have to work to learn how people "naturally" talk and capture tons 'o error data to figure out the gaps between how you think people will use our service and how they actually do. We had 15 users sit down with no-prompt, limited-prompt and aggressive prompt to start to work on our side of the conversation. We have a lot of mileage yet to cover.
What's next for LIGHTHOUSE messenger
The bot is still in development because it works in tandem with a Portal by Facebook experience which has been under review for 10+ days at this point and we need to line up intents, data sharing, and VUX. By Q4 there will be a seamless experience across Portal and messenger.
We have a pretty deep recipe library that didn't make it into this release of our messenger experience, and we have a big library of senior-focused workout videos that need to have a reimagined experience to be compelling. Lastly, our bot data capture is less broad than our Portal data capture -- we need to add a little user-insight into how we might differentiate the experiences or how we drive people to different experiences.
TRY IT OUT I'll clear out some of our proprietary content engine stuff and API keys and get it up on github in the next couple of days. It's worth it to see a couple of cool things we did with async. I don't think I can share the bot since it is still technically in DEVELOPMENT -- I'll see about getting a sharable version.
Log in or sign up for Devpost to join the conversation.