An Environment to Support Developers in Elaborating a Collaborative and Evolutionary Style Guide Elizabeth Furtado1 , Kênia Sousa1 and César Colera 2 1

Universidade de Fortaleza (UNIFOR) Av. Washington Soares, 1321 – Bairro Edson Queiroz – 60.455-770 Fortaleza - CE, Brazil 2

Secrel SSA Av. Dom Luis, 500, andar 20- Aldeota – 60.160-230 Fortaleza - CE, Brazil {elizabet,kenia}@unifor.br, [email protected]

Abstract. People involved in system development in organizations face problems during the user interface design phase. Some of these problems are lack of consistency among systems developed, lack of support by development tools and lack of documentation on recommended style guides and difficulties in choosing the best interaction styles. In order to avoid these problems, this paper defines an approach in which a style guide can be created and used in an organization. If a developer encounters a problem when using a development tool, the style guide can be accessed in order to find answers to the developer’s doubt, since the approach for elaborating a style guide proposed in this paper is structured with questions and answers, which can also be used as documentation for new developers.

Resumo. Pessoas envolvidas no desenvolvimento de sistemas em organizações encaram problemas durante a fase de projeto da interface do usuário. Alguns dos problemas são falta de consistência entre os sistemas desenvolvidos, falta de apoio das ferramentas de desenvolvimento, falta de documentação sobre os guias de estilos recomendados e dificuldades em escolher os melhores estilos interativos. Para evitar esses problemas, esse artigo define uma abordagem na qual um guia de estilos pode ser criado e usado em uma organização. Se um desenvolvedor encara um problema quando está usando uma ferramenta de desenvolvimento, o guia de estilos pode ser acessado pelo desenvolvedor com o intuito de encontrar respostas as suas dúvidas, já que a abordagem para elaborar um guia de estilos proposta neste artigo é estruturada com perguntas e respostas, que também podem ser usadas como documentação para novos desenvolvedores.

1. Introduction It is common for developers in an organization to stop developing an interactive system under their responsibility for many reasons, such as, they change to a new organization or they have been allocated to develop another system. This can cause serious problems to the usability of a system. In addition, it is very difficult to find an organization worried about doing style guides documentation; instead they do conceptual models as a relationship-entity model. But if there is some documentation, the documents have an extent that makes their handling uncomfortable [Vanderdonckt, 1999]. Style guides are one type of ergonomic source, which can be called “User Interface (UI) guidelines” when designing UIs. The style guides are usually hard to interpret and apply [Myers, 1993]. For these reasons, we verify that in an organization, the UI of the same interactive system can be different, lacking consistency among windows developed. To solve the problem related to lack of consistency, the organization generally assigns the responsibility of UI evaluation to one person. Instead of assigning the responsibility for the creation of the style guide to one person, it is important to provide assistance to the entire development team involved in order for them to do it well and to know how to work with it. This means to have a tool, which provides developers good examples based on ergonomic principles, the opportunity to participate in decisions of UI design [Gale, 1996] and the possibility of maintaining and accessing the style guide easily. This paper defines a collaborative approach in which a style guide can be created and used in the organization. This approach is implemented through a tool, which supports the participatory and evolutionary process of creation of a style guide. This approach for elaborating a style guide is structured with questions and answers and it can be used as a help if a developer encounters a problem when using a development tool or as documentation for new developers.

2. Style Guide Development Principles The style guide is often used to check a UI after its implementation during the user testing process. However, it is more productive to use it right from the beginning of a project. It is important to note that the production of a style guide cannot be seen as a substitute for iterative design and user testing [Vogt 2001]. A good style guide must respect some development principles, which we consider very important.

Participation and Collaboration. Many developers do their work on their own and this contributes to re-work inside an organization. On the other hand, developers who share information among each other have better productivity since products of many phases during the development cycle can be reused. The participation of developers in a group to create a style guide is useful to them because they can share not only technical knowledge but also practical knowledge that a developer acquires through experience in the design of UIs. Another way to ensure a better application of a style guide is to make it possible for users to reflect about their difficulties on their own and with others. Several educational theories claim that learning depends on the individual's knowledge being built by social interactions [Vigotski, 1984] and [Bourne et al, 1997].

