Information Technology Reference
In-Depth Information
Semiotic analysis
Semiotic analysis focuses on the signs present in the UI and extracts the underlying
codes that make (or break) their meaning. A full specification of the method is included
in Appendix B, “Semiotic Analysis.”
The primary goal of the SA is “to establish the underlying conventions, iden-
tifying significant differences and oppositions in an attempt to model the system
categories, relations (syntagmatic and paradigmatic), connotations, distinctions and
rules of combination employed” (Chandler, 2001). We shall do this analysis by iden-
tifying the signs within the UI and the codes within which these signs have meaning,
what sort of reality is produced, and what assumptions are made about the users. We
shall also take into account rhetorical tropes.
For the assumptions about the user's part we can exploit the semiotic inspection,
as proposed by de Souza (2006). In her research group (SERG: Semiotic Engineering
Research Group) such inspection is carried out in five steps: “[1] an inspection of on-
line and offline documentation and help content; [2] an inspection of static interface
signs; [3] and inspection of dynamic interaction signs; [4] a contrastive comparison
of designer-to-user metacommunications identified in steps [1], [2], [3]; and finally
[5] a conclusive appreciation of the quality of the overall designer-to-user metacom-
munication” (de Souza, 2006, p. 149).
From the SA we expect to achieve more insights, capture more data, and gather
more compatible data We expect the SA to be easier/faster to do; to be more amenable
to cross-cultural use; to be more accessible/understandable to professional HCI/UX
designers, usability analysts, business people, engineers, etc.; and to provide much
previous data and analysis examples at a lower cost. For a discussion about the
strengths of the semiotic method, see Chandler (2001).
The goal was to validate the SA against a nonsemiotic method. A validation be-
tween different semiotic methods can be made in a future study. As input for this
comparison, we chose a UI corpus (Section 3.3) consisting of similar portions of
two complex graphic design applications: Adobe Photoshop (PS) CS2 and the GNU
Image Manipulation Program (GIMP) 2.6.7, both running on Mac OS X 10.5.8. The
results gained both compare the usability of the applications during similar tasks, and
the type outcome of both of the methods.
3.3 UI CORPUS
Because the chosen UIs are very complex, we need to select a sample body of material
with which to work, or a corpus (see Barthes, 1977). There are various ways of
selecting the corpus material. As Barthes suggests, “the corpus must be wide enough to
give reasonable hope that its elements will saturate a complete system of resemblances
and differences
” (Ibid., p. 97). Moreover, “the corpus must be as homogeneous
as possible. To begin with, homogeneous in substance: there is an obvious interest in
working on materials constituted by one and the same substance
...
” (Ibid.). “Further,
homogeneous in time: in principle, the corpus must eliminate diachronic elements to
the utmost
...
” (Ibid., p. 98).
As de Souza points out, the selection can follow different criteria. “One possi-
bility is to choose portions that the design team thinks are most relevant, [
...
...
] that
Search WWH ::




Custom Search