-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathusability.tex
51 lines (30 loc) · 7 KB
/
usability.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
\section{Usability}
\label{sec:usability}
Usability is one of the attributes of sustainable software, allowing users to achieve their “goals with effectiveness, efficiency, and satisfaction” \cite[p.3]{Venters_WSSSPE}. However, usability has the reputation of being a neglected aspect of scientific software \cite{Ahmed:2014}, and of relative perceived importance to users and developers \cite{Nguyen-Hoan:2010, Hucka:2016}. Papers on best practices for scientific software often omit the subject \cite{Stodden_WSSSPE, Wilson:2016} or briefly mention a particularity of scientific software usability, such as the convenience of command line interfaces \cite{bestprSC}. Nevertheless, there is a significant number of informative case studies and guidelines on the subject \cite{MacLeod:1992, Springmeyer:1993, Pancake:1996, Javahery:2004, Schraefel:2004,Letondal:2004, Talbott:2005, Macaulay:2009, DeRoure:2009, Keefe:2010, DeMatos:2013, Ahmed:2014, Beg:2016, List:2017}.
Scientific software usage and development present many challenges for usability design. Those can be related to development models, user-base needs and specialization, professional practices, technical constraints, and scientific demands \cite{Queiroz:2016}. As a result, computational science presents itself as an idiosyncratic field with unique and, occasionally, counterintuitive usability requirements. Throughout the next subsections, supported by documented case studies and further literature on the subject, we discuss those needs and how to address them. Recommendations presented here should be complementary to traditional usability best practices, such as Nielsen's heuristics \cite{Nielsen:1994}.
\subsection{Best practices recommendations}
\subsubsection{Learn about how users work}
Guidelines and case studies often recommend the adoption of a user-centered design process where to develop a firm understanding of how scientists do their work. A possible path to such understanding is the Designer as Apprentice technique, in which designers are tutored by users on the meanderings of their scientific work \cite{Springmeyer:1993}. It is also important to \emph{analyze the scientific work within the environment where it actually takes place} \cite{Pancake:1996}, evaluate existing tools which are already in use \cite{Javahery:2004}.
When designing user interfaces for scientific software, it is a good idea to \emph{address specific users or user-bases} rather than aim for a general solution \cite {Javahery:2004, DeRoure:2009}. Ideally, GUIs should be open to user customization and adjustable to personal preferences and professional specialization \cite{Gertz:1994, Javahery:2004}, possibly featuring \emph{quick access to frequent commands} \cite{Julvez:2014} and ways of \emph{navigating through previous commands} \cite{bestprSC}.
Additionally, it is advisable that scientific domain experts are brought into the design process for informing \emph{domain best practices} \cite{Schraefel:2004, DeMatos:2013} and evaluating the tool \cite{Keefe:2010}.
\subsubsection{Consider alternatives to graphical user interfaces}
Whereas graphical user interfaces (GUI) have made software user-friendly, arguably fostering the popularization of software in general, scientific software might require alternatives that, if not more intuitive, are more appropriate and efficient depending on the user's needs – especially if they involve entering and reading from large amounts of data. Furthermore, GUIs add an extra layer of complexity for development and documentation \cite{Smith:2016}.
Command-line interfaces are popular in computational science, as they often allow for quick repetition of tasks \cite{bestprSC}. Moreover, the analysis of large datasets can be easier and more productive when done through command-line input than through visual-based interfaces. \cite{Springmeyer:1993}.
Besides command-line interfaces, alternatives to GUI include code re-compilation, configuration files, and Domain Specific Languages (DSLs) \cite{Beg:2016}.
\note{elaborate on script / configuration files / DSL }
\subsubsection{Keep UI code separate from scientific simulations}
Simulation should not be embedded in UI code \cite{Kelly:2009}. This rule is particularly true to scientific software for many reasons: first, as previously stated, scientific software should be accessible from a number of alternative approaches; second, it should be easily ported and integrated to other software; third, keeping them separate makes reconfiguration and customization more convenient \cite{Bastos:2013}.
\subsubsection{Design for small, incremental changes}
Making incremental changes is considered a best practice for scientific software development \cite{bestprSC}, and the same principle applies to user interfaces. Ideally, \emph{GUIs should be planned for extensibility and frequent changes} as new requisites emerge. Through incremental changes, software is more likely to \emph{stay attuned to users' needs}, not forcing them to radically change the way they work \cite{DeRoure:2009}. Regarding constant updates and addition of new functionalities, GUI components that easily extendable, such as contextual popup menus, might offer interesting solutions \cite{MacLeod:1992}.
\subsubsection{Be minimalistic, but look out for exceptional needs}
Designers should be attentive to information that is particularly relevant in scientific software, but that could be eluded otherwise. \emph{Metadata}, for instance, is often required to be readable and easy to retrieve \cite{Talbott:2005, Baxter:2006, Macaulay:2009, Keefe:2010, DeMatos:2013, bestprSC, Thomer:2016}. Additionally, despite recent trends favoring flat design over skeuomorphism, software versions of physical instruments might benefit from adopting the looks of their real-world counterparts \cite{Foster:1998}, making it easier for users to learn about their functioning. Finally, minimalism should \emph{emphasize, rather than conceal, critical information} such as system malfunctioning \cite{Morais:2014}, emergency information \cite{Ferguson:2016}, and situations where awareness and response under time pressure are essential \cite{Aragon:2008}.
NOTE: Add sentence on parameters and user settings informed by List2017
NOTE: Double-check DeMatos on metadata
\subsubsection{Allow users to participate and contribute} Make it extensible
\note{include List 2017 as additional reference}
\subsubsection{Design for Accuracy}
The importance of correctness and precision in science demands software that allows for accuracy. This can be achieved by continuously constraining users' input and providing feedback on it \cite{Keefe:2010}. In some cases, it can be an advantage having two input modes for a same action --- one designed for accuracy, and other one for speed \cite{MacLeod:1992}.
\subsubsection{Design for Modeling, Simulation, and Data Analysis accordingly}
\note{Design for insight - data analysis and also providing visual tools on modeling and workflow composition}
\subsubsection{Record user steps}
\note{History and logging (informed by List 2017 and bestprSC)}