Evolution. The evolution of the style guide is extremely important to make it a dynamic process, in order to constantly expand and evolve the style guide. A style guide should reflect the corporate image of an organization and the evolution of interaction styles.

Documentation. The style guide can be used as documentation for the guidelines to be followed by developers. It is important for developers to have basis on ergonomic principles, instead of adapting each interface based solely on personal opinions.

Association of Theory and Practice. Researchers who have scientific basis on a domain of their interest, but do not apply this expertise in practice have missed the experience of finding real results for their research. Likewise, practitioners who lack expertise on a domain, but learn with practice find many problems along their work. The application of theory and practice simultaneously is an important factor in defining the success of a work, e.g. the usability of a UI. Considering this principle, people involved in building this style guide come from a university (researchers) and from an organization (practitioners). 3.

Procedures to Create the Style Guide

Consistency and usability problems can be avoided when developers have a defined pattern to follow by applying definitions of the style guide. To help an organization define this pattern, we defined a process for the creation of a style guide by considering the principles described previously. This process was composed of the execution of the following phases. 3.1. Definition of Online Communities and Needs A partnership was established between a private organization (SECREL) and us, a private university (UNIVERSITY OF FORTALEZA - UNIFOR). Secrel developers are responsible for developing usable systems and Unifor professors specialized in HCI are responsible for defining and preparing the fundamental base for the style guide, which will be accessed by Secrel developers in order to achieve their goal. The set in assessing community needs is to clearly identify the main purpose of communities that focus in development [Preece, 2000]. Secrel’s purpose is to satisfy their users with usable systems. Unifor has the need to apply the knowledge acquired by its professors and researchers in real situations in order to evaluate the output of new methodologies. These communities’ purposes helped to build an integrated practicetheory style guide and to motivate them to use it. 3.2. Definition of the Software Taking into account that communities need a virtual space to work in order not to compromise their activities, we chose an online software on the web. The software chosen to elaborate a style guide was MC2 [Furtado and Colera, 2000], (www.mc2.com.br/demo), which incorporates organizational learning principles to help ensure the motivation and participation of users. MC2 brings together a set of tools that contribute to the knowledge management process by allowing the creation and

maintenance of organizational memory. To achieve this goal, the approach taken by MC2 is aimed at establishing favorable conditions for interaction between the personnel within an organization as well as with the system itself. Another main goal of MC2 is to enhance personnel awareness as to the importance of their participation in the process, thereby creating an organizational culture of continuous learning. To have a tool to support the continuous learning of UI guidelines is in accordance with our interests of ensuring the evolution and documentation principles. MC2 has a participatory space, which makes computerized procedures available that seek to contribute to the formation of better relationships among online communities. The style guide will be available at this software, aiming to be used by developers from the beginning of every project in the organization. This software is useful for developers who have difficulty in finding development tools that support the use of style guides, and for new developers in the organization, facilitating the applicability of defined guidelines. The goal is not to get a huge amount of rules very quickly, but rather to transfer the knowledge about HCI issues as efficiently as possible from the experienced experts to all others [Vogt, 2000]. 3.3. Definition of Roles and Responsibilities People responsible for creating the style guide have to be properly assigned in order for its effects to be visible, such as the assurance of usability on developed systems [Gale, 1996]. Developers in an organization and experts on HCI are responsible for developing a style guide that will be done by the definition of questions and answers related to the style of the UI design. The main roles of this community are the following: • Administrator, the development cycle coordinator, is responsible for (i) verifying the existence of answers to questions; (ii) proposing questions and answering them; (iii) deleting these questions from the software; and (iv) proposing discussion on the creation of new style guides, which will lead to voting and a decision-making process. We have defined two administrators, one from the organization and the other one from the university. • Multiplier, who has knowledge on a specific area and is interested in propagating this knowledge. In more details, the multiplier is someone who (i) stimulates others to participate; (ii) brings scientific basis to the decisions by suggesting articles, and promoting courses; (iii) proposes reflective questions; (iv) proposes questions and answers them; (v) proposes basis to an answered question by inserting guidelines associated to the question; (vi) deletes visualization questions from the software; (vi) participates on the discussion of new style guides; and (vii) votes on proposed guidelines. The multiplier is represented by a human factors expert from UNIFOR, who is experienced in cognitive principles and may assume that guidelines are sorted by them, and pays attention to high levels guidelines [Vogt, 2000]. • General participants, who are responsible for (i) proposing reflective and basis questions; (ii) proposing visualization questions and answering them; (iii) suggesting

