51 lines
3.5 KiB
TeX
51 lines
3.5 KiB
TeX
%!TEX root = ../main.tex
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=\columnwidth]{graphics/vizir-ui-menu}
|
|
\caption{An example of Vizier's UI}
|
|
\label{fig:hybridinterface}
|
|
\end{figure}
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
Vizier's interface (illustrated in Figure~\ref{fig:hybridinterface}) combines elements of both notebooks and spreadsheets. Notebook interfaces like Jupyter use an analogy of pages in a notebook that consist of a block of code, as well as an output for the block like a table, visualization, or documentation text. Blocks are part of a continuous program, allowing a user to quickly probe intermediate state by creating new visualizations or views of the data, or to safely insert hypothetical, exploratory modifications by adding or disabling pages.
|
|
|
|
Spreadsheets give users an infinite 2-dimensional grid of cells that can hold either constant values or computed values derived from other cells through \textit{formulas}.
|
|
Collections, as they exist, are defined implicitly as any 1- or 2-dimensional region of cells that has meaning to the user.
|
|
Thus, instead of classical programmatic specification of bulk, set-at-a-time operations as operations over named collection objects, spreadsheets use the metaphor of copying code to a (user-specified) range of cells, combined with relative, positional data dependencies to quite literally ``map'' singleton operations over entire collections.
|
|
In addition to making it easy to perform bulk operations over the entire collection, this approach provides a clear affordance for declaring exceptions: Even after being copied, each cell's formula is (and is presented as) a singleton, logically independent of other cells' formulas.
|
|
|
|
\oksays{Need to discuss how creating figures is easier in spreadsheets}
|
|
|
|
Between the simplicity of creating singleton operations and the simplicity of creating visualizations, spreadsheets are a powerful tool for data curation and exploration. Indeed, spreadsheet users often ``do not appear inclined to use other software packages for their tasks, even if these packages might be more suitable"~\cite{Chan1996119}. Our goal in Vizier is to empower users with a similar level of flexibility for transforming, visualizing, and exploring relational data.
|
|
|
|
\begin{itemize}
|
|
\item Edit any cell (overwrite, cast, etc...)
|
|
\item Add/Delete rows, columns, etc...
|
|
\item Define target regions for ``bulk operations'' by selection
|
|
\item Enable singletons
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
Vizier's users can edit tables and visualizations directly, and have those edits reflected in the notebook's code block through database-style table updates that are propagated to all subsequent code blocks.
|
|
As a result, the user's edits, however they are applied,
|
|
are recorded in the notebook as a part of the workflow.
|
|
Although we will not reproduce
|
|
the full spreadsheet interface entirely, our goal is to replicate as many of the
|
|
flexible data and schema manipulation features of spreadsheets as possible. Concretely, Vizier's UI allows users to:
|
|
\begin{itemize}
|
|
\item Overwrite arbitrary values with constants or formulas
|
|
\item Cast cells to a new type
|
|
\item Cut/Copy/Paste cells, tiled over target regions
|
|
\item Add/Delete/Reorder columns or rows
|
|
\item Sort data
|
|
\item Filter data
|
|
\end{itemize}
|
|
Operations that affect multiple cells are applied to an area currently selected by the user, rather than to an entire column or row.
|
|
|
|
are applied to an area currently selected by the user, as opposed to the entire
|
|
|
|
target regions, as opposed to entire |