About Us & Our Story

About Talkready

This project is an interactive website designed to support people with social anxiety by offering a safe and low-pressure space for social rehearsal. Through a series of everyday conversational scenarios—such as starting small talk, making requests, or responding to others. The work allows users to practice communication without judgment or performance anxiety.

Unlike conventional training tools that focus on correctness or outcomes, this project deliberately removes scores, rankings, and “right answers.” The system does not evaluate whether a response is good or bad. Instead, it provides gentle prompts that help users begin, continue, pause, or revise a conversation at their own pace.

Scenario cards are used to present different social situations and serve as entry points into conversational rehearsal. Rather than outlining a complete context or prescribing a dialogue flow, each card offers a brief prompt that introduces a possible communicative state, inviting users to imagine and fill in the details themselves.

The chatbot on this site is designed as an adjustable language support tool rather than a system that speaks on behalf of the user. During interaction, users can choose to rewrite their messages into shorter, more polite, or more confident versions, allowing them to explore how different tones and structures might feel in a social context. These rewrites are not presented as better or more correct answers, but as optional variations that can be kept, modified, or discarded at any time. 

During development, I encountered a key issue: when the user entered short intent phrases (e.g., “ask about lecture / ask about ddl”), the model sometimes interpreted them as questions addressed to the assistant, producing assistant-like replies such as “Sure, what are your questions?” rather than drafting a message the user could send to another person. In addition, under unstable network conditions or API quota/response irregularities, the model could return incomplete JSON, which triggered a “Load failed” error in the UI. To ensure stable demonstration and consistent outputs, I implemented intent detection and normalization in the backend (rewriting short intents into explicit drafting tasks and enforcing a single placeholder like [your question] when details are missing), and added a fallback strategy: if the API fails or the output is invalid/unhelpful, the system automatically switches to locally generated template drafts, ensuring the app always returns a sendable reply with alternative options.