Tải bản đầy đủ - 0trang
3 SigniFYI: A Suite of Semiotic Engineering Tools for the Study of HCC
SigniFYI: A Suite of Semiotic Engineering Tools for the Study of HCC
Fig. 1.7 The scope and the focus of research supported by SigniFYI tools
As suggested in Fig. 1.6, the SigniFYI Suite is designed to be used in inspection
activities, that is, an examination of various kinds of artifacts that carry the trace of
software design, development, and use characteristics. All proposed methods are
thus inspection methods, which can be used to probe for meanings in three speciﬁc
contexts shown in Fig. 1.7. Starting on the left-hand side, SigniFYIng Models supports semiotic engineering investigations of how meanings are inscribed in modeling and speciﬁcation tools and the conceptual objects they produce (“Meanings
(i)”). The scope of investigation supported by SigniFYI includes not only studies of
interaction with these tools but also studies of what models and speciﬁcations produced with such tools may mean to development team members who will use these
artifacts in the process of building a new IT artifact. The next context where meanings inscribed in software are probed is programming (“Meanings (ii)”). SigniFYIng
APIs supports investigations of how APIs and other programming packages are
typically used by software developers to communicate what such packages are and
what can be done with them by means of programming protocols. These protocols
function as an interface between the main program being developed and the particular package that is helping the programmer to accelerate his task by reusing readymade solutions implemented in the package. The third context where meanings can
be probed with SigniFYI is the end-user interface (“Meanings (iii)”). SigniFYIng
Interaction supports an investigation of designer-user metacommunication through
an inspection of interface signs that system and user can produce during interaction.
The investigation is carried out from the metacommunication sender’s point of
view, that is, without observing how users actually receive the metacommunication
message. SigniFYIng Message is the persisting structure that binds all probed meanings together in complex computer-mediated and computer-aided human communication processes that go from early stages of systems conceptual design and
development to the ﬁnal stages of systems use.
Our choice to work with inspection methods instead of user observation methods
is a practical one. In the context of HCC, unlike in HCI, the abundance of artifacts
provides us with a wealth of empirical evidence for an investigation of how meanings get to be inscribed in software. Moreover, considering that semiotic engineering has a powerful method to analyze metacommunication enabled by end-user
interfaces, the choice for SIM (the Semiotic Inspection Method) instead of CEM
(the Communicability Evaluation Method, which as mentioned above involves
direct user observation), gives the entire methods module in the SigniFYI Suite a
homogeneous contour that can considerably facilitate the learning and use of each
component. Therefore, in Fig. 1.7, “Meanings (iii)” should be taken as meanings
that may arise during end users’ interaction with the system. Their presence is
established by an inspector (see Fig. 1.6) who analyzes interface and interaction
signs as an advocate for a community of targeted users.
SigniFYI’s documentation module plays an essential role in the proposed suite,
given that knowledge gained with studies supported by SigniFYI is the result of
reﬂective interpretation and grounded judgment processes. As a consequence, the
very investigative procedures carried out by researchers, expert technical professionals, or even educators using the SigniFYI Suite have great value for others who
are interested in learning from reﬂections on practice. Note that, as mentioned previously, in interpretive studies in general and semiotic studies in particular, investigators construct their object of study. The way they approach the topic and their
evidence, the interim stages of analysis, the relations established among interim
results – all of these constitute knowledge assets that the investigation produces and
that can be used and evolved, for various purposes, in various contexts. Even in
more technical contexts, where rigorous scientiﬁc methodology yields to more
practical considerations, the trace of how expert professionals proceed in analyzing
and solving problems is a valuable knowledge asset. In educational contexts, where
demonstrations and illustrations are fundamental resources to support learning, the
value of SigniFYI tracing functions is even more evident. Hence, the beneﬁts of our
proposed suite may extend beyond the context of academic research.
Although a partially implemented version of SigniFYIng Traces has been built
and used in previous research (Brandão 2015), we choose to keep our presentation
at a conceptual level. In this way, readers who already use C&A technology or multimedia documentation systems can combine existing tools and compose their own
instantiation of SigniFYI’s documentation module in more convenient ways. The
blueprint speciﬁes the components and conceptual architecture of SigniFYIng
Traces, aiming to support the registration, presentation, and subsequent use (for
various purposes, in different contexts) of information and knowledge from semiotic engineering investigations of meanings in HCC. The documentation module’s
tracing facilities listed in Fig. 1.6 include capture and access of evidence (in various
kinds of media) as well as of analysis and interpretation procedures. They also keep
activity histories and support multimedia document generation, organization, and
interactive presentation. In research, these facilities play a fundamentally important
role in the validation and subsequent use of knowledge produced with interpretive
research methods. But in technical and educational contexts, these facilities play a
critical role in supporting reflection in action, reflection on action, and reflection on
practice (see Sect. 1.1). Starting with the latter, SigniFYIng Traces provides the
means to build and use a thoroughly documented and organized library of workplace practices that professionals can use to think critically about what they do and
how they do it, with which means and for which ends. The documents in this library
SigniFYI: A Suite of Semiotic Engineering Tools for the Study of HCC
may contain empirical evidence collected in action by reﬂective practitioners. That
is, SigniFYIng Traces capture tools can be turned on while professionals are at
work, thinking critically about their steps and decisions. Their thoughts will thus be
recorded in speciﬁc documents that can be structured and organized in ﬂexible
ways. The library of workplace practices can, of course, contain only a collection of
software development and metacommunication artifacts, which are perfectly ﬁt for
reﬂection on action. In this case, professionals can think about how a particular
system was built and the results it achieved, aiming to learn from good choices and
A detailed description of SigniFYI would be inappropriate in this introduction.
Chapter 3 is fully dedicated to this end. However, to give a ﬂavor of practical results
that can be achieved with the SigniFYI Suite, let us take the small school administration system example again. During an interface metacommunication inspection
with SigniFYIng Interaction, the inspector may ﬁnd that the “Add more” button (see
Screen 1 in Fig. 1.3) allows for the addition of information for just one more parent.
This should strike the inspector as a controversial choice, with potentially negative
psychological and social consequences for school children, their parents, and the
school itself. In an HCC study, the inspector wants do go deeper into the problem
and ﬁnd out where it began or how it came to be. One of the possibilities we have
already mentioned is that the modeling tool used to create representations and speciﬁcations of system features would not call the model readers’ attention (in printed
or interactive digital form) to annotations and extensions made to the created models. Thus, even if the modeler meant the system to accommodate the addition of as
many parents as appropriate for any given student, and said so in her annotation to
the “Add Parent” function, end model representations passed on to other members
of the development team failed to communicate the modeler’s message. This, as
will be seen in detail, could be veriﬁed with the use of SigniFYIng Models. Moreover,
SigniFYIng Traces would support the registration of evidence, as well as the production and the presentation of various types of documents with the inspector’s
analysis. For example, his considerations about the modeling tools used for the
development of this particular system (or the way they have been used to produce
interim and ﬁnal software artifacts) could be explicitly captured, structured, and
included in a larger workplace practice library organization for future use.
Similarly, the inspector using SigniFYIng Interaction might have come upon an
incomplete student record (see Screen 3 in Fig. 1.3). Now, searching more deeply
for how meanings got inconsistently inscribed in the school administration system
(remember that through the interface, the user is not allowed to submit a form unless
the information in it is complete), the inspector can use his technical knowledge to
infer (in an abductive reasoning process) that there may be a problem with data
importation programming packages. Thus, with the use of SigniFYIng APIs, he can
verify that, for example, certain default values inscribed in the importation API
allow the programmer to suspect that the API is checking for required data ﬁelds
when in fact it is not. Once again, SigniFYIng Traces will support the inspector in
documenting and presenting the procedures and ﬁndings of his study, for the beneﬁt
of other researchers, professional practitioners, educators, or learners.
How This Book Is Organized
This book is organized in four chapters, each one containing its own bibliographic
A Software Development Story
The SigniFYI Suite
This introductory chapter provides a panoramic view of the content of the book
as well as the motivation for doing the research we have done and publishing it.
Chapter 2 literally tells a software development story. Although it is a piece of ﬁction, which we wrote to use as a uniform constant reference for subsequent explanations and discussions, it is – as with many literary novels and short stories – “based
on true facts,” which we have put together to build a compelling plot. Thus, the
chapter reads as a short piece of technical ﬁction where readers will easily identify
elements of the content presented in this introduction to the book. In subsequent
chapters, parts of the story are revisited, examined, expanded, illustrated, and
Chapter 3 is the longest one. It presents, illustrates, and explains SigniFYI. Our
aim is that interested readers will be able to use it as a guide to work with semiotic
engineering tools in research, professional practice, or educational contexts. Chapter
4 concludes the book with our own reﬂections about the promises and limitations of
our contribution to HCC.
Electronic publications now allow readers to select which chapter(s) of a book
they want to read. We have therefore structured this book in such a way that chapters
can usually be read independently of others. Chapter 1 has been written for readers
who just want to have an overview of SigniFYI and the gist of our argument in favor
of investigating meanings inscribed in software. Chapters 2 and 3 have been written
for readers who are interested in learning our methods and using the SigniFYI Suite
to carry out semiotic studies of meaning inscription in software artifacts. Because
all illustrations in Chap. 3 are based on the short story presented in Chap. 2, the
former depends on the latter. However, Chap. 2 can be read in isolation by readers
who are interested in a compelling thought exercise. Finally, Chap. 4 can also be
read in isolation by readers who are acquainted with semiotic engineering. It can be
read in combination with Chap. 1 by readers who are more interested in the overall
rationale of a semiotic approach to HCC.
We include a manually generated subject index to the book, which supports more
efﬁcient searches for related content. Finally, we provide complementary material
online, in this book’s website. Interested readers can download this material from
Afonso. L. M. (2015, April). Communicative dimensions of programming interfaces (APIs). Phd
thesis, Department of Informatics, Pontiﬁcal Catholic University of Rio de Janeiro (PUC-Rio),
Rio de Janeiro, RJ – Brazil
Afonso, L. M., Cerqueira, R., & de Souza, C. S. (2012). Evaluating application programming
interfaces as communication artefacts. In Proceedings of the Psychology of Programming
Interest Group annual conference 2012 (PPIG’2012) (pp. 151–162). London: The Psychology
of Programming Interest Group.
Andersen, P. B. (1997). A theory of computer semiotics: Semiotic approaches to construction and
assessment of computer systems (2nd ed.). Cambridge: Cambridge University Press.
Bannon, L. (2011). Reimagining hci: Toward a more human-centered perspective. Interactions,
Blackwell, A., & Green, T. (2003). Chapter 5: Notational systems – The cognitive dimensions of
notations framework. In J. M. Carroll (Ed.), HCI models, theories, and frameworks (pp. 103–
133). San Francisco: Morgan Kaufmann.
Brandoã, R. R. M. (2015). A capture & access technology to support documentation and tracking
of qualitative research applied to HCI. Phd thesis, Department of Informatics, Pontiﬁcal
Catholic University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, RJ – Brazil.
Brandão, R., de Souza, C., & Cerqueira, R. (2014). Uma infraestrutura de captura & acesso para
instrumentaỗóo de avaliaỗừes qualitativas de IHC. In Proceedings of the 13th Brazilian symposium on human factors in computing systems (IHC ’14) (pp. 197–206). Porto Alegre: Sociedade
Brasileira de Computaỗóo. Online at: http://dl.acm.org/citation.cfm?id=2738088.
Crawford, K., & Hasan, H. (2006). Demonstrations of the activity theory framework for research
in information systems. Australasian Journal of Information Systems, 13(2), 49–68.
Creswell, J. W. (2015). A concise introduction to mixed methods research. Los Angeles: SAGE.
Danesi, M., & Perron, P. (1999). Analyzing cultures: An introduction and handbook (Advances in
semiotics). Bloomington: Indiana University Press.
de Souza, C. S. (1993). The semiotic engineering of user interface languages. International Journal
of Man-Machine Studies, 39(5), 753–773.
de Souza, C. S. (2005a). The semiotic engineering of human-computer interaction. Acting with
technology. Cambridge, MA: The MIT Press.
de Souza, C. S. (2005b). Semiotic engineering: Bringing designers and users together at interaction time. Interacting with Computers, 17(3), 317–341. doi:10.1016/j.intcom.2005.01.007
de Souza, C. S., & Carla Faria Leitao. (2009). Semiotic engineering methods for scientific research
in HCI, volume 2 of Synthesis lectures on human-centered informatics. San Rafael: Morgan &
de Souza, C. S., Leitão, C. F., Prates, R. O., Bim, S. A., & da Silva, E. J. (2010). Can inspection
methods generate valid new knowledge in HCI? The case of semiotic inspection. International
Journal of Human Computer Studies, 68(1–2), 22–40.
Dyba, T., Maiden, N., & Glass, R. (2014). The reﬂective software engineer: Reﬂective practice.
Software, IEEE, 31(4), 32–36.
Eco, U. (1976). A theory of semiotics (Vol. 217). Bloomington: Indiana University Press.
Ferreira, J. J. (2015, April). Communication through models in the context of software development
(Doctoral Thesis). Pontiﬁcal Catholic University of Rio de Janeiro, Department of Informatics,
Rio de Janeiro.
Ferreira, J. J., Sieckenius, C. de Souza, & Cerqueira, R. (2014). Characterizing the tool-notationpeople triplet in software modeling tasks. In Carla Leitão & Cristiano Maciel (Eds.),
Proceedings of the 13th Brazilian symposium on human factors in computing systems, IHC ’14,
pages 31–40, Porto Alegre, Brazil, Brazil, 2014. Sociedade Brasileira de Computaỗóo.
Ferreira, J. J., Sieckenius, C. de Souza, & Cerqueira, R. (2015). Why and how to investigate interaction design of software development tools. SBC Journal on Interactive Systems, 6(1), 48–65.
Fischer, G., Lemke, A. C., Mastaglio, T., & Morch, A. I. (1991). The role of critiquing in cooperative problem solving. The ACM Transactions on Information Systems, 9(2), 123–151.
Fischer, G., Girgensohn, A., Nakakoji, K., & Redmiles, D. (1992). Supporting software designers
with integrated domain-oriented design environments. IEEE Transactions on Software
Engineering, 18, 511–522.
Goguen, J. (1999). An introduction to algebraic semiotics, with application to user interface
design. In C. Nehaniv (Ed.), Computation for metaphors, analogy, and agents, LNCS 1562 (pp.
242–291). Heidelberg: Springer. doi:10.1007/3-540-48834-0_15.
Guzdial, M. (2013). Human-centered computing: A new degree for licklider’s world.
Communications of the ACM, 56(5), 32–34.
Hasan, H. (1999). Integrating IS and HCI using activity theory as a philosophical and theoretical
basis. Australasian Journal of Information Systems, 6(2), 44–55. doi:10.3127/ajis.v6i2.305.
Hill, W. C., Hollan, J. D., Wroblewski, D., & McCandless, T. (1992). Edit wear and read wear. In
P. Bauersfeld, J. Bennett, & G. Lynch (Eds.), Proceedings of the SIGCHI conference on human
factors in computing systems (CHI ’92) (pp. 3–9). New York: ACM. doi:10.1145/142750.142751.
Jaimes, A., Gatica-Perez, D., Sebe, N., & Huang, T. S. (2007). Human-centered computing:
Toward a human revolution. Computer, 40(5), 30–34. doi:10.1109/MC.2007.169.
Juliana Soares Jansen Ferreira. (2015, April). Comunicaỗóo atravộs de modelos no contexto do
desenvolvimento de Software. Phd thesis, Department of Informatics, Pontiﬁcal Catholic
University of Rio de Janeiro (PUC-Rio), Rio de Janeiro, RJ – Brazil.
Klaus Bruhn Jensen. (1995). The social semiotics of mass communication. London: Sage.
Korpela, M., Mursu, A., & Soriyan, H. A. (2002). Information systems development as an activity.
Computer Supported Cooperative Work (CSCW), 11(1–2), 111–128.
Maran, T., Martinelli, D., & Turovski, A. (Eds.). (2011). Readings in zoosemiotics. Number 8 in
Semiotics, communication and cognition. Berlin/Boston: De Gruyter Mouton.
Maria Eunice Quilici Gonzalez & Willem (Pim) Ferdinand Gerardus Haselager. (2005, January).
Creativity: Surprise and abductive reasoning. Semiotica, 2005(153 – 1/4), 325–342.
Nadin, M. (1988). Interface design: A semiotic paradigm. Semiotica, 69(3–4), 269–302.
Nakakoji, K., Yamamoto, Y., Takada, S., & Reeves, B. N. (2000). Two-dimensional spatial positioning as a means for reﬂection in design. In D. Boyarski, & W. A. Kellogg (Eds.), Proceedings
of the 3rd conference on designing interactive systems: Processes, practices, methods, and
techniques, DIS ’00 (pp. 145–154) New York: ACM Press.
Nerur, S., & Balijepally, V. G. (2007). Theoretical reﬂections on agile development methodologies.
Communications of the ACM, 50(3), 79–83.
Norman, D. A. (1986). Cognitive engineering. In D. A. Norman & S. W. Draper (Eds.), User centered systems design (pp. 31–62). Hillsdale: Lawrence Erlbaum and Associates.
Pakman, M. (2000). Thematic foreword: Reﬂective practices: The legacy of Donald Schon.
Cybernetics & Human Knowing, 7(2–3), 5–7.
Peirce, C. P. (1992). The essential Peirce (Vol. 1). Bloomington: Indiana University Press.
Peirce, C. P. (1998).The essential Peirce (Vol. 2). Bloomington: Indiana University Press.
Pereira, L. S., Ferreira, S. B. L., Braga, H., Cardoso, L. de Castro Salgado, & Nunes. R. R. (2014).
Using cultural viewpoint metaphors to provide web accessibility for the visually impaired
users. Procedia Computer Science, 27, 186–196.
Pescio, C. (2006). Listen to your tools and materials. IEEE Software, 23(5), 74–80.
Redmiles, D., & Nakakoji, K. (2004). Supporting reﬂective practitioners. In Proceedings of the
26th international conference on software engineering. ICSE 2004. (pp. 688–690) Piscataway,
May 2004. IEEE Press.
Russell, T. (2005). Can reﬂective practice be taught? Reflective Practice, 6(2), 199–204.
Salgado, L. C. C., Leitão, C. F., & de Souza, C. S. (2013). A journey through cultures – Metaphors
for guiding the design of cross-cultural interactive systems. London: Springer.
Schön, D. A. (1983). The reflective practitioner: How professionals think in action. New York:
Schön, D. A. (1987). Educating the reflective practitioner: Toward a new design for teaching and
learning in the professions (1st ed.). The Jossey-Bass higher education series. San Francisco:
Schön, D. A., & Bennett, J. (1996). Reﬂective conversation with materials. In T. Winograd (Ed.),
Bringing design to software (pp. 171–189). New York: ACM Press.
Sebe, N. (2010). Human-centered computing. In Nakashima, H., Aghajan, H., & Augusto, J (Eds.),
Handbook of ambient intelligence and smart environments (pp. 349–370). New York: Springer.
Silva, B. S., & Barbosa, S. D. J. (2007). Designing human-computer interaction with MoLIC diagrams – A practical guide (Monograﬁas em Ciờncia da Computaỗóo MCC 12/07). Rio de
Janeiro: Pontifớcia Universidade Catúlica.
Silva, F. F. M., Luciana Cardoso de Castro Salgado, Suplino, M., & Raposo, A. B. (2014). Cultural
viewpoint metaphors guiding the collaborative strategies design of a multitouch tabletop game
for people with autism. Themes in Science and Technology Education, 7(2), 83–98.
Simone Diniz Junqueira Barbosa and Maíra Greco de Paula. (2003). Designing and evaluating
interaction as conversation: A modeling language based on semiotic engineering. In Goos, G.,
Hartmanis, J., van Leeuwen, J., Jorge, J. A., Nunes, N. J., & J. Falcão e Cunha (Eds.), Interactive
systems. Design, specification, and verification (Lecture notes in computer science, Vol. 2844,
pp. 16–33). Berlin/Heidelberg: Springer. doi:10.1007/978-3-540-39929-2_2.
Sowa, J. F. (2000). Ontology, metadata, and semiotics. In G. Goos, J. Hartmanis, J. van Leeuwen,
B. Ganter, & G. W. Mineau (Eds.), Conceptual structures: Logical, linguistic, and computational issues (Lecture notes in computer science, Vol. 1867, pp. 55–81). Berlin/Heidelberg:
Winograd, T. (Ed.). (1996). Bringing design to software. New York: ACM Press.
A Software Development Story
Abstract In this chapter, we present a piece of technical ﬁction, that is, a short
story that tells how a group of users trying to coordinate action through Web and
mobile applications got into serious problems. The aim of the story is to serve as a
motivation and an illustration of our proposed approach to human-centered computing (HCC).
In spite of being a piece of ﬁction, our “software development story” is composed by episodes veriﬁed in use situations by one or more of the authors. Hence,
the portrayed scenario is a realistic one. It provides a quick illustration of SigniFYI,
the suite of tools to inspect meanings encoded in software design, which we introduce in Chap. 1 and will develop and discuss in Chaps. 3 and 4.
This chapter tells a software development story. Although it is a piece of ﬁction,
which we wrote to use as a reference for subsequent explanations and discussions in
this book, it is based on true facts. They have happened at different times and different contexts, but we have them strung together in order to build a compelling plot.
It is a piece of “technical ﬁction,” so to speak, where readers will be able to spot
elements of the content presented in Chap. 1. Parts of this story will be revisited,
examined, expanded, and discussed in detail later.
The plot is presented schematically in Fig. 2.1. It starts with users experiencing
a serious breakdown while interacting with a university system that manages the
graduation process of all students. The focus of the story is on the scheduling process of a PhD student’s defense session. The candidate student and all other committee members must use the system to establish and conﬁrm the date and time for
this session. However, when everything is settled, one of the committee members
realizes that his choices have been completely overridden “by somebody” or “by the
system” when setting the ﬁnal schedule. He notiﬁes the student about it and, after
testing the system and cross-checking information, they have no idea of what went
wrong. The problem is reported to the developers of the system, who begin to investigate its causes immediately. This problem has caused severe disruptions in the
involved users’ work activity. Decisions had to be revoked and new defense date
options had to be created and discussed. Therefore, even if the reason for so much
trouble is that users were confused while interacting with the system’s interface, it
will have to be avoided and changes will have to be made.
© Springer International Publishing Switzerland 2016
C. Sieckenius de Souza et al., Software Developers as Users,
A Software Development Story
Fig. 2.1 Our ﬁction’s plot
The details of the investigation are not relevant at this point. We cursively tell
what happened, concentrating on the plot, so that readers can more easily keep it in
mind. It will help them understand the rationale behind SigniFYI and see how it can
be used to support both research and technical knowledge-building activities.
Ana’s PhD Thesis Defense Scheduling Process
Ana Pereira is a PhD student who has just ﬁnished her thesis in Computer Science
and Information Technologies at a Brazilian university in Rio de Janeiro. All the
invited examiners have accepted the invitation sent through the university’s
Graduation Exams Management System (GEMS) by her advisor, Prof. Costa, in a
previous stage of the process. Right now Ana is using GEMS to negotiate the date
and time of her defense with all committee members. GEMS is used by all students
and faculty at the University and provides easy authenticated access for external
examiners. The system runs on different platforms (desktop, Web, and mobile),
featuring communication and coordination functions that have, among other things,
considerably improved and facilitated defense scheduling processes at all levels of
graduation. GEMS has been developed by the University’s Information Technology
Service Center (ITSC) and is integrated with other administrative systems developed by ITSC.
One of Ana’s ﬁrst steps in GEMS is to create an event (Ana Pereira’s Thesis
Defense). She informs all the requested details for the event, as well as a set of
Ana’s PhD Thesis Defense Scheduling Process Goes Wrong
Fig. 2.2 Ana previews her message to committee members in the desktop browser interface
scheduling options for the defense session. In PhD committees, there are two internal members and two external ones in addition to one internal and one external
standby member. Including her advisor, who chairs the committee, Ana’s task is to
ﬁnd a date and time period when these seven people are simultaneously available.
She narrows the scheduling possibilities to a short list of four alternatives. Next,
she concludes this initial stage by pressing a button to send all committee members
and chair a message with a request to indicate all possible schedules (if any) among
the proposed alternatives. Ana knows that Prof. Santos, who is a faculty in her own
department at the University, is away for a conference in Dallas, Texas. But she is
not worried because she knows that he is always connected when traveling and that
he can access GEMS through the system’s mobile app. If he cannot respond for
some reason while traveling, he will be back at the University in just a few days.
There would only be a short delay in the process, which she thinks is OK. So she
previews her message to committee members (see Fig. 2.2) before she dispatches it
through the system.
Less than a week later, Ana is happy to see that all seven members have checked
their availability and that there is a common date and time period when they are all