--- https://elaraliu.com/ --- # Home Landing page for Elara's Portfolio with overview, highlight news, and navigation to research and projects. High-level introduction and current status. --- https://elaraliu.com/cv --- # CV | Elara's Portfolio Authoritative record of Elara Liu's publications, positions, experiences, and timelines (via embedded PDF). --- https://elaraliu.com/research --- # Research | Elara's Portfolio Selected research projects for Elara Liu, with methods, publications, roles, and venues. --- https://elaraliu.com/projects --- # Projects | Elara's Portfolio Technical and infrastructure projects relevant to Elara Liu's research practice. --- https://elaraliu.com/research/caregivers-hci-systematic-review --- # Designing With Caregivers: Power, Involvement, and Relations in Health-Related HCI This research project is currently underway and targets submission to CHI 2027. It exploring the dynamics of power, involvement, and relationships in health-related Human-Computer Interaction (HCI) design processes involving caregivers. --- https://elaraliu.com/research/jubilee-llm --- # Coach-Style LLM Assistant for Safe Lab Automation on the Jubilee Platform ## Overview Under the **joint supervision of Dr. Nadya Peek (UW)**, I am exploring how an LLM can coach, rather than replace, non-programmer scientists using Jubilee, an open-source multi-tool lab automation platform. Many users understand their biology deeply but struggle with the Science Jubilee Python library; my approach frames this not as a simple “natural language to code” problem, but as a **mixed-initiative coaching task**. The assistant translates plain-English goals into machine steps while preserving user control, ingesting device manuals and calibration notes to compile goals into code that only touches verified APIs. Crucially, the system automatically inserts **dry-run simulations and safety checks** before any real motion occurs. I focused heavily on **iterating on failure cases**: whenever simulations revealed unsafe trajectories or ambiguous device states, I treated them as design opportunities—tightening constraint representations and adjusting how the assistant explains trade-offs. The interface logs every assumption for audit and exposes generated code to invite inspection rather than hiding it. Following approval from the UW IRB, and building on pilot deployments that reduced invalid steps, I am now designing a user study to evaluate task success and safety violations, aiming to establish a recipe for **dependable, documentation-grounded automation tools** in scientific research. --- https://elaraliu.com/research/llm-imu-har --- # Smartwatch IMU foundation model for human activity recognition ## Overview In Prof. Ahuja’s lab, I am tackling a persistent gap in human activity recognition: models trained on a single IMU dataset often look impressive on their home benchmark yet fall apart when the watch, sampling rate, or population changes. To push against that brittleness, I started by **aggregating and harmonizing multiple public smartwatch datasets**, aligning device frames, reconciling sampling rates, and negotiating a shared label ontology that can express each dataset’s idiosyncratic activity set without collapsing everything into vague catch-alls. A lot of the early work was spent iterating on these choices—discovering where alignment conventions disagreed, where resampling quietly distorted motion patterns, and where label merges hid important distinctions—until simple baselines could at least behave sensibly across held-out datasets. On top of this common substrate, I am **pretraining large sequence models**—transformer-style architectures and time-series variants of vision models—using self-supervised objectives such as masked modeling and contrastive invariance. The evaluation pipeline is explicitly designed to stress generalization: leave-one-dataset-out and unseen-device protocols, plus planned ablations that vary window length, sampling rate, augmentation, and sensor stacks to isolate which design decisions actually move the needle. When early results exposed failure modes on particular datasets, I treated them as prompts to revisit both the harmonization and the objectives rather than just tuning hyperparameters, aiming for a training recipe that is robust, reproducible, and well-documented. The long-term goal is a **portable IMU foundation model** that researchers and practitioners can fine-tune across devices and populations, with clear guidelines for adapting it to wellness and community settings instead of yet another leaderboard-only model. --- https://elaraliu.com/research/human-ai-tool-account-difference --- # Regional Experience Differences (Under Review) This project is currently under review at UIST 2026. It focuses on understanding how user experiences and preferences differ across regions, leveraging online reviews and location-based services to inform place-aware recommender systems. --- https://elaraliu.com/research/cross-cultural-stress-copings --- # Cultural Underpinnings of Stress Relief: Exploring Cross-Cultural Coping Strategies ## Overview Within my advisor, I co-designed and implemented a **mixed-methods study** that starts from a deceptively simple question—how do students from different cultural backgrounds actually relieve stress in their day-to-day lives—and pushes past stereotypes using both survey data and open-ended narratives. I helped **build and iterate the survey instrument**, piloting it with early participants and refining wording and scales whenever items produced ambiguous or contradictory patterns in ANOVA and regression models, working with co-authors and my advisor until we could **separate culture, gender, and convenience effects** in a defensible way. On the qualitative side, I developed a **lightweight analysis pipeline** that combines hand coding with _LDA-style topic modeling_ and _SBERT-based similarity analysis_, treating disagreements between algorithms and human readings as signals to revisit our categories rather than letting any single method act as ground truth. The final picture shows that while students raised in East Asian contexts do lean more toward structured introspection and those from Western backgrounds report more social and leisure activities, many **weave together cross-cultural practices** whenever schedules, spaces, or peers make them viable—an insight that now shapes how I think about designing stress interventions that respect cultural histories without freezing people inside them. ### Selected visuals ![Coping preferences across cultural backgrounds](/images/research/ctross-culture/survey-data-1.png) ![Openness to cross-cultural strategies](/images/research/ctross-culture/survey-data-2.png) --- https://elaraliu.com/research/mhealth-scoping-review --- # Mapping the Role of Wearable and mHealth Technologies in Stress: A Scoping Review ## Overview Working with my advisor’s lab, I led the design and execution of a structured scoping review that asked a deceptively simple question: how are wearable and mHealth technologies really being used to capture and intervene on stress in practice? I built and iterated on a search and coding protocol across PubMed and IEEE Xplore, refining inclusion criteria, stress definitions, and data-extraction templates whenever borderline papers or conflicting labels broke the scheme. During dual-review screening, I regularly revisited our categories with my co-reviewer and advisor—especially when studies mixed HRV, cortisol, and app-based self-reports in ways our initial framework could not neatly describe—until we reached a stable taxonomy of study designs, sensors, and outcomes. The final map shows a field dominated by small, HRV-centered pilots with short follow-up, scattered use of hormonal markers and telemedicine, and limited attention to underserved populations, and it now anchors how I think about designing next-generation, wearable-driven stress interventions that are both methodologically sound and scalable beyond narrow laboratory samples. --- https://elaraliu.com/research/xai-cvd-sleep-data --- # Explainable AI–Driven Integration of Health and Sleep Metrics for Enhanced Cardiovascular Risk Prediction As part of the UCI ICS Honors Program, I designed and implemented an end-to-end pipeline on the Wisconsin Sleep Cohort, starting from cleaning and reshaping 230+ clinical and polysomnography variables and converging on a compact, stable set of predictors. I iteratively refined the feature set, regularization strategy, and evaluation protocol whenever models overfit or produced confusing explanations, discussing edge cases with my advisor until we could surface sleep-related metrics as clear, defensible signals rather than opaque covariates. The final framework lets clinicians see how changes in sleep efficiency, non-REM duration, and onset latency shift cardiovascular risk estimates, and it motivated follow-up conversations about extending the approach to wearable-derived sleep data and broader, more diverse cohorts. --- https://elaraliu.com/projects/airtable-ts --- # Airtable TS ![Airtable TS docs landing page — tiny, fetch-based Airtable client](/images/projects/airtable-ts/hero.jpeg) ### Overview Airtable TS started from a pattern I kept seeing in my own projects and in friends’ research setups: Airtable bases were doing real analytical work—organizing studies, logging experiments, tracking deployment metadata—but the surrounding code was brittle. The **official Airtable JS SDK** had been effectively frozen for years, still relied on deprecated Node-only APIs such as `url.parse`, and carried design assumptions from an older callback-driven ecosystem. That made it awkward to use in modern, isomorphic apps running across Node, browsers, Workers, and test environments—exactly the kinds of contexts I care about for research tools. I treated this as a developer-facing HCI problem: how do we make Airtable-backed analyses **feel predictable and reviewable**, instead of a tangle of ad-hoc HTTP calls and subtle runtime failures? Airtable TS wraps the Web API in a **TypeScript-first façade** that mirrors the familiar `Airtable.configure(...); Airtable.base(...)` style, so existing mental models still apply, but the surface is strongly typed and fully promise-based. Base and table helpers are parameterized by field schemas, so editors can show completions and catch mismatches before a script ever runs. Underneath that façade is a small `AirtableClient` that exposes records, metadata, and webhooks directly; this lets more advanced users treat the client like infrastructure while still benefiting from the same typed contracts and retry logic. The docs site is generated from TypeScript sources, so signatures and “Defined in …/file.ts” links act as **documentation-as-interface**—you can see exactly what the library believes the API to be. For data-heavy work, I added an **optional record-caching layer** to reduce redundant reads when you’re iterating on analyses or dashboards. A pluggable `AirtableCacheStore` interface supports custom backends (e.g., KV stores), and the built-in in-memory implementation uses LRU + TTL with automatic invalidation when mutations occur. Configuration is consistent: caching can be enabled globally via `Airtable.configure`, per-base when you call `Airtable.base`, or directly on `new AirtableClient`, so the same code can scale from quick scripts to longer-running services. The library is built and bundled with tsdown, tested with Vitest against a V8-style environment, and released via npm with coverage sitting around 99%, which makes it feasible to **treat releases as research artifacts**—tagged versions are signed, documented, and safe to pin in pipelines. Overall, Airtable TS is meant to be boring glue: a small, opinionated toolkit that replaces an aging SDK with a modern, type-safe layer tuned for Airtable-based research and production work. --- https://elaraliu.com/projects/gravatar-worker --- # Gravatar Worker ## Overview Gravatar Worker started as a very practical annoyance: profile images on sites I cared about depended on a remote Gravatar origin that was often slow, served only PNGs, required precomputed hashes instead of emails, and in regions like mainland China could be completely unreachable or flaky across different CDNs. At the same time, many developers I know wanted to run their own gravatar-like endpoint—close to their users, with modern image formats and predictable caching—without rebuilding the whole protocol. I treated this as an infrastructure HCI problem: how do you make **“just show me an avatar for this email”** into a simple, reliable, and self-hostable affordance for developers and their users? I implemented Gravatar Worker as a **Cloudflare Workers + Hono** service that exposes a small, gravatar-compatible API surface. It supports MD5 and SHA-256 hashes for drop-in compatibility, but also adds a `GET /avatar?email=` endpoint where the email is safely lowercased, trimmed, and hashed server-side instead of asking every caller to do that work. The worker runs format negotiation based on the browser’s `Accept` header, using a WebAssembly encoder to serve **AVIF when possible, WebP as a fallback, and the original JPEG as a last resort**, so avatars stay crisp and light on modern networks. To avoid hammering upstream origins and to make things feel instant in real deployments, I designed a layered **edge + browser caching strategy** with tuned TTLs and `stale-while-revalidate` for hits, shorter lifetimes for 404s, and explicit `Vary: Accept` and `ETag` headers so different formats can be cached correctly without surprising clients. From a developer’s point of view, the goal is to make spinning up your own gravatar-style CDN as low-friction as possible: configure a Worker, point your app’s avatar URLs at `/avatar/:hash` or `/avatar?email=…`, and let the proxy handle hashing, origin fetching, format conversion, and caching. Because it runs on the edge, teams can deploy their own instances closer to users in regions where `gravatar.com` is slow or blocked, instead of relying on a single global CDN. In practice, Gravatar Worker ends up being a small but important piece of **profile infrastructure**: it turns a historically fragile external dependency into something developers can reason about, tune, and move with them as their applications and audiences grow. --- https://elaraliu.com/projects/safepassage --- # SafePassage ## Overview SafePassage started from a concrete use case we heard repeatedly in client discovery and classroom discussions: people with serious medical conditions feel vulnerable when traveling abroad, especially when language barriers and unfamiliar health systems make it hard to communicate history, medications, and emergency contacts. Rather than designing yet another full-blown patient portal, I led our team in scoping the problem down to a **single, high-stakes moment**—a clinician or bystander scanning a QR code in an emergency—and asked what information, flows, and safeguards would make that interaction actually usable and safe. We framed the app around three roles: the traveler who configures their profile, the medical professional who scans it, and the emergency contacts who may need to be notified. On the HCI side, this led us to a read-only, **privacy-preserving QR profile**: the QR code opens a minimal, emergency-focused view of the traveler’s conditions, allergies, and medications, translated into the destination language, without exposing full account details or edit controls. The scanning view prioritizes legibility and triage—clear sectioning, large text for critical fields, and language that matches what clinicians told us they look for first—while the traveler-facing side gives people control over what appears and who gets alerted. On the engineering side, I worked with the team to implement SafePassage as a **React + Zustand app** backed by Firebase, with a lightweight backend built using **Hono and serverless functions**. The frontend generates QR codes that encode only the information needed to retrieve a profile; the backend looks up the corresponding record, serves a localized, read-only view, and, when configured, sends SMS messages to the traveler’s emergency contacts to indicate that their code was scanned. We kept the codebase structured for field studies—clear separation of concerns, environment-based configuration, and a deploy path that runs today on Cloudflare Workers or Firebase Hosting—so that SafePassage can be used in small pilots with real travelers and clinicians, not just in the classroom. --- https://elaraliu.com/projects/zl-react --- # @zl-asica/react ## Overview I built **@zl-asica/react** after running into the same friction points across several React projects: hooks that quietly break on the server, ambiguous APIs that invite subtle bugs, and documentation that drifts from the code it’s supposed to describe. I framed the library as a developer-facing HCI problem—how to give React teams **clear affordances** around server vs. client behavior, and how to make everyday tasks like event handling, viewport checks, and storage state feel predictable instead of fragile. The result is a small set of hooks and utilities where the **API surface is the interface**, and types are used to shape developers’ mental models rather than just to satisfy a linter. Design-wise, the library codifies the **server–client boundary** up front: DOM-dependent hooks live in the main entry, while SSR-safe utilities are exported from a separate `@zl-asica/react/utils` module that never touches `window` or `document`. This makes server-safe usage a first-class path instead of an afterthought of `typeof window !== 'undefined'` checks scattered in app code. Functions like `useEventListener` expose strongly-typed event maps so developers can only subscribe to valid events on valid targets, turning what is usually a runtime error into compile-time feedback. All public APIs are documented via TypeDoc-generated pages that show full signatures and source locations (“Defined in …/useArray.ts”), so behavior is inspectable and reviewable in the same way you’d inspect a UI. On the engineering side, I built and released the library with **TypeScript, GitHub Actions, and JSR**. CI pipelines build and sign artifacts, run tests, and publish to JSR (with npm-compatible installs), keeping the package at a 100% JSR quality score and explicitly marking compatibility across Cloudflare Workers, Node, Bun, and browsers. Tagged releases are mirrored on Zenodo for stable academic citation, and the docs site is version-aware so people can see which API surface belongs to which release. Taken together, @zl-asica/react is less a grab-bag of hooks and more a **small, opinionated toolkit** for React apps that need server awareness, typed ergonomics, and documentation that behaves like a trustworthy interface for developers. ### Selected visuals ![CI automation on GitHub Actions for building, testing, signing, and publishing releases](/images/projects/zl-react/ci-automation.png) ![JSR package page showing 100% score and multi-runtime support badges](/images/projects/zl-react/jsr-badges.png) ![Typed useEventListener signature illustrating constrained event maps and targets](/images/projects/zl-react/useeventlistener.png) --- https://elaraliu.com/projects/suzu-blog --- # SuzuBlog ![SuzuBlog landing preview — minimalist theme](/images/projects/suzublog/hero.png) ### Overview SuzuBlog grew out of a very practical HCI problem: I wanted a blog that was pleasant to read and easy to maintain as a researcher, but most CMSes I tried pushed me toward admin dashboards, plugin jungles, and opaque hosting. I framed the design around two kinds of users—**readers**, who need clean typography and predictable behavior, and **authors**, who need low cognitive overhead, clear provenance, and tools that won’t break three years from now. That led me to a file-first approach where each post is a Markdown file with YAML frontmatter and the entire site is governed by a single `config.yml` rather than scattered runtime settings. On the design side, I treated reading ergonomics and accessibility as baseline constraints rather than “nice to have.” The theme is intentionally quiet—sakura-inspired colors, consistent rhythm, semantic HTML, and generated SEO/OG/JSON-LD metadata—so posts read more like long-lived essays than social feeds. Policy decisions such as license, comments, analytics, and language are expressed declaratively in `config.yml`, which doubles as a kind of **configuration-as-policy artifact**: you can diff changes, audit what’s turned on, and keep academic pages reproducible without poking through UI menus. Internationalization is likewise config-driven so multilingual personal sites don’t need boilerplate code on every page. Under the hood, I implemented SuzuBlog with **Next.js (App Router), TypeScript, and Tailwind CSS**, targeting static generation and ISR for predictable performance and easy hosting. A small set of plug-in points—comments (Disqus or Twikoo), analytics, social cards—are wired through config flags instead of hard-coded, and a GitHub Action keeps downstream sites in sync with the main template while preserving content. More recently, I added support for emitting `/llms.txt`, an emerging convention for guiding assistant crawlers to canonical, plain-text sources, so my own research notes and posts can be responsibly consumed by LLMs. SuzuBlog is open source on GitHub and archived on Zenodo, and now powers my personal site and other small academic pages as a **minimal, provenance-aware blog system** rather than yet another one-off portfolio. ### Selected visuals ![Excerpt of config.yml showing site identity, i18n, and policy knobs](/images/projects/suzublog/config.png) ![llms.txt support to expose canonical content to LLM tools](/images/projects/suzublog/llms-txt.png) ![Lighthouse report illustrating static-by-default performance and accessibility budgets](/images/projects/suzublog/lighthouse.png) --- https://elaraliu.com/projects/goshsha --- # Goshsha ## Overview Goshsha began as an existing AR prototype that could overlay digital content on physical products, but the experience felt closer to a tech demo than something real shoppers—especially Gen Z—would actually use in stores. In a 20-week Informatics capstone with Prof. Matthew J. Bietz and our industry partner, I led a five-person team in treating this as an HCI problem: **how do we turn an AR capability into a retail experience that people can understand, enter, and stay with?** We met weekly with the partner and bi-weekly with our advisor, using those sessions to keep aligning the product vision with what felt realistic for first-time users navigating a busy store. In the fall quarter we effectively **restarted the UX from scratch**. I coordinated our mapping of the old flows, a short competitive scan of AR shopping and social shopping apps, and a series of Figma explorations aimed at Gen Z: a community feed where people can browse and share “Goshshas,” product pages that surface reviews, virtual try-ons, and creator videos, and a simplified sign-up/sign-in flow that leads into an optional walkthrough instead of dropping users cold into the scanner. Throughout this phase, we used feedback from our partner and professor as our primary evaluation loop, iterating whenever testers got stuck—especially on first-time navigation and understanding what “scanning a product” would do. Once the flows were stable, we shifted to the **technical implementation** on top of the existing codebase, using React Native with Expo, TypeScript, and Firebase. I focused on translating the redesigned navigation and community features into the app and on helping rework parts of the scanning and data-retrieval pipeline so scans felt responsive instead of laggy. We kept our process ticket-based in Jira, which made it easier to decompose design decisions into incremental changes—adjusting the onboarding copy, tweaking the walkthrough steps, or refining how quickly content loads after a successful scan. By the end of the course we had shipped a cohesive prototype with over forty Figma screens, a working cross-platform app, and a clearer pattern for **combining AR scanning with social, community-driven engagement** rather than treating AR as a one-off trick. ### Selected visuals [Demo video 1](https://youtu.be/muTHa8mqn1U) · [Demo video 2](https://youtu.be/gbJFdoUQjsE) --- https://elaraliu.com/projects/life-tune --- # LifeTune ## Overview LifeTune started from a simple tension I kept hearing in conversations with health-conscious friends: they were willing to track, but most apps buried them in numbers and charts. As team lead, I framed the design problem as **how to reduce data overload while still giving people enough signal to act**, and our team treated it as both an HCI and systems question. After a quick competitive analysis of existing assessment and tracking tools, we ran interviews with four groups—health enthusiasts, experienced app users, developers of health tech, and self-identified “tech-haters”—to understand not just what they logged, but where current tools broke down in their everyday routines. Across these interviews, a few patterns kept resurfacing: people wanted someone to “just tell me what to eat” instead of counting every calorie; sleep tools that could explain patterns without demanding new rituals; feedback that celebrated progress instead of nagging; and mental-health support that translated mood logs into concrete suggestions. I synthesized these into a set of design commitments: **simplify** complex data into a single health score with clear levers, **fit into existing routines** rather than invent new ones, and **motivate through visible progress** while still acknowledging emotional state. On the technical side, I translated these commitments into an end-to-end **SwiftUI app**. LifeTune aggregates inputs on activity, nutrition, sleep, and mood into a composite score that updates as users log small actions—a short walk, a better meal choice—so the interface can show how each decision moves the needle. The UI uses a compact, card-based layout and gentle visual cues instead of dense dashboards, and the recommendation layer surfaces a small set of next steps rather than long to-do lists. I iterated from mid-fidelity flows to high-fidelity prototypes and finally a working iOS implementation, revising interactions whenever testers reported confusion or found themselves ignoring features. The result is less a numbers app and more a **health companion** that tries to make “what should I do next?” legible for people at very different levels of comfort with health tech. ### Selected visuals ![Competitive analysis snapshots used to scope gaps in existing health apps](/images/projects/lifetune/Competitive-Analysis.jpg) ![Mid- and high-fidelity LifeTune prototypes informing the final SwiftUI implementation](/images/projects/lifetune/Mid-Fidelity-Prototype.jpg)