Background
Graphical user interfaces (GUI) are an essential part of modern
software, providing users with an intuitive method to access all of the
functionality offered by a program. A well-designed GUI guides users by,
for example, displaying relevant actions, adapting to user input,
providing info tooltips and other visual cues. Software developed for
research purposes, however, rarely includes a GUI, relying solely on the
command line interface (CLI). The CLI is appropriate for advanced users,
who can then quickly integrate new software into existing pipelines, but
it comes with a steep learning curve (that may never be overcome) for
non-technical users. CLIs are sensitive to typing errors, requiring
users to remember which command-line options need to be included to run
a program effectively. Moreover, command-line tools generally have a
single, well-defined function and therefore require additional programs
to view or post-process the output, further complicating their usage.
These issues may appear trivial, but, in practice, they dramatically
limit the number of potential users to those who are already comfortable
using the command-line.
GUIs make programs more user-friendly and ease the adoption of novel
computational tools. While the inclusion of GUIs is in the interest of
both developers and users, there is little incentive to code a native
graphical user interface. Many journals are dismissive of the scientific
contribution offered by more usable software and development teams in
academia tend to be constrained in terms of members (Mangul et
al. , 2019). A common compromise is to set up an online service where a
web interface is used to launch a CLI program on a remote server. This
provides cross-platform, installation-free access to the software, but
has many disadvantages: (i) it requires a web server, necessitating
additional setup, programming and maintenance; (ii) it cannot be used
offline; and (iii) it is limited by the fact that users need to share
the available network and CPU resources. Furthermore, such web
interfaces tend to be based on basic HTML forms with little
interactivity to guide the users. While it is possible to develop more
sophisticated web interfaces, this requires extensive knowledge of web
technologies like CSS (Cascading Style Sheets) and Javascript, and can
take a long time to develop.
Although it is considerably easier to implement a web service than a
native GUI, integrating multiple programs remains a challenge. Both the
web interface and the server side code needs to be built for a specific
CLI program. Moreover, most of the user input processing and related
code typically resides on the server that is hidden from the users. This
causes redundancy, because the web interfaces cannot be reused by
third-party developers for modification and therefore need to be created
from scratch. The issue could be addressed by standardizing
communication between a graphical interface and its program. Some
standard specifications have been developed, like the Common Workflow
Language (https://commonwl.org) or the Galaxy tools XML (Afgan et
al. , 2018), that define how to describe a CLI program in a text file.
Scientific workflow management systems (e.g. Taverna (Wolstencroftet al. , 2013) or CWL implementations like Arvados
(https://arvados.org)) utilize this information to integrate external
programs and, in some cases (e.g. Galaxy), also for creating the
graphical interface elements. However, these standards are optimized for
building pipelines and therefore omit GUI-specific instructions. In
addition, setting up and running a workflow management system together
with its environment (e.g. a dedicated web server, system container or
virtual machine) adds unnecessary overhead when used only for creating a
GUI for a CLI program.
Here, we introduce Pline (“ Plugin interface language” ):
a specification for describing command line programs and their
interfaces, and a lightweight framework that uses the program
descriptions to build interactive graphical interfaces. By utilizing
standardization and web technologies, Pline allows for creation of
cross-platform GUIs without programming, considerably lowering the bar
to develop user-friendly software in science.
Implementation
On a technical level, a CLI program powered by a Pline interface
consists of three parts: the plugin files (the program and its
description in JSON format), the interface generator (a Javascript
library) and the server module (a Python script). Bundled together, they
form a fully functional GUI program that can be used as a standalone
desktop application, as a dedicated web service, or as part of an
existing web page.
Pline plugin API
Pline is an application programming interface (API) for writing plugins,
and its implementation as a web application. A Pline web app can include
one or more plugins, i.e. CLI programs and their description files.
Description files are written in plain text using the API specification
and are used to detail how to launch the associated program and draw its
interface.
Pline plugin descriptions specify a list of command-line arguments
available for a given CLI program. The information is written in JSON
notation (https://www.json.org) – a common format that structures
textual data with nested brackets, designed for easy reading and writing
for both humans and programs. The Pline API represents interfaces using
the JSON format where the data (a set of properties with values) define
the underlying functionality and the structure (the order and nesting of
the data items) reflects the placement of resulting interface elements.
Since most of the properties are optional, basic interfaces are quick to
construct (see example in Figure 1). However, the plugin description is
extendable with advanced inputs and properties for sophisticated GUIs.
Pline supports both simple input types like text, files, on/off flags or
selection lists, and advanced ones that merge or modify values from
linked inputs (see Figure 2 for an advanced case).
Input arguments are often related. A CLI program may require one or more
sets of arguments where the list of compulsory or optional arguments,
their values or the effect of those values is defined by the user input
for a set of other arguments. In the Pline JSON format, the network of
linked inputs is described by setting rules for the input properties
that support it. For example, instead of a fixed default value for an
input, a rule can derive the value from another input. These rules are
written as conditionals – english-like if-else sentences or Javascript
statements where the action of the rule is defined by the property that
the rule is attached to. In addition to setting the default value, Pline
supports conditionals for dynamically formatting or fixing an input
value, for specifying an output file name and for enabling or disabling
input elements and element groups. Together with other advanced features
like input filters, error messages and merged values, the Pline API
allows for describing even highly complex command-line interfaces. To
customize the resulting interface, the API also specifies properties for
adding icons, labels, documentation, HTML markup and CSS styling.
Pline web application
Pline includes an interface generator that implements the JSON
specification and translates the program description into a graphical
user interface. The generator is written in Javascript, which runs
natively inside any modern web browser, and is used by including it in a
webpage as a library. The library takes a Pline plugin description as
input (given as raw JSON text or a URL), parses the information into an
internal data model, and outputs a graphical interface that can be
placed into any container element in a web page. In practice, the
process involves just two Javascript commands (addPlugin() for the
plugin import, plugin.draw() for interface drawing) and supports
multiple input programs and output interfaces in a single web page.
A Pline-generated GUI is not static – the HTML interface is bound to an
internal data model and event listeners that enforce the dependency
rules between the program parameters and adjust the interface according
to user interactions. User input is tracked in real-time: as soon as a
tick-box is clicked or a number is typed, the interface updates
accordingly, e.g. by hiding, revealing, or changing the values of all
the linked input elements. The conditionals in the Pline JSON therefore
provide a quick way to construct sophisticated interfaces that hide
invalid inputs and guide the user through program configuration options.
In addition to generating standalone GUIs, Pline can chain multiple
interfaces together, forming a pipeline – a set of commands executed in
succession. The information about input and output files in the program
description is used to control the data flow between the pipeline steps.
The current state of a single interface or a full pipeline can be stored
to a file and distributed as a reusable Pline pipeline with pre-filled
input values.
A graphical interface generated with Pline records user input and forms
a complete terminal command for launching the CLI program or pipeline
together with user-supplied input files. Since the web browser security
sandbox prevents direct command-line access, the program launch data is
passed on to a backend server for execution. Pline includes a
lightweight python script that acts as a server module to launch the
commands, either on a local computer or over the web. The Pline server
accepts the command data sent by the interface via an HTTP POST request,
sanitizes the input, and manages the execution process. It also supports
HTTP requests to send execution status updates back to the interface,
pause, cancel or resume running pipelines, or send email notifications
after a command or pipeline has finished.
Pline interfaces are designed to be installation-free and work across
many different operating systems. The JSON program description files are
platform-agnostic, the interface generator runs on any device with a
modern web browser (including mobile devices), and the server module
supports both Python 2.7 and 3 environments (which is preinstalled on
most MacOS and Linux systems). However, command-line executables are
compiled to run on a specific operating system, so a Pline plugin should
include an executable for each target system.
Results
Example plugins
New program interfaces are added to Pline by supplying the corresponding
JSON description files, either by copying them into the designated
plugin directory (when using the Pline server module), or by feeding the
data directly into the Pline interface generator using a special
Javascript command. In principle, an interface can be generated for any
command-line executable, including installed programs that are available
system-wide. However, the JSON description is written for a specific
version of a program and it is recommended that the matching binary
(preferably with copies for different operating systems) is distributed
together with the description file, forming a plugin bundle. The Pline
homepage includes several example plugins that can be used as templates
for writing third-party plugins.
A basic interface can be constructed from a few pieces of information in
a program description file. The only compulsory data fields are the
executable name and a type and/or name property for each of the input
arguments. A simple example is shown in Figure 1. Here, the JSON
description specifies a python script that expects an input file (as a
positional argument) and an optional boolean flag ”–count” (a named
argument). Pline translates this information into a file input element
and a checkbox element. In addition, the interface header displays the
program description and provides an option to name the program execution
session, as well as to save or restore sets of user input values. The
”Run” button produces the program command that is sent together with the
input file to the server module for execution. In case the input file is
not provided, the error message ”Input file missing!” is displayed
instead (as specified by the “required” property).