Tải bản đầy đủ - 0 (trang)
3 SigniFYI: A Suite of Semiotic Engineering Tools for the Study of HCC

3 SigniFYI: A Suite of Semiotic Engineering Tools for the Study of HCC

Tải bản đầy đủ - 0trang


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 specific

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 specification 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 specifications 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 final 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

reflective 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 reflections 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 scientific 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 benefits 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 specifies 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 reflective 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 specific documents that can be structured and organized in flexible

ways. The library of workplace practices can, of course, contain only a collection of

software development and metacommunication artifacts, which are perfectly fit for

reflection 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

not-so-good ones.

A detailed description of SigniFYI would be inappropriate in this introduction.

Chapter 3 is fully dedicated to this end. However, to give a flavor 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 find 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 find 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 specifications 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 verified 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 final 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 fields

when in fact it is not. Once again, SigniFYIng Traces will support the inspector in

documenting and presenting the procedures and findings of his study, for the benefit

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


Chapter 1.

Chapter 2.

Chapter 3.

Chapter 4.


A Software Development Story

The SigniFYI Suite

Concluding Remarks

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 fiction, 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 fiction 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 reflections 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

efficient 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, Pontifical 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,

18(4), 50–57.

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, Pontifical

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 &

Claypool. doi:10.2200/S00173ED1V01Y200901HCI002.

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 reflective software engineer: Reflective 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). Pontifical 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, Pontifical 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 reflection 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 reflections 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: Reflective 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 reflective 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 reflective 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:

Basic Books.



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). Reflective 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 (Monografias 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:

Springer. doi:10.1007/10722280_5.

Winograd, T. (Ed.). (1996). Bringing design to software. New York: ACM Press.

Chapter 2

A Software Development Story

Abstract In this chapter, we present a piece of technical fiction, 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 fiction, our “software development story” is composed by episodes verified 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 fiction,

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 fiction,” 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 confirm 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 final schedule. He notifies 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,

DOI 10.1007/978-3-319-42831-4_2




A Software Development Story

Fig. 2.1 Our fiction’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

Goes Wrong

Ana Pereira is a PhD student who has just finished 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 first 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

find 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

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

3 SigniFYI: A Suite of Semiotic Engineering Tools for the Study of HCC

Tải bản đầy đủ ngay(0 tr)