this is for holding javascript data
Vijay Krishna Palepu renamed sectionsc_The_Design.tex to The_Design_Process.tex
almost 11 years ago
Commit id: dc44a034901aed0f4b3621b0de2deadbb9e2bc95
deletions | additions
diff --git a/The_Design_Process.tex b/The_Design_Process.tex
new file mode 100644
index 0000000..4250342
--- /dev/null
+++ b/The_Design_Process.tex
...
\section{\sc The Design Process}
In this section we are going to talk about the design process that guided the development process and certain key decisions that were made as a result of that process.
\subsection{Designing with Balsamiq}
In order to begin developing the tool we initially decided to prototype our user interface through the creation of low-fidelity mockups. The central notion behind this approach was to draw out fundamental ideas that we wanted to capture in our application. Although our initial tool of choice for creating mockups was pen-and-paper, we quickly decided to use the Balsamiq Google Drive plug-in for this purpose. The Google Drive plug-in for Balsamiq provided us with a web-based interface to create the mockups in a collaborative setting. This resulted in easy sharing of the mockups as we created them, allowing us to critique and refine our ideas. One of the advantages of a web based interface, apart from easy collaboration, was that of a zero-installation overhead. Since the plug-in worked in a web browser we never had any issues with installing the plugging. This was especially important as we were all using different stacks of operating systems and their associated developer tool sets.
\subsection{Discussion of Design Decisions}
We very quickly gravitated towards the idea of creating a web-based application for our tool. A major reason for the same was our level of confidence and expertise with developing web based applications. However, the advantages behind the use of a web-based interface for prototyping the UI showed that the same advantages (of using the web-based technologies), could be employed in developing and deploying the actual application itself. Since, the underlying technologies and standards, i.e. HTML, CSS, and JS, were universal, we could not only develop using our own stack of development tools (editors, IDEs, web-browsers, etc.), but also suffer a zero-overhead in terms of deploying the application again due to the universal presence and use of these technologies. This further prompted us to render the application solely on the client side web-browser, with perhaps a basic file hosting capability from the server; thus simplifying the deployment process by reducing the dependence on a central resource-serving entity.
Some of our initial designs rendered a number of different inputs that would be required from the user, largely in terms of the data and the specifications of the test itself. The different kinds of inputs along with a whole host of results and their discussion, that would need to rendered, resulted in a very cluttered UI design. Thus, in order to avoid the clutter, a key decision that we made was to guide the user through a series of steps that would lead to execution of a simple Hypothesis Test. This served two goals. Firstly, this would separate the different user inputs into well defined stages or steps (as we call them in our application). Thus, streamlining the UI itself. Secondly, and more importantly, it actually created a basic walk through of a simple hypothesis test. This, in our opinion, might add pedagogical value to the application.
The results that we present as a part of the t-Test/Hypothesis-test, would be by and large numeric. However, we recognized that it is important to contextualize these numbers for the users of the application to make sense of these results. We focused on two basic approaches to provide this context. Firstly, we provide users with notification based discussion points about the implications of the results that they get, given the inputs with respect to the data and the test itself. Secondly, we display, once again, the Research Questions, and Hypotheses (H0 and Ha) when the results are finally presented in the final step. Note that, the RQ, H0 and Ha are initially presented in the first step of the application.
