new_ide.tex

We are in the initial stages of rethinking what an IDE might look like when it is designed from the ground-up to support programming as problem solving. We particularly are exploring new metaphors for how users would interact with the IDE (compared to the bento-box paradigm underneath today's IDEs), as rooted in the specific actions that we know programmers engage in and that must thus be supported (conform Table~\ref{pps_matrix}). At present, the leading metaphor for our design is that of cards (as inspired by  code bubbles~\cite{bragdon2010bubbles}): the IDE presents all information and enables the developer to make changes through individual cards (see Figure 1).  We believe cards, and the affordances that they have, allows the envisioned IDE to better match what programmers actually do. We briefly highlight five key elements in this regard together with which challenges (\textit{C\#}) we identified they would address.

\begin{itemize}
	\item Cards serve as containers for different entities created during problem-solving sessions. They span different artifacts (e.g., an open issue that is being worked on (Card 1), sketches that capture designs (Card 2), or code snippets for reviewing and editing (Cards 3--6)). This diversity of cards is crucial, as it unifies how programmers interact with different types of information that they need in formulating problems and reflecting on them (\textit{C\#1}).
    
	\item Cards can be spatially arranged or grouped by programmers in the open canvas. Since cards can be grouped in different ways, this supports different information processing styles and workflows (\textit{C\#3}). For example, cards can be placed side-by-side (Cards 4--6) allowing for the exploration, reflection, and mixing and matching of alternative solutions (\textit{C\#1}). Such comparative reasoning has been shown to be critical for creating good solutions~\cite{hartmann2008design}. 
 
%     Cards provide manageable snippets of content which can be arranged in dynamic structures across an open canvas.
% 	The spatial arrangement of cards is determined by the user, which accommodates different information processing styles and workflows (\textit{C3}).
% 	Additionally, the ability to compare individual cards (\textit{Cards 4--6}) allows for the exploration, reflection, mixing, and matching of alternative solutions facilitates comparative reasoning and the development of "what if" scenarios~\cite{hartmann2008design}.
% 	This process of personalization and contextualization between cards provides further support towards the formulation and reflection of in-progress solutions (\textit{C1}).
	
	\item  Cards can be organized in \textit{groups} or \textit{stacks}, which allows programmers to organize the different entities to create the context that is needed in the problem solving exercise (\textit{C\#2}). For example, cards can be organized spatially (Cards 3--5) such that all relevant cards for a given context are visible at the same time, or they can be stacked (Cards 7–9) to consolidate cards that are relevant, but are not immediately needed.
	
	\item Card groupings (in \textit{groups} or \textit{stacks}) are type-agnostic, that is, cards of different types can be combined together (Cards 7--9). Cards can also reflect programming elements at different points in time (Cards 4, 5), allowing comparisons between different versions of the same artifact to provide historical context to the current change (\textit{C\#4}).
	
	\item Cards are created within an individual programmer's workspace, but are easily shared between different programmers (e.g., Cards 3--5 are shared with two teammates: Mark and Sally). Further, each card is dynamic, automatically updating itself to reflect the latest changes, which provides an awareness of what other programmers are currently working on (\textit{C\#5}), thereby allowing developers to create some form of workspace awareness~\cite{dasilva2006lighthouse}.
\end{itemize}

To date, we have merely engaged with the 'theoretical' exploration of these ideas.
Our next step is to construct an actual prototype implementation to take them forward toward supporting programming as problem solving.