## Check out our site -> [Saga](http://sagaverse.app)

## Inspiration

There are few better feelings in the world than reading together with a child that you care about. “Just one more story!” — “I promise I’ll go to bed after the next one” — or even simply “Zzzzzzz” — these moments forge lasting memories and provide important educational development during bedtime routines. We wanted to make sure that our loved ones never run out of good stories. Even more, we wanted to create a unique, dynamic reading experience for kids that makes reading even more fun.

After helping to build the components of the story, kids are able to help the character make decisions along the way. “Should Balthazar the bear search near the park for his lost friend? or should he look in the desert?” These decisions help children learn and develop key skills like decisiveness and action. The story updates in real time, ensuring an engaging experience for kids and parents.

Through copious amounts of delirious research, we learned that children can actually learn better and retain more when reading with parents on a tablet. After talking to 8 users (parents and kiddos) over the course of the weekend, we defined our problem space and set out to create a truly “Neverending Story.”

## What it does

Each day, *Saga* creates a new, illustrated bedtime story for children aged 0-7. Using OpenAI technology, the app generates and then illustrates an age and interest-appropriate story based on what they want to hear and what will help them learn. Along the way, our application keeps kids engaged by prompting decisions; like a real-time choose-your-own-adventure story.

We’re helping parents broaden the stories available for their children — imprinting values of diversity, inclusion, community, and a strong moral compass. With *Saga*, parents and children can create a universe of stories, with their specific interests at the center.

## How we built it

We took an intentional approach to developing a working MVP

* **Needs finding:** We began with a desire to uncover a need and build a solution based on user input. We interviewed 8 users over the weekend (parents and kids) and used their insights to develop our application.
* **Defined MVP:** A deployable application that generates a unique story and illustrations while allowing for dynamic reader inputs using OpenAI. We indexed on story, picture, and educational quality over reproducibility.
* **Tech Stack:** We used the latest LLM models (GPT-3 and DALLE-2), Flutter for the client, a Node/Express backend, and MongoDB for data management
* **Prompt Engineering:** Finding the limitations of the underlying LLM technology and instead using Guess and check until we narrowed down the prompt to produce to more consistent results. We explored borderline use cases to learn where the model breaks.
* **Final Touches:** Quality control and lots of tweaking of the image prompting functionality

## Challenges we ran into

Our biggest challenges revolved around fully understanding the power of, and the difficulties stemming from prompt generation for OpenAI. This struggle hit us on several different fronts:

1. **Text generation** - Early on, we asked for specific stories and prompts resembling “write me a 500-word story.” Unsurprisingly, the API completely disregarded the constraints, and the outputs were similar regardless of how we bounded by word count. We eventually became more familiar with the structure of quality prompts, but we hit our heads against this particular problem for a long time.
2. **Illustration generation** - We weren’t able to predictably write OpenAI illustration prompts that provided consistently quality images. This was a particularly difficult problem for us since we had planned on having a consistent character illustration throughout the story. Eventually, we found style modifiers to help bound the problem.
3. **Child-safe content** - We wanted to be completely certain that we only presented safe and age-appropriate information back to the users. With this in mind, we built several layers of passive and active protection to ensure all content is family friendly.

## What we learned

So many things about OpenAI!

1. Creating consistent images using OpenAI generation is super hard, especially when focusing on one primary protagonist. We addressed this by specifically using art styles to decrease the variability between images.
2. GPT-3's input / output length limitations are much more stringent than ChatGPT's -- this meant we had to be pretty innovative with how we maintained the context over the course of 10+ page stories.
3. How to reduce overall response time while using OpenAI's API, which was really important when generating so many images and using GPT-3 to describe and summarize so many things.
4. Simply instructing GPT to not do something doesn’t seem to work as well as carefully crafting a prompt of behavior you would like it to model. You need to trick it into thinking it is someone or something -- from there, it will behave.

## Accomplishments that we're proud of

We’re super excited about what we were able to create given that this is the first hackathon for 3 of our team members! Specifically, we’re proud of:

* Developing a fun solution to help make learning engaging for future generations
* Solving a real need for people in our lives
* Delivering a well-scoped and functional MVP based on multiple user interviews
* Integrating varied team member skill sets from barely technical to full-stack

## What's next for Saga

### **Test and Iterate**

We’re excited to get our prototype project in the hands of users and see what real-world feedback looks like. Using this customer feedback, we’ll quickly iterate and make sure that our application is really solving a user need. We hope to get this on the App Store ASAP!!

### **Add functionality**

Based on the feedback that we’ll receive from our initial MVP, we will prioritize additional functionality:

**Reading level that grows with the child** — adding more complex vocabulary and situations for a story and character that the child knows and loves.

**Allow for ongoing universe creation** — saving favorite characters, settings, and situations to create a rich, ongoing world.

**Unbounded story attributes** — rather than prompting parents with fixed attributes, give an open-ended prompt for more control of the story, increasing child engagement

**Real-time user feedback on a story to refine the prompts** — at the end of each story, capture user feedback to help personalize future prompts and stories.

### **Monetize**

