Skip to main content
Skip to main content

Quantitative methods · Craving research · Tools for researchers

Ethan O. Kile

Ethan O. Kile

Ethan O. Kile

Open to research, data science, and UX research internships

Quantitative

Regression · SEM · multilevel modeling · multivariate analysis · time series · dynamical systems · regime-switching models · Bayesian statistics · generative AI for qualitative analysis & NLP · computer vision · data mining · machine learning

Technical

R · Python · C# · SQL · SPSS · Mplus · JAGS · Docker · Azure · PyTorch · Hugging Face · Git · Shiny · LaTeX · REDCap · Qualtrics · HTML/CSS · JSON · YAML · Power BI · Microsoft Office · APIs · ggplot · pandas · Excel · HPC via SLURM

Design

Blender · GIMP · Photoshop · Figma · Framer

I’m a PhD candidate in Human Development & Family Studies (Quantitative Methodology Core) at Penn State. Half of what I do is modeling substance use craving. The other half is building tools that make research data reproducible and accessible, including to non-technical stakeholders.

A researcher. A maker. Always a little curious.

About Me

I’m Ethan O. Kile, a PhD candidate in Human Development and Family Studies at Penn State, focused on quantitative methods. Before Penn State, I earned my BA in psychology at Vermont State University.

My research focuses on modeling substance use craving, a fast-moving, non-stationary, oscillating process that may arise and dissipate suddenly. Half of my research applies new methods to it, from multilevel dynamical systems to natural language processing and computer vision for detecting craving triggers. The other half is pure methods work through simulation studies and package development.

The tools side matters just as much to me. I build data-description standards, automated documentation tools like WearITReadR, and quality-checking pipelines that make research data reproducible and accessible to the people who depend on it. I write a lot of code along the way: 300+ commits on GitHub in the past year.

Outside of research

Outside of Work

When I'm not working I enjoy game development, making music on guitar, and playing soccer.

Research Projects

Modeling craving in recovery, plus the data systems, machine learning, and statistical models behind it.

Half of my work: tools, pipelines, and applied data science.

Design Portfolio

Three design walkthroughs, start to finish: a research toolkit, an LLM review analysis, and retro 3D asset creation.

Half of my work: tools, pipelines, and applied data science.

Research Projects · Data systems, machine learning & modeling

Research Projects

Research Projects

Research Projects

Modeling craving in recovery. Substance use craving is a fast-moving, non-stationary process that can arise and dissipate suddenly, which makes it a hard modeling problem. Half of my research applies new methods to it. The other half is pure methods work through simulation studies and package development.

01 / Data systems & standards

Making complex data describable, checkable, and shareable.

Human-facing standard · Variable page
  1. Variable nameAs it appears in the dataset
  2. Human-readable name
  3. Question textExactly as it is presented to the participant
  4. DescriptionIn layman's terms, or a citation to a longer explanation
  5. How the data was obtainedSensing, survey, observation, digital slider…
  6. Type of dataNumeric, categorical, continuous…
  7. Possible valuesIncluding item codes, e.g. 0 = not at all
  8. Skip logicFor whom and when this is collected
Machine-readable spec · study.json v0.1.0
{
"Item.ID": "item_stress_01",
"Question.ID": "stress_q1",
"Question.Long.Name": "Perceived Stress Item 1",
"Question.Text": "How stressed have you felt in the past hour?",
"Question.Description": "A self-report measure of perceived stress on a scale from 0 (not at all) to 100 (extremely).",
"Question.Type.Display.Name": "Slider",
"Item.Type": "Question",
"Data.Type": "numeric",
"responseKey": [
{ "value": "0", "definition": "Not at all" },
{ "value": "100", "definition": "Extremely" }
],
"Conditional.Info": {
"Conditional.Master.Item.ID": null,
…
}
}

Data-description standard: human- and machine-readable

A standard for describing complex data and study designs, in two forms: a human-facing version researchers read, and a machine-readable JSON specification that software can run on. WearITReadR and its AI study generator are built on the JSON spec. I also mentor undergraduate research assistants who collect the scale metadata it documents.

JSON Schema · metadata standards · documentation

WearITReadR’s AI study generator

Qualtrics survey builder

AI study generator: feasibility trial against Qualtrics

One of WearITReadR’s functions is an AI study generator that builds a study from the JSON spec. I ran a feasibility, acceptability and usability trial comparing it with Qualtrics, the familiar way researchers build studies.

Feasibility · acceptability · usability · LLM · Shiny

Multi-site data pipeline

Collect across sites

  • Qualtrics
    Online surveys
  • REDCap
    Study records and assessments
  • WearIT
    Smartphone EMA
  • Multiple study sites
    Different apps, formats and schedules