new style guides; (iv) discussing about new style guides; and (v) voting on proposed style guides. These participants can be designers and programmers, the first one isolates specific guidelines and solves conflicts between them by ranking them into ordered sequences, and the latter is responsible for the creation of widgets in the program, which should be reflected in the organization of the style guide. 3.4. Specification of the Method on Defining Questions and Answers for the

Style Guide Questions defined for Style Guides are composed of expression and complement. The type of expression varies according to the kind of question. Examples of expressions for reflective questions are “what”, “which”, “where”, and “how”, an example for basis questions is “why it is necessary”, two examples for visualization questions are “how it is visualized”, and “where it is visualized”. The complement is used to specify interaction objects and interaction styles, asking about standard names, formats, color, type, fonts, ordering sequence and so on [Delgado and Nielsen, 1996]. The complement includes the following aspects: a) Screen layout and design, which may be characterized by the following types of information about windows: window interaction – opening, closing, navigating between windows, etc.; window layouts depending on its type – control, data presentation, data maintenance, search, main, dialogue, pop-up, etc. b) Interaction objects design, which may be characterized by: types of interaction objects – input, output, I/O, message, tables, graphics, and diagrams; and menu and push buttons for activating tasks. c) Interaction styles asking about variations of input and feedback to meet target user requirements. For example, how to provide information with text-only without extensive graphics. 4. Elaboration of the Style Guide This section provides information and an example about the participatory and collaborative online community process for the style guide elaboration. 4.1. Accessing and Maintaining the Style Guide As we have mentioned, the organization style guide is documented with questions and answers based on guidelines. This documentation is used as a help for developers and is accessed through MC2 tools. So, we can say that the help is automatically created as the questions and answers are defined in the style guide knowledge base. The creation of this help is set by the interaction of the participants with the guide (See Figure 1). When the guide is consulted, an auto-reply question can be submitted and the guide is changed with the answer to this question (1) or a question can be submitted to be answered by participants (2). Administrators and multipliers read the question (3) and may answer it changing the guide (4) or they may answer it and e-mail the answer to the requester, not

changing the guide (5). Another option is to send the question to the group using Forum (6). The question can be discussed by the group personally (7a) or using forum (7b). To come to a consensus, the group can vote (8) and the decision can inserted in the guide as an answer to the question (9) or it can be e-mailed to requester, not changing the guide (10).

the the be the

Figure 1 – Maintaining and accessing the style guide

The guide uses some of MC2 tools, such as queries, forum, groups, voting, and article. “Queries” is a tool in MC2, through which the community can research questions, make questions, and create knowledge bases depending on the user’s permission. When designers encounter problems during the UI design phase, they can find answers to their doubts by accessing the style guide base, or they can submit the question to be answered by experts on the subject (multiplier), by the administrator, or by participants of a group. The “Group” is defined based on the theme of interest, which in this case is style guides. Participants of a group share knowledge disseminated by the multiplier by accessing the “Article”. It is useful to write information about guidelines. The discussion in-group is made by using the “Forum”. At this moment, the articles can be accessed, what brings basis to the decision process. Since many participants find it difficult to come to a consensus, the “Voting” tool is used in order to simplify this process.

