Fien De Waele Tongeren, Belgium 2H AGO

Build a Tiny HTML Research Logger Instead of Fighting a Spreadsheet Turn repeated research measurements into a simple phone-friendly interface instead of making participants wrestle with spreadsheets. Some research data is simple. Collecting it often isn't. Imagine recording pain, energy, mood and a few additional variables several times during a study. A spreadsheet can technically do this. But on a phone? Open the file, find the right row, locate the columns, enter values without accidentally changing something, save and close. That's a ridiculous amount of interface for a tiny measurement. If recording how you feel takes ten seconds mentally but two minutes administratively, the tool has become part of the research burden. So I asked: What is the smallest interface someone actually needs when logging an observation? My answer was a tiny HTML page that works on both phone and desktop. 1. Separate the interface from the dataset Participants shouldn't need to interact with rows, columns or database structures. They should see a few simple fields: Pain, Energy, Mood, Optional Note and Save. Behind the interface, each submission becomes a structured record containing the measurements, a timestamp and any optional context. The researcher gets organised data. The participant gets simple controls. 2. Define the research measures first Before asking AI to build anything, establish what you're measuring. Which variables matter? What does each scale mean? Which values are allowed? Should measurements remain comparable over time? These are research decisions, not interface-design decisions. AI can help implement your measurement system, but shouldn't quietly invent the methodology. 3. Design for repeated use A questionnaire completed once can tolerate some friction. A logger used several times a day cannot. Make controls large enough to tap comfortably. Use readable labels, vertical layouts and obvious actions. Avoid unnecessary navigation, tiny cells and repeated setup. Design for the phone first, then let the interface adapt to larger screens. And test the fifth entry, not just the first. Something that looks elegant during development can become irritating when you're tired, distracted or recording yet another observation. The ideal repeated action is almost boring. That's a compliment. 4. Automate the invisible work Participants shouldn't have to enter information the system already knows. A logger can automatically generate timestamps, record identifiers and technical metadata. Each submission should become one coherent record. Show a clear confirmation when saving succeeds and prevent accidental duplicates. Keep optional notes available without turning every measurement into a diary assignment. Don't make participants do the database's job. 5. Keep the interface neutral A research logger is a measurement instrument. Its colours, labels, ordering and controls shouldn't subtly suggest which answers are desirable. Likewise, the logger doesn't need to interpret someone's measurements or announce that their mood seems lower on Tuesdays. That's analysis, not collection. First gather observations reliably. Interpret them later using appropriate research methods. 6. Decide where the data lives A single HTML file can provide the interface without requiring a full application. But HTML alone doesn't provide persistent storage or synchronisation. Browser storage may work for a local prototype, although it has limitations. For research involving several devices, participants or longer periods, you'll need suitable storage and export options. A phone and laptop displaying the same interface don't automatically share observations. Keep the dataset consistent and exportable, for example as CSV. For sensitive information, include appropriate privacy and security safeguards. 7. Build only what's necessary It's tempting to expand a tiny logger into an entire platform. Dashboards! Charts! Profiles! Notifications! Accounts! Perhaps later. Start with Open → Measure → Save. Test the process repeatedly on phone and desktop. Improve whatever causes genuine friction. You can enlarge buttons or rearrange the layout without changing the study. But changing a measurement scale is a research-design decision, not a cosmetic update. The workflow Define the variables and scales → ask AI to build a responsive HTML logger → add automatic timestamps and structured records → choose suitable storage and export methods → test repeated logging → refine usability without changing the measurements. Why this works A spreadsheet is excellent at displaying a dataset. That doesn't make it the best place to create one. Researchers think in variables, records and analysis. Participants simply need to answer the question in front of them. Those shouldn't have to be the same interface. Sometimes the best research tool isn't a sophisticated platform. It's a tiny page that gets the spreadsheet out of the participant's way.