Research Workflow Suite User Guide

Suite overview

About the Research Workflow Suite

The StatsWithR Research Workflow Suite is a growing collection of browser-based applications for common research tasks, including reviewing REDCap project definitions, checking and cleaning research data, and preparing publication tables from major statistical software families.

The applications can be used independently. A project that begins in REDCap may eventually use several of them, while a researcher who already has completed analyses may use only one publication-table application.

How to use this guide

Start with the next chapter for shared guidance. Then read the chapter for the application you plan to use. The publication-table chapters are followed by a more detailed explanation of the common table-review workflow, projects, exports, and troubleshooting.

Shared guidance

Getting Started

Browser and device preparation

Use a current version of Chrome, Edge, Firefox, or Safari. Work on a device and in a location appropriate for the sensitivity of the research material. These applications run locally in the browser, but local processing does not remove the need to follow institutional security requirements.

Preserve the source

Keep the original dictionary, dataset, log, viewer file, notebook, or report unchanged. Work from a copy and save deliberate milestones. This makes it possible to compare changes, repeat an import, or recover if a saved session or project file is damaged or deleted.

Understand the common workflow

1. Import or restore. Load the source file, or open a saved session or project where that feature is available.
2. Review. Confirm that the application understood the file and inspect the starting summaries or extracted content.
3. Edit or correct. Make intentional changes, apply suitable rules or fixes, and use Undo/Redo where available.
4. Validate. Rerun checks and inspect warnings before export.
5. Export and archive. Save the result and supporting documentation. In Data Quality Studio, save a session; in a publication-table application, save a project when work may continue later.

Autosave, sessions, and project files

Research Data Quality Studio and the current publication-table applications provide browser autosave and a portable saved state. Data Quality Studio calls the downloaded state a session; the publication-table applications call it a project. Browser autosave may be removed by private browsing, browser cleanup, device management, or storage limits, so a downloaded session or project is better for deliberate backup, transfer, or long-term continuation. REDCap Dictionary Studio does not autosave or create a portable project file; export its corrected dictionary and supporting files before closing or reloading the page.

Navigation and workspaces

Each application is organized into tabs or workspaces. Tabs become useful at different stages of the task: overview and profile screens help you understand the starting file; issue and editor screens support investigation and correction; report and export controls, session or project controls where available, and validation screens help finish and preserve the work. Empty states normally explain what must be imported or selected before a workspace becomes active.

Large and complex files

Because processing occurs in the browser, performance depends on file size, complexity, browser memory, and device resources. Large files may take longer to load or may exceed practical browser limits. Close unnecessary tabs, use a desktop browser for demanding projects, and save checkpoints before large cleaning or formatting operations.

Undo and review

Undo/Redo protects against accidental local changes, but it is not a substitute for a project backup. After a large batch of edits or fixes, stop and review the result before continuing. This makes it easier to identify the step responsible for an unexpected change.

Application guide

REDCap Dictionary Studio

REDCap Dictionary Studio examines project-definition metadata before or during project development. It does not require participant-level data.

Preparing the input

Export the current Data Dictionary CSV from REDCap. Avoid changing the required column names or saving the file through software that may alter quotation marks, line breaks, or leading zeros in choices and codes.

Recommended workflow

1. Load the dictionary and confirm that the expected forms and fields are present.
2. Review overall findings and analysis-readiness concerns.
3. Filter the issue table to investigate critical findings, warnings, and informational notes.
4. Use Codebook Preview to inspect how the project will read to users and reviewers.
5. Make local edits or preview suitable Safe Auto-Fix actions.
6. Re-audit and review the Change Log.
7. Export the corrected dictionary, report, issue table, and codebook.
8. Test the dictionary in a development REDCap project.

Understanding findings

Critical findings are likely to affect import, project behavior, logic, calculations, or downstream use. Warnings identify concerns that deserve review. Informational findings highlight design choices that may be acceptable but should be confirmed or documented.

Editor and Safe Auto-Fix

The Editor changes only the local browser copy. Safe Auto-Fix is intended for deterministic or clearly explained repairs that can be previewed. More interpretive changes remain optional. After applying fixes, review the affected variables and the Change Log instead of relying on the score alone.

Codebook Preview