Evaluate unit economics and determine the best path to market. Current possible ideas:

* SaaS subscription based on one book per day or unlimited access
* Audible tokens model to access a fixed amount of stories per month
* Identify and partner with mid-market publishers to license IP and leverage existing fan bases
* Whitelabel the solution on a services level to publishers who don’t have a robust engineering team

## References

<https://www.frontiersin.org/articles/10.3389/fpsyg.2017.00677/full>
## Inspiration

2020 had us indoors more than we'd like to admit and we turned to YouTube cooking videos for solace. From Adam Ragusea to Binging with Babish, these personalities inspired some of us to start learning to cook. The problem with following along with these videos is that you have to keep pausing the video while you cook. Or even worse, you have to watch the entire video and write down the steps if they're not provided in the video description. We wanted an easier way to summarize cooking videos into clear steps.

## What it does

Get In My Belly summarizes Youtube cooking videos into text recipes. You simply give it a YouTube link and the web app generates a list of ingredients and a series of steps for making the dish (with pictures), just like a recipe in a cook book. No more wondering where they made the lamb sauce. :eyes:

## How we built it

We used React for front-end and Flask for back-end. We used [Youtube-Transcript-API](https://pypi.org/project/youtube-transcript-api/) to convert Youtube videos to transcripts. The transcripts are filtered and parsed into the resulting recipe using Python with the help of the [Natural Language Toolkit](https://www.nltk.org/) library and various text-based, cooking-related datasets that we made by scraping our favourite cooking videos. Further data cleaning and processing was done to ensure the output included quantities and measurements alongside the ingredients. Finally, [OpenCV](https://opencv.org/) was used to extract screenshots based on time-stamps.

## Challenges we ran into

Determining the intent of a sentence is pretty difficult, especially when someone like Binging with Babish says things that range from very simple (`add one cup of water`) to semantically-complex (`to our sauce we add flour; throw in two heaping tablespoons, then add salt to taste`). We converted each line of the transcription into a Trie structure to separate out the ingredients, cooking verbs, and measurements.

## Accomplishments that we're proud of

We really like the simplicity of our web app and how clean it looks. We wanted users to be able to use our system without any instruction and we're proud of achieving this.

## What we learned

This was the first hackathon for two of our three members. We had to quickly learn how to budget our time since it's a 24-hour event. Perhaps most importantly, we gained experience in deciding when a feature was too ambitious to achieve within time constraints. For other members, it was their first exposure to web-dev and learning about Flask and React was mind boggling.

## What's next for Get In My Belly

Future changes to GIMB include a more robust parsing system and refactoring the UI to make it cleaner. We would also like to support other languages and integrate the project with other APIs to get more information about what you're cooking.
## Inspiration

For the first 18 years of my life, I have lived in the same city. Despite living in the same place for almost two decades, I do not feel like I know the city on an intimate level. My friends and family usually stuck to the same couple of places we all knew we loved. Familiarity becomes comfortable, certainly, but we also know there's a wealth of undiscovered places situated right outside your backyard.

We created an iOS application called Oyster to promote and embrace spontaneous exploration, whether you're touring a new city for the first time, or simply coming back to a place you've called home all your life.

## What it does

Oyster brings its users to places they wouldn't usually frequent and generates half-day, full-day, or single activity "adventures" for users to embark on.

Input your desired location -- this can be a hotel you're staying at, your house, or anywhere you'd like to get to know better, and Oyster uses the Foursquare API generates an itinerary for the user. These destinations can be restaurants, museums, parks, or any points of interest in the surrounding area. Users can then navigate their walking progress with Apple Mapkit, or choose to take a Lyft.

In order to promote spontaneity, users are rewarded with points for accepting to go to a destination immediately. These points can then be turned into rewards from partnered businesses. In theory partnered businesses, in turn for their sponsorship, would receive increased foot traffic from our users and promotional events in our app, such as bonus points for visiting their locations on certain time periods. Once the user has gone to the location assigned by our app, they can "check in" and receive their points.

Our app also facilitates spontaneous itineraries. Choosing "Surprise Me!" will give the user one location, while choosing "Half-Day" or "Whole-Day" will give itineraries to fill up a larger amount of time.

## How we built it

We built the app using Swift 2.0. We employed several API's: we incorporated the Foursquare API using a Swift wrapper called Das-Quadrat and gathered potential points of interest located near the user. We also used the Lyft API to implement a ride-sharing option in case the user wanted mobile transportation to reach their destination. Lastly, we implemented the Apple Mapkit API for navigation, directions, and displaying locations.

For front end, we used Sketch 3 and Keynote to design and implement the user interface.

## Challenges we ran into

## Accomplishments that we're proud of

We are proud of building an app that we would actually like to use.

## What we learned

This was our first iOS app we have developed, so learning Swift and how to create an iOS app was a wonderful experience.

## What's next for Oyster: Make the World Yours

There are many possibilities in the future for Oyster. Further development can be done to improve the predictive ability of Oyster to guide you to a place that you not only haven't been to but also will most likely enjoy, adding sponsored events/locations, and opening up potential locations to use user submissions.