Clean and check

  • Aggregate
    Align and merge data across apps and sites
  • Outlier detection
    Autoencoder flags unusual records
  • Quality checks and cleaning
    Rules-based checks, then fixes

Report

  • Data-quality reports
    What was flagged and what changed
  • Codebooks and data descriptions
    Documented, reusable datasets

Data pipelines for a multi-site clinical trial

Data-description and quality-checking pipelines for three public-health studies, including a multi-site clinical trial that aggregates data across collection apps, with autoencoder-based outlier detection. I also cleaned the data and wrote the codebook for one study.

Data pipelines · quality checks · autoencoders

02 / Machine learning & AI

Turning messy, real-world data into usable signals.

NLP & generative AI for craving-state prediction

Using natural language processing and generative AI to predict craving states from free-response text. The plots show the 50 words most associated with higher craving (left) and lower craving (right).

NLP · generative AI

[Full Name] — UX research, design & quantitative methodsA person seen from behind wears glasses with a small camera. The camera's field of view projects to a frame showing a scene with a person, whose face is blurred, and an object, each inside a detection box. Steps: YOLO person and object detection, face de-identification, vision-language model scene context, then a craving-trigger flag.PROTOTYPE SKETCHEgocentric video from smart glassesRECobjectperson · face blurredVLM: scene contextcamera on the glasses1YOLO person & object detection2De-identify faces3VLM scene context4Craving-trigger flag

Computer vision for egocentric video

An AI data-processing pipeline for video from smart glasses: YOLO-based de-identification of participants, and a craving-trigger detector that pairs YOLO person and object detection with a vision-language model for scene context.

YOLO · vision-language models · computer vision

[Alt text: describe the personas and the review evidence behind them]

Machine learning for flight delay prediction

Built and compared machine-learning pipelines for predicting the proportion of flights delayed: full and Boruta-selected multilevel models, k-nearest neighbors (k = 17), and gradient boosting with and without weather data.

Multilevel models · KNN · gradient boosting · Boruta

[Alt text: describe the personas and the review evidence behind them]

Boruta feature selection for multilevel data

Modified the Boruta random-forest algorithm to identify features and interactions in multilevel data, then ran HPC simulations evaluating its feature classification across conditions.

Random forests · Monte Carlo Simulation · HPC / SLURM

03 / Statistical modeling

Modeling how people and processes change over time.

Finding · schematic
Daily craving
Measured every day
Predicts use
Substance use
Weekly craving
Measured once a week
Not predictive
Substance use

The same construct behaves differently depending on the time scale it is measured at.

Craving across time scales

Multilevel dynamical systems models for a fast-moving, non-stationary, oscillating process that can arise and fade suddenly. Measured daily, craving predicted substance use; measured weekly, it did not.

Multilevel Modeling

Study design · schematic
Recruited in person
Recruited online
Same measures, compared across two studies
Multigroup SEM
Nested model comparisons (OpenMx)
Multilevel VAR networks
Day-to-day dynamics (RJAGS, dynr)
Where recruitment channel biased the data

Recruitment effects: in person vs. online

Compared participants recruited in person with those recruited online, across two studies, to test how recruitment channel biased the data. Used multigroup SEM with nested model comparisons, plus multilevel vector-autoregressive network models.

OpenMx · RJAGS · dynr · Dynamical systems

Predicting daily recovery commitment · multilevel Tobit model
Predictorbtp
Craving, person level (statistically significant)−0.63−6.88< .001
Craving, daily (statistically significant)−0.16−2.52.012
Negative affect, person level−0.04−0.84.401
Negative affect, daily (statistically significant)−0.28−8.30< .001
Time in recovery (statistically significant)1.373.17.002
Daily negative affect × time in recovery (statistically significant)0.052.26.024
Daily craving × time in recovery−0.01−0.35.729

N = 206 participants, 1,769 days. Outcome: daily recovery commitment (0–100). Filled dots mark effects significant at p < .05. Also adjusted for age, sex, race, household income, education, and study day.

Craving, negative affect, and daily recovery commitment

206 people in recovery completed 10 days of smartphone diaries (1,769 days in total). Higher craving, both day to day and on average, and higher daily negative affect went with lower commitment to recovery that day, and the negative-affect link was weaker for people who had been in recovery longer. Because 42% of commitment ratings sat at the scale maximum, I used multilevel Tobit models to handle the ceiling effect.

Multilevel Tobit models · censReg · R · Wear-IT

Design Portfolio

01 / From alpha to finished product

WearITReadR

WearITReadR

WearITReadR

From a functional alpha to a finished research toolkit. WearITReadR brings data access, study documentation, flowcharts, and AI-assisted study creation into one interface.

Role

Researcher & designer

Timeline

August 2024 - Present

Tools

Shiny · Wear-IT · LLM · Qualtrics · JSON · Python · R · YAML · CSS · JavaScript

Methods