The preview helps you inspect forms, section headers, question wording, field notes, answer choices, validation settings, and matrix structure. It is useful for detecting problems that are technically valid but confusing to respondents or project staff.

Exports

The corrected dictionary preserves the required dictionary structure when the input is safe to rewrite. The report and issue export support review, while the codebook provides a readable description of the project. Structural damage such as duplicate headers or malformed quotation may block corrected export while leaving review information available. REDCap Dictionary Studio does not save a portable application project, so download the corrected dictionary and any needed supporting exports before closing or reloading the page.

Workspace guide

Readiness scores

Scores summarize patterns found in the dictionary and help prioritize review. They should be interpreted with the issue details. Repeated problems can affect many fields, while a single critical design problem may matter more than a long list of minor notes. A higher score is generally better, but a score cannot determine whether the project meets its scientific aims.

Branching logic and calculations

Logic and calculations depend on exact variable names, choice codes, operators, and parentheses. Review warnings alongside the source expression. When a correction is not deterministic, make the change intentionally in the Editor and test it in REDCap. Pay special attention to checkbox references, repeated instruments, calculated fields, and expressions copied from older projects.

Example use

A data manager receives a draft dictionary with inconsistent yes/no coding, missing validation settings, several broken logic references, and lengthy survey labels containing legacy HTML. The manager audits the file, filters the issue table by form, previews safe repairs, corrects remaining logic manually, reviews the codebook, exports the revised dictionary, and tests it in a development project before sending it to the study team.

Application guide

Research Data Quality Studio

Research Data Quality Studio provides a structured way to profile, check, clean, and document a research dataset before analysis or delivery.

Preparing the input

Use a working export that preserves the intended variable names and coding. Keep the original file unchanged. Supported imports include delimited text (CSV, TSV, pipe, and semicolon forms), JSON/NDJSON, XLSX/XLSM, ODS/FODS, DBF, SPSS SAV/ZSAV/POR, Stata DTA, and SAS7BDAT/XPT. If the source uses special missing-value codes, date or time formats, value labels, long strings, or non-ASCII encodings, compare those features with the source after import before creating rules. SAS labels stored only in a separate SAS7BCAT catalog cannot be recovered from a SAS7BDAT file by itself. For delimited files, every data row must contain the same number of fields as the header; malformed quotation and inconsistent row widths are rejected rather than silently shifting or padding values.

Recommended workflow

1. Import the dataset and confirm dimensions and variable types.
2. Review missingness, distributions, categories, duplicates, and initial findings.
3. Create or import rules based on the protocol, codebook, and analysis plan.
4. Inspect findings by variable and record.
5. Apply deterministic cleaning actions or case-specific edits.
6. Rerun checks and review the change history.
7. Export the cleaned data and supporting documentation.

Rule types

Rules can address required values, ranges, allowed categories, unique keys, date order, conditional requirements, text patterns, data types, numeric comparisons, text length, and outliers. A good rule should have a clear rationale and a defined response when it fails.

Cleaning decisions

Cleaning is not just a technical exercise. A value outside an expected range may be an entry error, an unusual but valid observation, or evidence that the rule is too narrow. Review the record context and source documentation before changing or excluding it.

Change documentation

The change record is essential when cleaned data will be shared with analysts, investigators, monitors, or collaborators. Review it before export and preserve it with the cleaned dataset.

Exports

Choose an export format appropriate for the next step in the workflow. Cleaned-data exports include CSV, TSV, pipe-delimited and semicolon-delimited text, XLSX, ODS, JSON, NDJSON, and SPSS SAV. Native import support for POR, DTA, SAS7BDAT, and XPT does not imply export to those formats. Reopen a representative export and compare labels, dates, missingness, identifiers, leading zeros, and precision when fidelity is especially important.

Workspace guide

Designing useful rules

A useful rule is specific enough to identify a meaningful problem and broad enough to remain valid across the intended dataset. Document whether the rule is based on the protocol, instrument, data dictionary, source-system constraint, or analysis plan. For example, an age range should reflect the eligible population rather than an arbitrary statistical cutoff.

Handling missing values

Different sources may represent missing data as blank cells, special numeric codes, text labels, or software-specific values. Review these conventions before calculating missingness or applying recodes. Do not automatically combine refusal, not applicable, unknown, and true missingness unless the project has decided that they should be analyzed together.

