Image via Wikipediawww.atlasti.com
I felt that his comments on intuitiveness in qualitative data analysis software bore repeating and disseminating. This issue has long been a matter of contention in comparing quantitative and qualitative software packages AND more recently in the discussion new Web 2.0 tools in comparison to the more robust stand-alone packages. As a developer with long experience in the field, Muhr's comments are particularly important for those of us who are advocates for QDAS software to hear.
Dear readers of qual-software,
this post was intended as a reply to a discussion that emerged in early
February. However, when thinking about a specific issue I decided to make
this a separate thread.
The notion of "intuitiveness" is intriguing but has its limitations. If it
is used as a lense to evaluate tools such as software systems, the inherent
complexity of the domain augmented by the tool must be taken into account.
Intuitiveness has its obvious benefits; for one, it is associated with a
shallow learning curve, and as a corrollary, efficient and economical.
Nevertheless, I would like to raise a few points with regard to this
increasingly popular standard and expectation, and in particular question
its universal applicability.
For starters, assuming that the addressed domain (to be analyzed) is
adequately understood by the potential user (no matter if the methodology
was or was not sufficiently intuitive to abandon any manuals or courses),
the steepness of the learning curve does in fact depend on how well,
completely and congruently (emulating natural workflows) the concepts and
methods of the domain are represented in the tool. However, in reality, and
not only in the QDA field, learning a tool and learning a methodology are
This can often lead to a bias and making it difficult to isolate the
learning curve for the software. Ultimately, discussions about the relative
ease of learning QDA tools often overlook that fact that essentially two
things are part of the curriculum. In some cases, users expect that a
software program might even replace proper training in methods.
Intuitiveness is not neccessarily bound to how well a given software system
intended for one domain resembles a standard in a completely different
domain such as one used for writing and reading emails. It may come as a
surprise how many users of standard email/calendar tools experience
difficulties regarding the accessibility or "user-friendliness" of important
And the functions provided by such tools, e.g. Outlook, are far less complex
than what tools in the QDA area may need to offer. The situation is even
becoming a bit more complicated with tools like Outlook. While receiving and
responding to an email is quite intuitive, changing the style of your
responses, adding or modifying mail accounts or creating a meaningful series
of calendar events is already another thing. While we expect and require a
broader range of functions, expectations of ease-in-use also continue to
grow, prompting the question of whether there is indeed a budding paradox in
the software field.
Even if all engineering efforts have been invested in making a tool as
"intuitive" as possible, there will still be a difference dictated by the
complexity of the modeled reality. t is relatively easy to create
anintuitive tool for calling a taxi with an iPhone (which I recently
installed: activate big yellow button; enter number of passengers; make
payment and voila, the taxi is on its way). Such tools obviously do not
require a manual or a two-day workshop. By the way, good examples for
intuitive interfaces are some adaptations of web sites to the limitations of
mobile devices. Modelling more complex relations obviously requires a
broader spectrum of commands, all of which the user must be at least vaguely
aware in order to benefit from them.
And if users plan to use a tool that allows them to work on text, images,
audio, video, GIS data, (native) PDFs, as well as one that can create and
manage selected segments in each of these media types; a program that
enables the user to create and define links between codes and segments,
codes and codes, segments and segments (hyperlinks), create and manage memos
that can be associated to any kind of concept available, group concepts,
synchronize media data and transcripts, create queries & hypotheses, decide
and/or create relational prototypes modeling the methodology used, offer a
vast array of analytical tools, offer standards for importing and exporting
project data (-> 1)... and so on and so forth... comparing this type of
broad-spectrum functionality - with regard to intuitiveness - to a tool
primarily dedicated to the analysis of video and the display of an
associated transcript (i.e. Transana) is questionable, at very least.
Without a doubt, the latter tool will suffice for any task or phase
constrained to the ingredients just described.
A tool's intuitiveness can be taken to impressive heights, but if a variety
of methodologies and styles are to be supported, the increasing number of
tool functions and workflows may conflict with this effort. And of course,
personal styles and intellectual habits are also involved in the process of
getting acquainted with a tool. ATLAS.ti has always tried to be as open as
possible with regard to exploring, navigating the emerging "context of
discovery" while concurrently remaining systematical when it comes to
representation and analysis.
Human reasoning and creativity does not often fit well in a tiled
hierarchical windowing scheme, even if it is sometimes comfortable and
tidier. (-> 2) The task we have solved (and are steadily improving) is to
provide a workspace for the user in which all ingredients of a research
endeavor, including the primary data, the concepts that arise in the
process, the memos to be recorded, the linkages between the data and the
"theory", the short cuts between the conceptual level and the indicators in
the data in their original context, can be easily queried and navigated. It
would be an interesting research question itself to find out which
methodologies and which tools match which intellectual and emotional
preconditions - while of course using ATLAS.ti for the analysis!-) While I
agree completely that our system would and should benefit from certain
improvements - and we are constantly working on improvements, which by the
way, we return to our users not only in (costly) major releases but in a
constant evolutionary process, I disagree that adapting to a more standard
(i.e. "Outlook"-type) interface would make things much easier. Our current
efforts are focussed on the different roles and levels of expertise of users
working with our tools and how different needs can be modeled in the user
interface. And in this process of change we include our users as well as our
Thanks for your patience - comments welcome!
- Thomas Muhr (CEO ATLAS.ti GmbH)
---- end notes ---
(1) By the way, it is only the fact that ATLAS.ti exports project data in a
standard format (XML) that makes the feature "we are able to import ATLAS.ti
projects" possible. It would be much better - at least for the scientific
community - if ALL (!) makers of QDA software would finally agree to support
an open standard or at least an XML based export/import technology. Our XML
compatibility means we allow our users to "leave" us, which may not make
much sense business-wise. But with only proprietary data structures, the
migration path to alternative and/or future tools will be long and bumpy,
not to mention the chances for smooth longitudinal designs. My advice is to
check your current system if it also gives you the freedom to say "goodbye".
If not, ask for it.
(2) When I look at my desk and desktop, I personally get the impression that
a messy environment can be quite inspiring at times!-
"Convolutedness" at first sight may indeed turn into familarity once the
main concepts and procedures are understood. Instant intuiveness on the
other hand is great, but if you need to drop important properties of your
research requirements it isn't really helpful, i.e. conducive to complex
"Computers, like every technology, are a vehicle for the transformation of
tradition" (Winograd & Flores, 1987) ATLAS.ti Scientific Software
Development GmbH - Berlin - www.atlasti.com