Prototyping · wireframes · UI mockups

The project in brief

Start with the working demo, then follow my design process: from the first functional prototype, through wireframes and mockups, to the finished product. One of the tool’s functions is an AI study generator that builds a study from the JSON spec; its feasibility trial is in Research Projects.

Try it first

The finished toolkit, live.

5,700+

Lines of source code across R, Python, and CSS

285

Commits I’ve authored since May 2024

31

R source files in the package

Try it yourself: this is a clickable recreation of the app. Use the left panel to move between tools, open the codebook, search the data dictionary, build a flowchart, or ask the AI Study Assistant for a schedule. It loads the real Daily Diary documentation from the project’s GitHub repository, and nothing you type is sent anywhere.

Wear-IT ReadR
Interactive demo · real study documentation

Purpose of this tool

This is a human-accessible tool to help pull data and generate codebooks for Wear-IT users.

Set App Working Directory

Use this to set the working directory of the app. It will reference this directory when saving and viewing codebooks, data dictionaries, and study flowchart exports.

Tip: use the panel on the left to move between tools, just like in the real app.

My design process · 01 / Prototype

Start with the core tasks.

The first alpha made the essential functions visible: pulling Wear-IT data, selecting codebook sections, and entering study metadata. These screens capture the starting point before a shared application layout took shape.

Alpha / Home. The first prototype introduced the tool’s purpose with a simple top navigation.

Alpha / Home

The first prototype introduced the tool’s purpose with a simple top navigation.

Alpha / Data pull. Study ID and API token fields made the initial Wear-IT data-pull workflow visible.

Alpha / Data pull

Study ID and API token fields made the initial Wear-IT data-pull workflow visible.

Alpha / Codebook generator. An expandable selection tree and study metadata fields formed the early codebook generator.

Alpha / Codebook generator

An expandable selection tree and study metadata fields formed the early codebook generator.

The starting point / A small set of functional screens, before wireframing the broader research workflow.

My design process · 02 / Wireframes

Give every task a place.

Low-fidelity wireframes mapped six core views around a consistent sidebar. Survey selection, previews, generation, and downloads each received a clear place in the interface, without committing to visual polish too early.

Wireframe / Home. A shared sidebar connected survey selection with the tool’s main research tasks.

Wireframe / Home

A shared sidebar connected survey selection with the tool’s main research tasks.

Wireframe / Data pull. Survey selection, a data preview, and the pull-data action were grouped into one screen.

Wireframe / Data pull

Survey selection, a data preview, and the pull-data action were grouped into one screen.

Wireframe / Codebook generator. Source data, codebook options, and generation were separated into distinct steps.

Wireframe / Codebook generator

Source data, codebook options, and generation were separated into distinct steps.

Wireframe / Codebook viewer. A contents panel sat beside the codebook preview, with a dedicated download action.

Wireframe / Codebook viewer

A contents panel sat beside the codebook preview, with a dedicated download action.

Wireframe / Data dictionary. The dictionary view organized variables, types, and descriptions into a table.

Wireframe / Data dictionary

The dictionary view organized variables, types, and descriptions into a table.

Wireframe / Flowchart. Survey selection and a simple start-to-end diagram established the flowchart view.

Wireframe / Flowchart

Survey selection and a simple start-to-end diagram established the flowchart view.

My design process · 03 / Mockups

Make the toolkit feel like one product.

The visual mockup explored a common application shell across six views: navigation, forms, document previews, data tables, and survey logic. This is the design exploration, shown separately from the implemented screens that follow.

UI mockup / Research toolkit. A six-screen visual exploration brought navigation, forms, document previews, tables, and survey logic into one visual system.

UI mockup / Research toolkit

A six-screen visual exploration brought navigation, forms, document previews, tables, and survey logic into one visual system.

My design process · 04 / Final product

The finished product.

The finished interface brings data access, codebooks, data dictionaries, study flowcharts, and the AI Study Assistant together in one shared application shell. Select any screenshot to view it at full size.

Finished product / Home. The WearITReadR home screen introduces the toolkit and provides a working-directory selector.

Finished product / Home

The WearITReadR home screen introduces the toolkit and provides a working-directory selector.

Finished product / Data pull. The finished data-pull screen groups study credentials, saved-key selection, a Wear-IT endpoint, and the primary pull action.

Finished product / Data pull

The finished data-pull screen groups study credentials, saved-key selection, a Wear-IT endpoint, and the primary pull action.

Finished product / Codebook generator. Codebook options and study metadata appear side by side within the shared application shell.

Finished product / Codebook generator

Codebook options and study metadata appear side by side within the shared application shell.

Finished product / Codebook viewer. The document viewer displays a generated study codebook, including its contents and variable pages.

Finished product / Codebook viewer

The document viewer displays a generated study codebook, including its contents and variable pages.