Duplicates and identifiers

Duplicate records require context. A repeated participant identifier may indicate accidental duplication, multiple legitimate visits, repeated instruments, or an identifier that is not actually unique. Define the expected key and visit structure before deleting or merging records.

Example use

A statistician receives a longitudinal export with mixed date formats, duplicated participant-visit combinations, inconsistent category spelling, and numeric values stored as text. The statistician creates date, unique-key, allowed-value, and type rules; reviews the findings with the data manager; applies agreed corrections; reruns the audit; and exports the cleaned dataset with the change record and rule set.

Application guide

R & Python Publication Table Studio

R & Python Publication Table Studio is intended for results produced in R or Python, including console output, notebooks, model summaries, rendered reports, and structured table exports.

Choosing the best source

Prefer the source that most directly represents the analysis result. A saved notebook with stored output or rendered HTML is usually more reliable than copied terminal text. For heavily formatted tables, HTML, Word, Excel, or a direct table export may preserve structure better than plain text.

Common supported sources

Sources include R console and .Rout output, R Markdown, Quarto, Markdown tables, Quarto list and grid tables, gt and flextable HTML, Jupyter notebooks, statsmodels summaries, pandas-style tables, and compatible document or spreadsheet exports.

Recommended workflow

1. Import related output files together.
2. Review software identification, source excerpts, warnings, and table counts.
3. Compare every table with the original analysis output.
4. Edit titles, labels, cells, notes, roles, and structure.
5. Apply publication formatting and merge compatible models when useful.
6. Validate the collection and mark verified tables reviewed.
7. Export or save a project.

Special considerations

R and Python output can include display indexes, multi-equation models, sparse factor loadings, nested headers, console prefixes, significance symbols, and code mixed with results. Review these features carefully. A notebook that contains code without stored output cannot provide result tables until it is rerun and saved.

Workspace guide

R-specific guidance

Console output may include prompt prefixes, significance legends, wrapped term labels, sparse matrices, and multiple printed sections. In rendered R Markdown and Quarto HTML, the application separates executable code from stored output before parsing. Common table(), xtabs(), and ftable() results are reconstructed as frequency or contingency tables, while mixed-model summaries are separated into model-fit, random-effects, and fixed-effects tables. Preceding code is used only to supply contextual labels such as the variable, model object, or outcome name; it is not treated as table data. When a report contains highly styled widgets or interactive content, a static HTML, Word, Excel, notebook, or console export may still be easier to verify.

Python-specific guidance

Python tables may include a display index that is not part of the statistical result. statsmodels summaries often contain model metadata followed by coefficient tables, while some models have several parameter blocks. Jupyter notebooks must store their output cells; code alone cannot be converted into result tables.

Example use

An analyst imports an R Markdown report containing descriptive tables, regression summaries, and estimated marginal means. The analyst removes an unnecessary display index, gives each regression a short model label, merges compatible models, standardizes confidence-interval formatting, adds notes describing covariate adjustment, validates the collection, and exports an editable Word file for the manuscript team.

Application guide

Stata & SAS Publication Table Studio

Stata & SAS Publication Table Studio is designed for Stata logs and reporting output, SAS listings and ODS-style output, and compatible exported result tables.

Choosing the best source

For Stata, a plain-text log or supported SMCL file is often a good starting point. Modern reporting output such as etable and dtable can also be imported when copied or exported in a supported structure. For SAS, use the listing or an ODS-derived HTML, XML, Word, Excel, or RTF export.

Recommended workflow

1. Import related files from the same analysis or reporting task.
2. Review command or procedure boundaries and table identification.
3. Compare rows, grouped headers, statistics, confidence limits, and footnotes with the source.
4. Edit and format the table collection.
5. Merge only compatible model tables.
6. Validate and mark reviewed tables.
7. Export or save a project.

Special considerations

Survey output, mixed models, class parameters, least-squares means, covariance structures, and post-estimation commands often use layered or continuation layouts. Stata logs may contain several commands in sequence, while SAS listings may repeat titles across procedure sections. Confirm that each extracted table has the correct boundary and label.

Workspace guide