4.2. An example using MC2 Developers who face problems during the development process may search for questions in the style guide in order to solve it. Figure 2 depicts a participant searching

for questions related to “hints”, and finding three reflective questions (what a hint is, how a hint is used, when a hint is used), one basis question (why a hint is needed), and one visualization question (how a hint is viewed). The goal of these questions is to present guidelines, which should be followed by developers who have access to the style guide.

Figure 2 – Searching for questions

When developers do not find the answer to their question in the style guide, they have the option of asking a question to other participants by submitting the question to a group. The group participants will discuss the question in order to come to a consensus and define guidelines that should be applied in the development process. Figure 3 shows a question being submitted to participants. There is also the option of administrators answering their own question, which happens when there is the intention of enhancing the style guide base.

Figure 3 – Submitting a question

If the group does not come to a consensus, the discussion is finished through a voting process, in which all participants express their opinions by choosing one of the options presented. Figure 4 depicts the meeting and voting results. The administrator answers the question based on the result and decides to change the guide or not based on the relevance of the matter.

Figure 4 – Visualizing the meeting and voting results

5. Conclusion We have described an original process for the style guide elaboration based on the participation of an online community (organization - university) through MC2 tools. The style guide can be easily accessed and maintained. Moreover, the results of the discussion process about the style guide (articles, question-answer, meeting results) can be used as documentation for developers. Using a style guide, it is possible to have benefits in both sides: users and developers. The user productivity can increase because a consistent style reduces what users need to learn and remember, resulting on shorter training time and fewer user errors. The developer productivity can increase because it is more effective to start with standards than to attempt personally to achieve consistency re-inventing new standards formats. Our work is still at an early stage; however the evidences encourage us to believe that the overall environment being developed has considerable possibilities. The style guide knowledge base should be based on concrete experiences, obtained from discussions with a group of professors and developers. During these discussions, the groups will debate and share their practice, and the knowledge mobilized in this

practice. These discussions will help us discover developers' beliefs, and their experience level. The method application will be composed of the following activities: i) group definition with the role specification for each member, considering the experiences identified in the discussions; ii) training on the method; iii) proposal of themes concerning style guides, which will be in the knowledge base, e.g. Web Pages; and iv) the environment use. In the whole process, the method will guide us, but we will be very privileged by the group cooperation.

References Bourne, J.R., McMaster, E., Rieger, J. & Campbel, J.L. Paradigms for on-line learning: a case study in the design and implementation of an asynchronous learning networks course. 1997. Available on http://www.aln.org/alnweb/journal/issue2/assee.htm Delgado, E.; Nielsen, J. International User Interfaces. New York: Wiley, 1996. FURTADO, J. J. P.; COLERA, C. Learning Organization through the integrated use of Information Systems and knowledge Engineering In. AMERICAS CONFERENCE ON INFORMATION SYSTEMS, 2000, Long Beach, CA Proceedings of Americas Conference on Information Systems - AMCIS, New York AIS, 2000, v. 1, n. 1. Gale, S., A collaborative Approach to Developing Style Guide, In: Proc. Of ACM conf. on Human Factors in Computing Systems CHI 96. Vol. 1. 1996 – 362-367. Also Accessible at http://www.acm.org/sigchi/chi96/proceedings/papers/gale Myers, B.A. why are Human-computer interfaces difficult to design and implement? Technical Report, no CMU-CS-93-183. Carnegie Mellon University, School of Computer Science. July, 1993. Preece, I. Online Communities – Designing Usability, Supporting Sociability. New York: Wiley, 2000. Vanderdonckt, J. Development Milestones Towards a Tool for Working with Guidelines. Interacting with computers. 81-118. September. 1999. Vigotski, L. S. A formação social da mente. São Paulo: Martins Fontes. 1984. Vogt, T., Difficulties in Using Style Guides for Designing User Interfaces. In proc of Tools for Working with Guidelines. Ed. Jean Vanderdonckt and Christelle Farenc. Biarritz, France. 2000.