Finished product / Dictionary generator. A dedicated action generates a data dictionary from the data pulled into the app.

Finished product / Dictionary generator

A dedicated action generates a data dictionary from the data pulled into the app.

Finished product / Dictionary viewer. The dictionary table exposes question text, response types, missingness codes, ranges, and response labels.

Finished product / Dictionary viewer

The dictionary table exposes question text, response types, missingness codes, ranges, and response labels.

Finished product / Study flowchart. Survey selection, flowchart generation, and PNG export sit above the branching survey diagram.

Finished product / Study flowchart

Survey selection, flowchart generation, and PNG export sit above the branching survey diagram.

Finished product / AI Study Assistant. Configuration and a chat-based prompt support creating or changing a study within the same toolkit.

Finished product / AI Study Assistant

Configuration and a chat-based prompt support creating or changing a study within the same toolkit.

Design Portfolio

02 / LLM review analysis

From Reviews to Design Recommendations

From Reviews to Design Recommendations

From Reviews to Design Recommendations

I scraped 100 Amazon reviews of a cat toy and used a local language model to summarize sentiment, pull out recurring themes, code every review for them, and turn the results into design recommendations.

Role

Analyst & developer (team project)

Tools

Python · Selenium · pandas · Llama 3.1 via Ollama

Methods

Web scraping · LLM theme coding · sentiment analysis

The project in brief

Collected: 100 reviews of a cat teaser wand. Analyzed: overall sentiment and five recurring themes, with every review coded yes/no for each theme. Made: three recommendations for improving the product.

01 / Design process

From raw reviews to recommendations.

I scraped the reviews with Selenium, then gave the full set to Llama 3.1 to summarize overall sentiment, name five recurring themes, and suggest three product improvements. A second prompt coded each of the 100 reviews for each theme, so every theme came with a count of how often it appeared.

[Alt text: describe the journey stages, pain points, and supporting review evidence]

The product: a cat teaser wand with 1,144 ratings averaging 3.6 out of 5, split between 5-star (49%) and 1-star (17%) reviews.

02 / Findings

Cats loved it. The hardware let owners down.

Overall sentiment was mixed. Many reviewers said their cats loved the toy and its attachments, but they were frustrated by the short string, flimsy materials, and a reel that was hard to use or broke, and several would not recommend it.

How often each theme appeared in 100 reviews
  • Praise: Cats love the attachments and variety of toys55 of 100
  • Complaint: Disappointed despite initial excitement55 of 100
  • Complaint: Poor durability and quality53 of 100
  • Complaint: Reel mechanism hard to use or not working49 of 100
  • Complaint: String too short to use like a fishing pole42 of 100

Themes were named by Llama 3.1, then every review was coded yes/no for each one. A review can match several themes, so counts don't add up to 100.

“Great concept, horrible execution.”

Title of a 1-star review, October 2022

03 / Recommendations

Three fixes the reviews point to.

The model's three recommendations each line up with a recurring complaint, so every fix comes with the share of reviews behind it.

Longer string

Make the string longer or adjustable. A too-short string came up in 42 of 100 reviews.

Sturdier reel

Redesign the reel so it works reliably and doesn't break. Reel problems came up in 49 of 100 reviews.

Better materials

Replace the cheap plastic with more durable materials. Poor durability and quality came up in 53 of 100 reviews.

Design Portfolio

03 / Retro asset creation for 3D games

Retro 3D Asset Creation

Retro 3D Asset Creation

Retro 3D Asset Creation

Retro-style assets for a low-poly snowboarding game I built solo in Unity: a hand-lettered logo, menu screens, and pixel-textured mountain scenery.

Role

Solo developer & designer

Tools

Unity · C# · GIMP

Methods

Low-poly assets · pixel textures · hand lettering

The project in brief

Made: a hand-lettered logo, menu art, and pixel-textured scenery for a retro low-poly snowboarding game. Built: the game itself, solo, in Unity and C#.

01 / Asset creation

Building a retro 3D world.

I created the game's visual assets to feel like a retro console title: an original logo developed from reference gathering through hand lettering to the final mark, the menu screens, and pixel-textured mountain scenery around low-poly props.

[Alt text: describe the gameplay and controller interaction shown in the GIF]

Title screen: the hand-lettered 2340° logo over a mirrored, pixel-textured mountain backdrop.

[Alt text: describe the gameplay and controller interaction shown in the GIF]

Course scenery: pixel-textured mountains, a snow-capped fence, and a wooden kicker ramp on a low-poly slope.

Good questions start with a conversation.

Let’s make something meaningful.

I’m open to research collaborations and internships in quantitative methods, data science, and UX research, especially work that helps people make sense of complex, real-world data. If that sounds like your team, I’d love to hear from you.

Research questions, side projects, or a good conversation — my inbox is open.