%!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