The import, table collection, editor, cleanup, formatting, validation, project, and export workspaces operate in the same way described in the publication-table workflow chapter. The source workspace is specialized for Stata and SAS file types and software-specific output patterns.

Stata-specific guidance

Logs can contain several commands, echoed syntax, iteration histories, and text that is not part of a table. Modern reporting commands may place multiple models or descriptive groups into one table. Confirm that command boundaries, model labels, omitted categories, base levels, and post-estimation statistics are represented correctly.

SAS-specific guidance

SAS listings often repeat procedure titles and may use separate sections for fit statistics, effects, parameters, odds ratios, least-squares means, covariance estimates, or survey corrections. ODS exports usually preserve structure more reliably than copied listing text, especially when headings span several rows.

Survey and mixed-model output

Survey estimates can include design degrees of freedom, weighted totals, design effects, and corrected tests. Mixed models can include fixed effects, covariance parameters, random-effect structures, and model-fit information in separate tables. Keep the needed sections and describe the model or design clearly in table notes.

Example use

A researcher imports a Stata log containing a descriptive dtable, two regression models, margins, and an etable. The source review confirms that the sections remain separate. The researcher labels the models, retains the margins table as a separate result, formats estimates and P values, and exports the collection to Word.

Application guide

SPSS & Point-and-Click Publication Table Studio

SPSS & Point-and-Click Publication Table Studio supports SPSS and compatible output from jamovi, JASP, JMP, and Minitab.

Choosing the best source

Use a compatible native results package when it contains readable table objects. For older, customized, hidden, encrypted, chart-only, or unsupported objects, export the required tables to HTML, XML/OXML, Word, Excel, RTF, CSV, or text.

Recommended workflow

1. Import the native output or structured export.
2. Review the detected software family, source excerpt, warnings, and table list.
3. Compare grouped headers, continuation rows, footnotes, and reference categories with the viewer or report.
4. Edit and format the table collection.
5. Merge only compatible model tables.
6. Validate and mark reviewed tables.
7. Export or save a project.

Special considerations

Point-and-click software often uses pivot tables with several header layers, suppressed repeated labels, superscript footnotes, and visually grouped statistics. Mixed-model, repeated-measures, generalized-model, survival, reliability, factor-analysis, and diagnostic output deserve especially careful comparison with the original viewer.

Workspace guide

The source workspace handles supported SPSS and point-and-click software files. After extraction, the table collection, editor, cleanup, formatting, validation, project, and export workspaces follow the same process used in the other publication-table applications.

SPSS-specific guidance

Viewer output often uses pivot tables with nested headings, repeated-label suppression, superscript footnotes, and procedure-specific notes. Confirm that the variable name and assumption rows remain distinct in t tests, that grouped coefficient headings are correct, and that repeated-measures corrections or covariance matrices retain their intended labels.

jamovi and JASP guidance

Compatible stored result members can be read from supported packages, but charts and proprietary analysis objects may need to be exported. HTML and spreadsheet exports are useful when a package contains a result that cannot be represented directly.

JMP and Minitab guidance

Use structured reports or session output that includes the numerical tables. A native project may contain interactive objects without directly readable table content. For reliability, mixed-model, logistic, and life-data reports, verify section titles and model-fit statistics carefully.

Example use

A manuscript team imports SPSS output containing descriptives, an independent-samples test, logistic regression, and a classification table. They verify the grouped headings and footnotes, rename the tables, remove software-only notes that do not aid interpretation, add a reference-category note, and export the final tables to Word.

Publication tables

Reviewing and Formatting Publication Tables

The publication-table applications share the same review, editing, formatting, project, and export workflow. The import logic differs by software family.

Source cards and excerpts

Source cards show what was reviewed, how the software family was identified, and whether any files were rejected. Use the retained excerpt to compare the normalized table with the source. If the wrong software family was selected, choose an appropriate parser hint and rescan.

Table status

New tables begin unreviewed. Mark a table reviewed after checking it against the source. Structural or cell edits made later change its status so that it can be reviewed again. Reviewed-only export helps keep unfinished tables out of a final collection.

Editing table content

You can edit titles, model labels, headers, row labels, cells, notes, references, row order, column order, and table structure. Use Undo/Redo when experimenting with cleanup or formatting.

