PlateEditor was written in pure JavaScript (JS) and uses only two external libraries as dependencies: PapaParse, for client-side parsing of text and csv files (v5.0; https://www.papaparse.com) and JSZip, for reading and writing of zip archives (v3.2.0; https://stuk.github.io/jszip). The source code is divided into four independent packages: editor.min.js regroups the classes needed by the plate layout editor; analyzer.min.js regroups the classes needed for data aggregation (including the Z-score calculation); shared.min.js regroups the classes needed for the file parsing, mapping and plate pairing; ui.min.js regroups the classes needed for the user interface. All classes and functions were written as independent JS files, organized in four folders named after the package to which they belonged (editor, analyzer, shared, ui). The packages were built by merging together all files from a single folder and minifying the resulting file, using the JS library Gulp (v4.0.0; https://gulpjs.com/). The cascade style sheet (CSS) files used by the web application were written and packaged the same way (merged and minified using Gulp). Each JS package file has an associated CSS package file (editor-styles.css; analyzer-styles.css, shared-styles.css and ui-styles.css). To simplify the development and bug-tracking process, source maps were also generated with Gulp, allowing the initial, non-minified code to be referenced in the browser console upon code execution errors. The application was designed using Firefox Developer Edition (v85; https://www.mozilla.org) and tested with Google Chrome (v87) and Microsoft Edge (v87). The source code is available under the MIT license on the PlateEditor repository on GitHub (https://github.com/vindelorme/PlateEditor) and SourceForge (https://sourceforge.net/projects/plateeditor). The latest version of the full application, as well as the version available at the time of the manuscript review, can both be downloaded as zip archives on SourceForge or GitHub.

For a population of n discreet numerical values, whose average is equal to Avg, the standard deviation (SD) and coefficient of variation (CV, %) of the population were calculated as follows: SD=1n∑i=0n(xi−Avg)2 CV=100×SDAvg

The formula used for calculation of the Z-factor (Z’, [6]) and window (W) are as follows: Z′=1−3×(SDpos+SDneg)|Avgpos−Avgneg| W={AvgposAvgnegifAvgpos≥AvgnegAvgnegAvgposifAvgneg≥Avgpos

Where Avg_pos, SD_pos, Avg_neg, SD_neg are respectively the average and standard deviation of the aggregated values for the positive and negative controls.

Multiple data files of various format and origins were used for the validation of the algorithms. Real-case files generated automatically by plate readers or other applications were included, along with manually created files containing randomized data. The source code includes test files used for the testing and validation of the application (tests folder). For each file, a short description of its usage and expected output is given in the Readme file present in this folder. Both in the source code and the bundled application, other files used for demonstration purposes are also included (examples folder). The files used to generate the figures and examples described in this manuscript are all available in this folder.

In PlateEditor the parsed contents of data files attached to the layout, which includes both Results and Definitions files, are not stored in the memory. Although such approach would be acceptable for files of few hundreds of kilobytes (kB), memory limitations would prevent files of several megabytes (MB) or more from being successfully loaded by the web browser, leading it to stall and eventually crash. To address these issues and allow the user to work with potentially big files, a streaming approach allowing the files to be read row-by-row was implemented. The JS library PapaParse (https://www.papaparse.com) was directly available for client-side streaming of text or csv files, but no counterparts were available for spreadsheet files (in particular.xls and.xlsx). These spreadsheets can always be converted to text or csv files by the user, so that the PapaParse library is theoretically sufficient. In practice, the Microsoft Excel file format is widespread in research laboratory and usually preferred over txt or csv due to the sorting, formatting and calculation tools that it offers. It thus seemed appropriate to implement a streaming-enabled parser for these files.

For xlsx files (the most recent format) the data are stored as human-readable xml files in a zip archive, so that implementation of a streaming-enabled parser was relatively straightforward. The archive is first opened and metadata parsed to extract the sheet names (these information are kept in memory for later use). Blocs of xml data from the sheet to be read are then transferred to a web worker (equivalent to a separated thread) for parsing and the parsed rows sent back one by one to the main thread. On a regular desktop computer, parsing of an xlsx file of about 16 MB, corresponding to a single worksheet file of over 250,000 rows with an unzipped size of 180 MB, was completed in about 5 seconds, which we considered satisfying.

Older spreadsheet files (.xls) are unfriendly binary files of varying structures depending on their version. A deep dive into the file specifications was necessary (https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-xls), but ultimately it was possible to implement a parser that could read xls files dating from as far as 1995. A strategy similar to xlsx files was used here: a first parsing digests the structural information to extract the sheet names and byte offsets of the sheet data-streams in the file (these metadata are kept in memory to speed-up future access). The desired sheet data-stream is then transferred to a web worker, parsed and the resulting rows sent back to the main thread. With a regular desktop computer, parsing of a 17 MB file containing a single sheet of 65,536 rows (the maximum allowed for xls files) was completed in less than 3 seconds. Both spreadsheet parsers are able to extract results from formulas but will ignore dates (return them as numbers) and formatting applied to the numbers or texts.

When attaching data files to the layout as Results or Definitions, PlateEditor allows the mapping of specified columns to a well name (Well ID) or a plate name/index (Plate ID) (Fig 2A). Mapping of a Well ID is required for result files but both Well ID and Plate ID are optional for definition files. Fetching of the data will differ depending on this mapping configuration. This is quite straightforward for results as the values will always be fetched at the desired well locations in the file. If a Plate ID field is provided, values for the well ID matching the desired plate name will be used. Otherwise, the number of times the desired well name occurs in the file will be used as a key to match the desired plate index. Things are more complex for Definitions due to the higher number of cases to consider. All four possible mapping configurations and the corresponding rules used to resolve the name of a given range index are summarized in Table 1. If the name cannot be resolved, the generic name of the item is used instead: RangeName (#i), where RangeName is the name given to the range and i the index of the item in the range. For display in the Analysis tool, in cases where the range item is tagged over multiple wells, the name resolved at the first well location (i.e. well with the lowest index) will be used.

In PlateEditor Ranges are self-incrementing Areas that can be tuned to match the desired numbering pattern. Several options are provided for automatic numbering (Fig 5A), giving the user the choice over the number of replicated wells per range index, the direction of the replication (Horizontal, i.e. left to right / Vertical, i.e. top to bottom) and whether Columns or Rows should be given the priority when numbering. The possible numbering outcomes for each option configuration is shown in Fig 5B. For specific cases that would not be covered by these options and to give the user more flexibility, a full Custom mode is also available. In this mode, the range index is manually indicated by the user through a prompt that displays after the wells have been tagged. In particular, this allows the preparation of layouts where range items occupy blocs of wells spanning multiple rows and/or columns.

A layout for primary screening in 96-well plate can be created on a single layer, using 3 Areas: a range with one replicate that will represent the compounds, as well as a positive and a negative control (inhibitor and solvent, respectively. Fig 6A). The compound names can be resolved using a definition file attached to the range. A single result file holding well values for multiple plates can be attached as well. Result and definition plates can be paired by name using the auto-pairing option, which will allow them to remain synchronized. Values can be visualized for each plate in the form of heatmaps, making it simple to identify potential hit compounds. The Controls analysis tool will allow a rapid inspection of the Z-factor (Z’) for each plate. This example can be reproduced using the files available in the Screening2 folder within the Example folder (the layout, definition and result files are included).

In this example a batch of 6 compounds needs to be assessed by dose-response using a 96-well plate. The dose-response curve (DRC) should start with a 20 μM top concentration and contain 10 doses, with 2-fold dilutions between each doses. Preparation of the layout is straightforward: a single range with 10 replicates and its Direction and Priority properties set to their default value (Horizontal / Row) is first created, then tagged in the relevant wells. Using the same well selection a dose-response can be tagged automatically with the desired parameters, using the configuration as shown in Fig 6B. After binding of a result file, the Grouped Analysis tool can be configured with the concentration data (μM) as rows and the range as columns to display the desired dose-response table (as in Fig 4). A definition file can also be attached to the range in order to resolve the name of each compound. This example can be reproduced using the files available in the DRC2 folder within the Example folder (the layout, definition and result files are included).

In this example, two different cell types (CellA, CellB) should be engaged in viral infection experiments with two different viral strains (VirusA, VirusB) at two different multiplicity of infection (MOI, 5 and 20). Altogether 8 unique conditions should be tested (2 cells × 2 virus × 2 MOIs). Such layout can be prepared effortlessly by defining only 4 areas (2 for each cells and viruses) tagged on two independent layers (Fig 6C). MOI data can be added on the virus layer using the single concentration tagging tool to complete the layout. After binding of a result file, the Column Analysis tool will list automatically all the unique cell/virus/MOI combinations with their aggregated values and statistical summaries. This example can be reproduced using the files available in the Infection folder within the Example folder (the layout, definition and result files are included).

From the start, PlateEditor was envisioned as a free in-browser solution allowing researchers to quickly design plate layouts and safely analyze their data from any computer. The strength of a web-based application is its broad availability and speed of deployment: users just need to connect to the web-page to enjoy the latest version and improvements without the need of regularly downloading and installing updates, which quickly becomes cumbersome when working with multiple computers. Such strategy is currently also adopted by technology companies (for example Google), which are delivering more and more common applications and tools through the web-browser. This allows users to work with multiple applications using a single software that is ubiquitous in all communication devices, from computers to smart-phones, including laptops and tablets. In our approach, we leveraged the power of JS to allow the application to run purely client-side, eliminating the constraints of uploading the data to the server for processing. This not-only reduces the time needed to access the file but also ensures complete privacy of the research data used within the application. Lastly, having no requirement for database or server connection and a minimum of dependencies, PlateEditor can easily be integrated into other workflows and software. We hope the availability of the source code will promote such usage and speed up the implementation of new features.

Currently, PlateEditor offers only a limited support for tablets and smartphones, because the process of well selection requires drawing a selection box, which is not well supported by touchscreen device. Although all the functionalities are operational, the lack of support for this operation makes the preparation of layout tedious. The small screen size of smartphones would anyway make the use of 384-well plate layout (or bigger) quite uncomfortable, but a good usability of the application on tablets is still highly desirable. We are now considering solutions for this issue and hope to be able to implement them soon in the application. A related limitation is the lack of support for people with visual impairment. The need for well selection and the highly visual nature of the data representation and analysis using heatmaps and colors make it difficult however to implement work around.

Another limitation is the lack of support for writing and saving of big files by PlateEditor. The only feature currently impaired by this limitation is the Push Layout function, allowing layout data to be pushed to a result file. Since the file is generated in the memory, big files may pose an issue (browser stalling and crashing) so that this function is currently restricted to 5,000 rows. While reading is not a problem and web-browsers offer appropriate tools, access to the computer file system for writing is a clear vulnerability and is therefore restricted. Streaming client-side data in an output file is currently not possible in web-browsers without additional plugins or the use of experimental functions with limited support. To our knowledge, only one JS library currently implements such feature (StreamSaver.js, https://github.com/jimmywarting/StreamSaver.js) by installing a service worker online using GitHub static pages and using it to mimic a server sending the data back to the client in the form of a stream. We are currently evaluating the usefulness, safety and compatibility of this library and may add it to PlateEditor if deemed acceptable and necessary.

We are currently preparing additional analysis tools for PlateEditor. In particular, we are considering a tool for hits/outliers detection that could prove useful for the analysis of Primary screening data. We are also considering a tool to perform normalization using values from standard curves, in order to facilitate the treatment of data obtained from ELISA. This would further increase the usefulness and versatility of PlateEditor and warrant its implementation in more diverse workflows. In the near future, we also wish to upgrade PlateEditor with a graphical output tool that will allow the visualization of the aggregated data in graphs. Several types of graph are considered: bar graphs, dot plots and box plots (whiskers), along with basic tools to estimate the statistical significance between samples. A JS application for non-linear regression has already been deployed internally in our lab and its classes and functions will also be adapted to this graphical library when ready.