Column roles and statistical formatting

Column roles help the application understand labels, estimates, standard errors, confidence limits, P values, counts, percentages, and model statistics. Correct roles improve validation and formatting. Review automatically assigned roles when a source uses unusual headings.

Merging model tables

Merge tables only when they represent comparable models. Give each source table a clear model label. Confirm that estimates use the same scale and that term labels refer to the same predictors, categories, and reference groups.

Notes and footnotes

Retain information needed to interpret the table, such as reference categories, confidence levels, weighting, missing-data handling, multiple-comparison adjustments, survey design, and model-specific definitions. Remove software-generated notes only when they are truly unnecessary.

Collection validation

Validation checks table structure, blank or duplicate headers, row widths, hidden label columns, statistical ranges, review state, notes, and formatting consistency. A warning is a prompt for review, not proof that the value is wrong.

Titles and numbering

Use concise descriptive titles that identify the population, outcome, model, or comparison. Table numbers are often added during manuscript assembly, so keep titles useful even when numbering changes. Avoid software procedure names unless they help the reader understand the analysis.

Precision

Choose precision based on the statistic and journal expectations. Counts normally need no decimals; percentages often use one decimal; estimates and uncertainty measures should use enough digits to communicate the result without implying unrealistic precision. Keep related columns consistent.

P values

Use a consistent convention throughout the collection. When the journal requires exact P values, retain appropriate precision and use a threshold such as P < .001 only when justified. Do not replace a reported value with a significance symbol alone.

Confidence intervals and ratio estimates

Confirm the confidence level and make sure lower and upper limits correspond to the correct estimate. Odds ratios, risk ratios, incidence-rate ratios, and hazard ratios are generally interpreted relative to 1 rather than 0. Label the estimate scale clearly.

Missing and suppressed cells

Blank cells can mean missing, not estimated, not applicable, omitted, suppressed, or structurally repeated. Use notes or symbols to distinguish these meanings when readers could be confused.

Final review checklist

• Every included table has been compared with its source.
• Titles and model labels are meaningful outside the software.
• Headers and column roles are correct.
• Reference categories and adjustments are documented.
• Notes explain abbreviations, missingness, weighting, and special procedures.
• Numbers and confidence limits match the source.
• Formatting is consistent across the collection.

Saved work

Sessions, Projects, Autosave, and Exports

Browser autosave

Autosave in Research Data Quality Studio and the publication-table applications helps recover a recent working state on the same device. It is not a durable archive. Private browsing, clearing site data, browser storage limits, mobile device cleanup, or institutional device policies can remove it. REDCap Dictionary Studio does not use browser autosave.

Portable session and project files

Research Data Quality Studio saves a portable session containing the working dataset, rules, edits, settings, and change history. Each publication-table application saves a portable project containing normalized tables, edits, notes, settings, and review status. Publication-table projects include original source files only when you explicitly choose that option; source-inclusive projects are larger and may contain confidential output. REDCap Dictionary Studio instead exports the corrected dictionary and supporting review files.

Export selection

Choose exports based on the next user. Word and Excel are useful for collaborative editing, HTML for self-contained review, CSV for individual table data, and print/PDF for a fixed visual copy. Data Quality Studio offers formats suited to analysis and transfer, while REDCap Dictionary Studio provides project-definition, report, and codebook outputs.

Round-trip review

When a format will be edited and later re-imported, test a representative file early. Confirm that titles, notes, labels, dates, missing values, categories, and numeric precision survive the round trip.

File naming

Use names that identify the project, content, date or milestone, and version. Avoid repeatedly overwriting the only project file. A simple pattern such as project_table_review_2026-07-20 is easier to manage than names such as final2_new.

Source-inclusive publication projects

Including original output files can make rescanning and provenance review easier, but it increases file size and may embed confidential results. Include sources only when useful and store the project accordingly.

Collaborative review

When sending an editable Word or Excel export, also preserve the application project. A collaborator may change the document in ways that cannot be reconstructed automatically. Keep a clear distinction between the reviewed application output and later manuscript edits.

Reference

Troubleshooting

A file will not import

• Confirm that the file type belongs to the selected application.
• Try a fresh export from the source software.
• Check for password protection, encryption, malformed quotation, inconsistent rows, or an incomplete download.
• For proprietary output, export the needed tables to a supported structured format.

The application found no table

• Confirm that the file contains stored numerical output rather than code, syntax, charts, or empty placeholders.
• Try HTML, Word, Excel, XML, CSV, or the original log/listing output.
• For publication applications, review the source card and choose a parser hint before rescanning.

The table looks incomplete or shifted

• Compare the retained source excerpt with the original software output.
• Check for wrapped labels, grouped headers, continuation rows, superscript notes, or locale-specific decimal marks.
• Try a structured export instead of copied text.
• Correct the table manually only after confirming the intended structure.

The browser lost recent work

In Research Data Quality Studio or a publication-table application, check whether browser autosave is available, but do not rely on it as the only backup. Restore the latest downloaded session or project and repeat only the changes made since that checkpoint. In REDCap Dictionary Studio, reopen the latest exported corrected dictionary; unsaved in-tab edits cannot be restored after the page is closed or reloaded.

An export opens incorrectly

Check the application used to open it, the selected delimiter or encoding, and regional settings. Spreadsheet programs may automatically interpret dates, identifiers, leading zeros, and formula-like text.

Validation reports a failure

Rerun the validation suite once. If the same check fails, reload the application in a current browser and repeat it without a project open. A persistent failure may indicate a browser compatibility problem or a damaged application file; do not rely on the affected function until the problem is resolved.

The application appears slow

Large files, many tables, source-inclusive projects, and extensive browser history can increase memory use. Save the current session or project where supported, close unrelated tabs, reload the application, and work with smaller import batches when appropriate.

Text looks unrelated to the current task

Make sure the source file contains result tables rather than software syntax, logs from several unrelated analyses, debugging messages, or copied page furniture. A clean export of the needed table is often the best solution.

Reference

Glossary

Analysis-readiness

The extent to which project metadata or data coding is organized for reliable analysis. It does not mean that the scientific design or analysis plan is complete.

Browser autosave

A local recovery copy stored by the browser on the current device. It can be removed and should not be treated as the only backup.

Change log

A record of edits or cleaning actions showing what changed and, where available, the previous and updated values.

Column role

The statistical meaning assigned to a publication-table column, such as label, estimate, standard error, confidence limit, P value, count, or percentage.

Data dictionary

A structured description of fields, variable names, labels, choices, validation, logic, and other project metadata. In REDCap, the Data Dictionary CSV can be used to define or update a project.

Issue register

A searchable list of findings produced by an audit or rule set, usually including the affected field, variable, or record and a recommended review action.

Parser hint

A user-selected software-family clue that tells a publication-table application how to rescan ambiguous source text.

Project file

A portable saved state used by the publication-table applications. It preserves normalized tables, edits, notes, settings, and review status for later continuation; it is different from a final exported publication table.

Session file

A portable saved state used by Research Data Quality Studio. It preserves the working dataset, rules, edits, settings, and change history for later continuation; it is different from the cleaned-data export.

Provenance

Information about where a table came from and how it was reviewed or changed. Provenance helps users trace an exported table back to its source.

Review status

A publication-table indicator showing whether a table has been checked against the original source and whether it was changed afterward.

Rule set

A reusable collection of data-quality checks based on project requirements.

Safe Auto-Fix

A controlled REDCap dictionary repair process that previews supported changes before they are applied to the local copy.

Source excerpt

The portion of statistical output retained beside an extracted table to support comparison and verification.

Reference

Responsible Use and Citation

Verification

Automated review saves time, but the user remains responsible for the final project, data, and tables. Verify important outputs against the source material and the study protocol.

Privacy and security

Use approved devices, storage locations, and transfer methods. Do not place identifiable or confidential research information in unapproved support messages. Processing files within the application does not override institutional policy or data-governance requirements.

Scientific and regulatory judgment

The applications do not determine whether a variable should exist, whether a cleaning rule is scientifically justified, whether a statistical model is appropriate, or whether a table satisfies a particular journal, sponsor, or regulatory requirement.

Software citation

Each application’s Help tab includes a suggested citation. Use the application name and the version displayed in the application when documenting software used in a project or publication.

For current public information, visit the StatsWithR homepage.